There are still excessive delay or lack response after calling generic broker APIs in

[clearpicks]

I am testing the newest build of IB plugin (QuoteTrader 1060). It seems the excessive CPU problem is still not been solved yet. Just try to call buylimit, buystop, selllimit, sellstop and cancelOrders a few times (no sure how many are enough) and you will start to experience significant delay in response. In some worest case I got eSignal being freezed for about 20 seconds. The delay was measured by the time I click the mouse to call correspoinding API to the time the corresponding message is shown in the integrated message window, during which the esignal chart seems got freezen or very slow responding. The CPU usage window in windows task manager does not shoot to 100% as I reported before using older QT version.

A restart of eSignal solves the freezing problem untill I play with those APIs for a while and the slow response reemerges.

It is very likely the problem is caused by the IB pluin not being able to handle relatively frequent message exchange between IBpluin and IB TWS (although a few orders per second should really not be consider as "frequent". To proof this hypethesis, you may either click on "Buy Ask", "Buy Bid", "Sell Bid", "Sell Ask", "Buy Mkt", "Sell Mkt" buttons randomly with short interval to send out orders to IB TWS and very soon you will start to observe the delay build-up. In worst case, queued orders get hiden somewhere in QuoteTrader and get executed by IB TWS several seconds or well more than ten seconds after stoping click those buttons. Another simpler test is to create a few limit and/or stop orders for one instrument and use cancelOrder() to cancel them all. Maybe it is because IB plugin cancel those orders one by one which results in the relative large number events in short time, which has the same side effect as I click buttons frequently, the eSignal gets freezen again.

Please investigate this issue and get it fixed ASAP. If you need my testing script, please let me know. For software involving realtime communication, it is impossible to find out those bugs without a thorough test with more realistic setup. Each API works does not mean they will still work when putting them together.

- Clearpicks

[eSignal_MaxS]

>> If you need my testing script, please let me know.
Good idea. Can you provide it to us? It will help finding out the cause a lot.

[clearpicks]

My testing script is attached.

Apply it on CL F8, YM H8 or NG F8 charts. Click "UnArmed" button to enable the trading. Click on "Mouse" button, then left-click on the chart in different area to send orders to IB TWS. After create a few limit or stop orders, click "Cancel" button to cancel them. Go over this procedure a few times you will notice significant delay and freezing which becomes unbearable.

Take a look at the message window, when the problem becomes prominent, you would even observe significant delay between the message "Place order; id = xxx, contract = YYY" and the following messages "Order xxx New" and "Order xxx Submitted".

[eSignal_AlexM]

We were able to reproduce, thanks a lot. Will inform you when we will be able to address it.

[eSignal_MaxS]

Hi clearpics.

The first part of the problem has been fixed; delay between your mouse click and the moment when actual order placed has been minimized. But there are still some performance problems. For example, when you cancel a lot of orders (about 50-100) you'll notice some significant delays and CPU usage will hit about 100% for a short period of time. This problem is caused not by OBC but by WinSig itself and requires fixes on that side. Fixes will be done in the nearest releases I think.

Thanks in advance.

[clearpicks]

msendetsky,

Thank you for letting me know the progress. Do you know whether there is any chance the winsig side fixing can be done before its scheduled first maintenance release of eSignal v10, which would be out very soon?

The delay builds up even after cancelling only a few orders and sending a few orders. Could you doubt check it to make sure you have found all the buggy codes causing this problem? If possible, could you tell me what the reason was?

- Clearpicks

[eSignal_MaxS]

Yes, sure. We'll do additional testing before QT's december release to make sure that we've finally found all buggy code.

The reason was simple: each single-order change was causing a whole order set to be sent once again to WinSig. So the more orders you've sent, the more delay becomes. Finally when number of orders reaches around 1 000 or more, it becomes completely unusable.

Now there's still one more problem - WinSig is unable to effectively process a big number of orders.

[eSignal_AlexM]

Hi Clearpicks,

Currently i'm not sure if we are able to fix winsig side in maintenance release. I'll give you an answer in a 2-3 days.

[clearpicks]

msendetsky,

Thank you for the explanation though I am still not sure about the architecture of QT, Winsig and IB TWS integration. Who is responsible to maintain all the order status (order id, status, etc.), IB plugin or Winsig? Why does each single-order change cause a whole order set to be sent once again to WinSig? Do you mean the whole order set includes all orders which have been executed, cancelled as well as waiting in exchange queue? In my own test, far before the order number reached around 1000 (even less 100) I would observe significant delay.
Can you pre-release a build with the default route bug being fixed so that I can continue work on my script which needs to call cancelOrders()?

- Clearpicks

Originally posted by msendetsky
Yes, sure. We'll do additional testing before QT's december release to make sure that we've finally found all buggy code.

The reason was simple: each single-order change was causing a whole order set to be sent once again to WinSig. So the more orders you've sent, the more delay becomes. Finally when number of orders reaches around 1 000 or more, it becomes completely unusable.

Now there's still one more problem - WinSig is unable to effectively process a big number of orders.

[eSignal_MaxS]

>> Can you pre-release a build with the default route bug being fixed so that I can
>> continue work on my script which needs to call cancelOrders()?

There's no need in pre-release; this fix will be included to official QT December release (planned for today, 19th, actually).

I'll give you some brief explanation of the architecture. There's chain of components like this: [WinSig] <-> [OBC] <-> [IB] <-> [TWS]. Arrows designate how single order (it's status, changes, everything) is being transmitted. All received orders are passed to [OBC] first; as soon as new order arrives OBC must pass it (and ONLY it) to [WinSig] but in the particular case that you've found ALL orders that [OBC] have already had were being passed to [WinSig] EACH time as single order got updated; this caused really significant delays.

Finally, as soon as you use WinSig integration, WinSig is responsible for managing orders. Now some performance problems found there which need to be fixed; that's what amol is talking about in the previous post.

[clearpicks]

I just did a few paper trades to make sure I can do on chart trading on CL G8=1 chart. Then I found I even had 20 seconds delay after only three orders. The screenshot of the message window is attached.

At 10:32:12, I closed my real trading account and login into my paper trading account, which caused IB Plugin retried a few times and got connected again at 10:32:46. I placed a buy limit order (order 840) and cancelled it a few second later. Then at 10:33:15 I bought at market using "BM" buttom (order 841). When I tried to sell it using "SM" buttom, in message window it was shown "10:33:48 Place order; id = 842, ... ". But nothing happened until 10:34:08, it showed "Order 842 New" and "order 842 Filled". Was this 20 seconds delay caused by IB TWS or QT IB Plugin? Under what condition is the message "Order XXX New" displayed in the message window?

[eSignal_MaxS]

Looks like this delay was caused by TWS. Did you notice any excessive CPU usage during this operation?

>> Under what condition is the message "Order XXX New" displayed in the message window?

This message is displayed as soon as TWS notifies QT's IB Plugin about new order. In turn, as soon as TWS gets notified about order is placed by the IB Server. So it looks like your 20 seconds delay is actually a delay between these two events - order request and server response which contained your live order information.

[clearpicks]

Unfortunately I did not check the CPU usage. I was wondering why the sell market action did not close the position and forgot to check CPU usage. I hope this is only an one time incidence of IB paper trading account.

Originally posted by msendetsky
Looks like this delay was caused by TWS. Did you notice any excessive CPU usage during this operation?

>> Under what condition is the message "Order XXX New" displayed in the message window?

This message is displayed as soon as TWS notifies QT's IB Plugin about new order. In turn, as soon as TWS gets notified about order is placed by the IB Server. So it looks like your 20 seconds delay is actually a delay between these two events - order request and server response which contained your live order information.

[clearpicks]

Do you imply that even after the bugs in QT or IB Plugin being corrected, the bug in winsig would still cause large delay and freezing?

Originally posted by msendetsky
>> Can you pre-release a build with the default route bug being fixed so that I can
>> continue work on my script which needs to call cancelOrders()?

There's no need in pre-release; this fix will be included to official QT December release (planned for today, 19th, actually).

I'll give you some brief explanation of the architecture. There's chain of components like this: [WinSig] <-> [OBC] <-> [IB] <-> [TWS]. Arrows designate how single order (it's status, changes, everything) is being transmitted. All received orders are passed to [OBC] first; as soon as new order arrives OBC must pass it (and ONLY it) to [WinSig] but in the particular case that you've found ALL orders that [OBC] have already had were being passed to [WinSig] EACH time as single order got updated; this caused really significant delays.

Finally, as soon as you use WinSig integration, WinSig is responsible for managing orders. Now some performance problems found there which need to be fixed; that's what amol is talking about in the previous post.

[eSignal_AlexM]

Correct. But most probably maintenance release will contain fix for this.