开云体育

Just after 15:10 US/Central this afternoon, I request Historical TickByTickLast data for Friday's NQZ3 session (20230928 17:00 through 20230929 16:00 US/Central):

• I received 451,009 TickByTickLast objects for NQZ3
• It took 445 requests/responses and 1,045 seconds to receive all data
• that is an average of 2.347s per request (elapsed time)
• but the median was sub-second at 0.659s.

We don't download historical data a lot so we did not put a lot of thought into the little tool:

• it is a single threaded event processor (no sleeps, delays, or built-in pacing)
• requests data in 1,000 tick chunks in reverse time order
• converts each returned TickByTickLast into a relatively expensive immutable Java object
• accumulates the objects in a list that is serialized into streamable Json objects and written to file each time more than 10,000 ticks have been accumulated

That means the tool makes about 9 out of 10 requests immediately (a few micro seconds) after the callback for the previous request. There is a short processing delay before every tenth request (5ms to 40ms) for the data serialization and file storage.

Now, the interesting finding is the discrepancy between average and median response times. IBKR paced the responses within chunks of ~60 seconds, each time with roughly the following rhythm:

• Ten requests with response times around 600ms each
• One request with 3.5 seconds
• Three requests with 600ms each
• One request with 4.5 seconds
• One request with 600ms
• One request with 5.5 seconds
• Three requests with 6 seconds

• One request with 12 seconds

Attached a couple charts of what that looked like. I do not have data on how long they keep that 60 second chunk rhythm up in case you download a couple years worth of data. My gut tells me that you will not be able to keep up the less-than 3 second average for very long runs.

闯ü谤驳别苍