fbpx

Curious to hear what latencies are required of a trading system to be competitive in this space (measured as reaction to mkt data, calcs, etc & out to mkt). Appreciate any thoughts & insights.

(Last Updated On: July 21, 2011)

Curious to hear what latencies are required of a trading system to be competitive in this space (measured as reaction to mkt data, calcs, etc & out to mkt). Appreciate any thoughts & insights.

—-

Based on prior questions you’ll need to narrow down this question a fair amount to propagate a good discussion.

—–

currently <10us tick to trade.

—-

Yes – that is correct.

—–

currently <10us tick to trade.

—-

10us is the latency inside your system, without network latency?

—–

Yes, from receiving tick till send trading order from client system, will be measured at the border of client’s system.

—-

And what techonogies do you use to archive this? Real-time linux with kernel-bypass drivers and some pretty fast messaging?

Real-time Linux don’t reduce avg latency, it just make some guarantees that discrete work will be completed within pre-known time.

No, kernel bypass drivers isn’t needed for that, primary source for latency degradation is your software. My approaches based on some principles:
1. In-memory operations, SQL databases inappropriate at the realtime system’s level
2. Atomic operations with lock-free structures, avoid use of mutexes etc
2a. Threadpools with management facilities
3. Logical locking vs system services
4. Pre-allocated memory blocks with efficient memory management
5. At the critical points, avoid use any frameworks and standard library with development of high-efficiency very specialized data structures and algorithms
6. Efficient inter-machine IPC with internal messaging with zero-copy facilities
and so on

—-

I’m going the same way – thank you for insight!

—–

To be competitive should be looking into FPGAs and you cannot over-look the network.What good is decreasing the latency on your algo by 10us if your network latency in 200ms. Also, keep in mind that the further you fo down this road the harder it is to accurately monitor the latency. I recommend Corvil for monitoring, they are the only ones with proven accuracy down to the 10s of nanoseconds.

—–

Just wonder, how do you guy measure latency when it is 10us tick to trade?

—–

On my opinion – there only two ways here:
1. Specialized hardware for packets latency measurement

2. Your own application in profiling mode can place series of timestamps into structures and u will take in account an overhead for profiling.

But precise timing is very complex aspect of trading solutions.

I tried to do 2 position, and get results which satisfies me in general

—–

Would you mind share how to determine the overhead for profiling?

—-

Agree with Andrew. Timestamping NIC with Nanosecond counter in CPU cores. Add timestamps to incomming packets along with timestamps for processing steps. use logger process to write to disk. Overhead for timestamping is the extra instructions to read timestamp registers and convert to NS and send messges to logger.

—–

First, You need to warm up stack and warm up processor cores before testing.

Second, on specific architecture you need measure overheads for timestamps reading and writing by perform big iterations test to avoid caching. I thinking that is no reason to measure discrete timer requests deviation.

Third, when you measure latency, You need to avoid use of wall timer, prefer use monotonic clock.

When you did it, you will get values to overhead evaluation.

And further, when you process result of latency measuring, you need to adjuct given results by overhead values.

Another way – using specialized hardware precise timers generators such as Symmetricom, which can tuned to write counters into memory. But I didn’t try it, and this approach is interested for me, if some person tries it. I thinking that more accuracy here can be achieved.

Regards

—–

If you have spare cores, you can have one thread repeatedly update a volatile counter. How much you update the counter by can be adjusted so the counter is a nano-second timer. This works pretty well in Java, and I don’t imagine it would be a problem in C++. Its only accurate most of the time and its counter needs to be periodically adjusted as the Timer interrupt and other interrupts can cause “jumps” in time.

—–

When we’re down into micrseconds System time stamping is just not reliable enough. The jitter is too high. Time stamping must be done using specialized hardware on the egress/ingress of the algo server. There have been quite a few studies identfying the problems with system time calls.
In regards to “tick to order” the al go system needs to produce a reference tying the MD tick to the corresponding order. This can be done using a FFT field in the order message or in a seperate out of band message. It’s typically recommended to do this out of band

 

 

NOTE I now post my TRADING ALERTS into my personal FACEBOOK ACCOUNT and TWITTER. Don't worry as I don't post stupid cat videos or what I eat!

Subscribe For Latest Updates

Sign up to best of business news, informed analysis and opinions on what matters to you.
Invalid email address
We promise not to spam you. You can unsubscribe at any time.

NOTE!

Check NEW site on stock forex and ETF analysis and automation

Scroll to Top