Shared from my desk:
I am unable to catch the rule used by IBKR for pacing reqHeadTimestamp. But there is one!
But I got the feeling that exhaustive scrutation is disliked by IBKR and a batch does worst than interwoven request.I rarely have pacing violation with reqHeadTimestamp, It simply take forever to answer (and for some combination it simply never answer, like VICI/NYSE/CONID)
I "feel" pacing rule to be partly handled in TWS or GW, as it seems that disconnect/reconnect will improve your chance to retry successfully sooner.
It seems also related to reqHistorical, and all alike data activities, the more data requests you do, the less chance that reqHeadTimestamp run trough. Somewhere that make sense.
I feel an unsound practice to call reqHeadTimestamp at each reqHistorical.
With the caveat that there seems to be a multiplicity of headstamp, they differ for each exchange and also with the Whatoshow.
I default to "SMART" "Trades" to get a worst case situation but doesn't mean IBKR doesn't have more data available on a specific case.
I do caching of it, general update once a month. Seems enough.
Batch size of 150. The first 30 generally come fast, the next 70 are painfully slow, and sometime I am lucky enough to get the last 50.
With a cool down period of 2 hours, take about 10 days to update all US. (may it can be done at faster pace, was fast enough for me and no time to dig more)
I never do parallel calls on reqHeadTimestamp. This seems worst than waiting each answer to trigger next request if you want to improve your chance to get more than 30 headstamp quickly.
?
