[foobar10000]

You generally want the following in trading:

* mean/med/p99/p999/p9999/max over day, minute, second, 10ms

* software timestamps of rdtsc counter for interval measurements - am17 says why below

* all of that not just on a timer - but also for each event - order triggered for send, cancel sent, etc - for ease of correlation to markouts.

* hw timestamps off some sort of port replicator that has under 3ns jitter - and a way to correlate to above.

* network card timestamps for similar - solar flare card (amd now) support start of frame to start of Ethernet frame measurements.

[malwrar]

> mean/med/p99/p999/p9999/max over day, minute, second, 10ms

So basically you’re taking 18 measurements and checking if they’re <10ms? Is that your time budget to make a trading decision, or is that also counting the trip to the exchange? How frequently are these measurements taken, and how do HFT folks handle breaches of this quota?

Not in finance, but I operate a high-load, low latency service and I’ve always been curious about how y’all think about latency.

[elteto]

How does rdtsc behave in the presence of multiple cores? As in: first time sample is taken on core P, process is pre-empted, then picked up again by core Q, second time sample is taken on core Q. Assume x64 Intel/AMD etc.

[khold_stare]

In trading all threads are pinned to a core, so that scenario doesn't happen.

[foobar10000]

Yeap!

Also - all modern systems in active use have invariant tsc. So even for migrating threads - one is ok.

[elteto]

You could still have a receiving thread and a sending thread for example, so it’s not as simple.

But googling suggests that if the CPU has the invariant_tsc flag then it’s not a problem, as foobar mentions.