hey guys. i again have another overly technical trade problem i am hoping someone on ET has some insight into. basically i have an automated system simulating a peg to market order on a globex product. this is what i see on my audit trail. -PlaceOrder BUY 2 XYZ 1.12 @ 7:34:45 gmt -100s of ModifyOrder over the next 20 min. -ModifyOrder BUY 2 XYZ 1.11 @ 7:54:26 gmt -15 other ModifyOrder over the next 34 seconds at varying prices. all below 1.11. spaced out 1-3 seconds between modifies. -ModifyOrder BUY 2 XYZ 1.08 @ 7:54:55 gmt -Filled BUY 2 XYZ 1.11 @ 7:55:01 gmt -15 Rejected Orders corresponding to the 15 after the 7:54:26 modify. this is originally what confused me. basically 34 seconds of modified orders never reached the exchange it seemed. after talking to IB tech to try to under what happened the timeline they see in their logs goes something like this. -PlaceOrder BUY 2 XYZ 1.12 @ 7:34:45 gmt -100s of ModifyOrder over the next 20 min. -ModifyOrder BUY 2 XYZ 1.11 @ 7:54:27 gmt - 10 ModifyOrder BUY 2 XYZ all below 1.11 all arrived at 7:54:47 within 1 second of each other. -Filled BUY 2 XYZ 1.11 @ 7:54:49 gmt -5 ModifyOrder BUY 2 XYZ -Filled Confirm BUY 2 XYZ 1.11 @ 7:55:01 -15 Rejected Orders corresponding to the 15 after the 7:54:26 modify. there are two troubling differences between these audit trails. -first IB's log shows that the filled response from globex arrived at IB at 7:54:49. but was not sent to my TWS until 7:55:01 (12 seconds later). -second even though according to my audit trail 10 modify orders were sent out after the 1.11@7:54:27 order, spaced out one modify every 2-3 seconds, IB's log shows all these modifies arriving in one big bundle within a second of each other at 7:54:47 (too late to prevent the 1.11 fill@7:54:49) i know that the default time-to-live value for a TCP packet should be nowhere near 20 seconds, so the spaced modifyOrders which ended up getting bundled together could'nt have been delayed somewhere on the net. and the delay must have occured before they were put into TCP packets or after they were read out of the packets. this leaves me with two possible ideas of what could have happened for the 'second problem'. either my TWS was receiving the modifies but not transmitting them for 20 seconds, then sends them all together within a second, or IB's message server received the modify orders over the 20 seconds but did not pass them to the system which logs them / forwards to the exchange until 7:54:47. as for the 'first problem' I have no idea why IB would delay telling me I had an order filled for 12 seconds. does anyone else have any ideas or insights?