Mokwit, You want the ability to force a reconnect, without shutting down TWS and restarting it. I suggested that a long time ago, as a partial way to work around the magenta order problem. They granted my wish. Just hold down the <CTRL> and <ALT> keys, and type the letter "r" while doing so, and then wait a few seconds while TWS reconnects. This will almost always clear your magenta orders immediately.
Jim Thanks 1) Confused about "the and " keys please clarify. 2) IB thanks for listening. mtzianos Forgot to mention that I had serious delays with market orders seemingly unrelated to market liquidity/conditions. Made using a 'reverse' function impossible - solved the slowness by programming hot keys in Buttontrader to execute a marketable limit which seems to solve the problem even though I would have thought what gets sent to the exchange is the same.
Sorry, mokwit, I used angle-brackets to denote the CTRL and ALT keys, but the elitetrader software treated my punctuation as macro commands, so the text was not posted. You hold down the CTRL and ALT keys, and while doing this, you hit the "R" key, wait a few seconds, and then you are back in business.
Mokwit, about your delayed order executions, you should give specifics. What were you trading? Exactly when did you submit your order? What happened or didn't happen or was too slow? If you are trading equities, then, with enough specifics, it should be possible to narrow the problem down to the point where IB can be asked to fix it, or at least to explain it. It's all about details. Your description of the problem is too vague to be meaningful. I am eager to hear details, because your problem is an opportunity to improve IB order routing and execution. Please give details.
It was with futures and basically involved very slow execution with what appeared to be excess slippage relative to conditions, not experiencd since I stopped using market orders. Using a Reverse function with 2 different front ends both showed the same problem - sometimes around 30 ticks USD200/contract was typical slippage when using reverse function in HSI but some of that must be attributed to market conditions not latency. Your point is valid, and I agree details such as audit trails etc would help IB narrow it down but I have not used Market orders for entry for some time due to this issue. Myself and others have previously posted greater detail in previous threads participated in by IB. I seem not to experience the problem on exit except with SPI, but that may not be IB it may be the SNFE matching engine as others are fine on exit and slippage is not a factor so I suspect it is a SNFE delay in confirming execution. I noticed it with HSI the most but also if I remember correctly with other exchanges and I think also with IDEALPRO. I still see it in SPI exiting with a MKT order and saved screnshots, audit trails and a log file which I may still have, but I suspect it may be now too old for IB to be able to use. At the time I had had enough of sending emails to IB over the multiple issues (which seem to have been addressed ) and did not bother to send it. As it happens only on entry and not with marketable limits or stop limits, I suspect that the problem may be some issue with the code/process for margin checking or order building with a market order not present in a limit order, but that is just a guess.
Mokwit, Recall that IB simulates market orders for SPI and HSI. This means that IB never sends a market order for those contracts. IB instead uses an algorithm, by which it sends a limit order with a limit price generated by the algorithm, and then sends a series of cancel and replace operations to alter that limit price repeatedly, until all the size has executed. If the re-pricing algorithm has a bug, or if the algorithm is designed in such a way that it does not match the structures and behaviours of the particular vehicle or market you are trading, then it can cause very lengthy and expensive delays. It can, for example, persistently submit prices which are too conservative, so that by the time they reach the order-matching engine, the market has already run away from your order. This can happen over and over again, to the same order, while the market is rapidly moving, so that you will have price-->delay-->reprice-->delay-->reprice-->delay, etc., etc., producing a costly and outsized delay, instead of the immediate execution which would result from a better algorithm. I have detected such problems in U.S. equity executions, and I have analyzed them in detail and persuaded IB to fix them. If you take a very detailed, blow-by-blow approach to analyzing both time and sales, and your audit trail, and get some specific info on exactly how IB reprices its simulated market orders on SPI and HSI, then you will be in a position to diagnose the problem, either on your own or with the help of IB developers, and then you can help them fix the problem so that you will be able to use market orders with confidence for SPI and HSI. The hard part is persuading the developers to communicate with you. Customer service employees are mostly incapable of helping with these problems, but there are a couple of CS guys who are exceptions and can sometimes be helpful with these problems. You might have to complain to IB management in order to get attention to your problem, or you might have to start a thread. If market orders would help you, then you should probably consider working with IB to get this problem fixed.
Jim thanks, if there is multiple repricing rather than sending as a marketable Limit with wide limit it maybe explains why IB synthetic Market is slow and marketable LIMIT and STOP LIMIT is not. I assumed they sent a marketable limit up to the exchange maximum when creating synthetic market orders. It would be very easy for a repricing algorithm designed for equities or even other futures markets to submit an overly conservative limit in HSI and cause multiple repricing and therefore delays. I have to be fair and say that IB have opened the channels more and also addressed many of the issues raised by myself and others, but even so, from past experiences I am reluctant to go to all that work if I am going to have the kind of experience that I had when i reported a problem with a stop being blown through. e.g the IB rep refused to accept eSignal T&S as valid and IB is of course snapshot. I have had good service from the more technical CS reps, but generally i get irritated that they are being paid a salary to do this but seem to expect the customer to do all the work. Bottom line is that I have found a workaround via marketable limits (a better option for HSI) and using wide(ish) STOP LIMIT as my hard stop, and am not going to generate audit trails for slow reversals at USD200/per.
I would suggest IB to add a dynamic trailing stop. The trailing offset would decrease as underlying increases until it reaches an absolute offset. Ex: Buy QQQQ at 38. Set original trailing stop offset $1.00 Set absolute trailing stop offset $.20 Then if QQQQ goes up to 38.5, the trailing offset is reduced to $.50. If QQQQ = 38.8 then trailing offset = .20 and stays there even QQQQ continues to go higher. That feature would allow a trader to lock in profit when underlying goes up to certain level without manually adjust the trailing stop offset.
I was told by the IB help desk that the only way I can know if IB trades a specific OTC issue is to enter it into the TWS. It would be a lot better for me if I had access to a list of all the OTC issues on the IB website when I am screening out my stock universe for trading.