开云体育

Hi, I am using version: 10.19.02 of the C++ API. When I run the "TestCppClient" program the following error is received: The line in the code that crashes the program: printf( "Connected to %s:%d

Definitely not in the api thread. What do you mean by your own queue? Are you sure this is thread safe? Most probably your problem stems from this. If your queue is not fast enough or prone to race,

In which function are you running this bit of code? Inside the EWrapper callbacks (ie tickSize, tickPrice etc)? If you do time.sleep() on the api thread, wouldn't messages get lost when they are sent

If your instance of IBapi() is called app like mine, in every thread I check app.msg_queue.qsize(). Make sure to use semaphores, as the .qsize() reading itself can create race if a few threads try to

Hi, Thanks for the response, race conditions were my initial concern. Mind explaining how would I go about monitoring the api message queue and keep race conditions from happening?

IMHO this is hardly possible unless you're ready to rewrite the api itself. Anyway 10-20 trades per minute is not much. What's your current time per "a trading logic cycle"? I now have around 50ms per

For me the delay happened on race conditions when unloading the api message queue. Once I found a way to monitor it, I have noticed it could grow to thousands of unprocessed messages, which caused the

Yes @biney59? does same as I, you have to compute it. 1- it's simple enough 2- It's somewhere a real time information related to latest Bid or Ask depending upon your trade direction. (as current

I am running a trading strategy that gathers data from many different instruments, and can make 10-20 trades in a matter of minutes. Sometimes the order don't get filled so there can be a high load on

There is no API that gives this automatically. The basic idea would be to have execution callback handler monitor fill average price, and re-adjust order after that.

Unrealized PnL is basically *( avg_position_price - current_ticker_price ) * position_size* for longs, and *( current_ticker_price?- avg_position_price?) * position_size* for shorts.

I repeat: 10 * 1000 * (100 + 50) = 1,500,000 BYTES per second (ie 1.5 megaBYTES per second) Which is 15 megaBITS per second (approx). Sent: Thursday, December 28, 2023 12:35 AM To:

Thanks for all the replies.? I feel much better.

Do you (anyone) find cloud services useful? Thank you.

10 instruments, the busiest ones, maybe 50 Kbps at the open total, and half that the rest of the day.? Maybe 100Kbps tops when something huge happens for a brief minute.? So your 100MB is enough to

Oops, sorry you said your connection was 100 Mbps, not 400 Mbps. Still 15 Mbps is a low level of utilisation, only 15%, so still no problem. Richard Sent: Wednesday, December 27, 2023 10:56

It’s not easy to give a precise answer, but let’s make some very broad assumptions that will give us some kind of indication. Assume: * Each tick-by-tick stream generates 1000 events per

Hi, how to retrieve unrealied pnl for the current open position only? existing call back method includes previously closed positions pnl also into unrealised pnl. Thanks Anil

Hello, suppose I need to receive 10 tick-by-tick streaming data from my api, what is the right internet connection speed requirement?? Right now, my ISP has 100 MB and I am not sure if it is