CME roundtrip question

elabunsky

elabunsky

Hello!

May I ask about CME roundtrip latency if trade DMA from the AURORA?
I need any estimation for latency of this steps: get quote from the CME, parse it, send order to CME and get recieve report from the CME by CME timestamp time.
I understand that sometime CME can freeze and and send quotes with some delay and matching can freeze. But what is biggest delay and final roundtrip latency?
I'm trying estimate roundtrip latency for my own HFT algorithm. I need 500-650 microseconds from the get quote and recieve the report from the CME by CME timestamp time. Is it possible?...
 
the latency on the exchange side is the same for everyone connecting to the exchange. So like the tide, everyone goes up and down with it. Once you make sure you are connected in the most efficient way, the right network cards, it configuration etc... then all you can optimize is your side.
How much time does your system need to get the quote, process and send an order in response?
 
Here are some numbers on the latency of CME's FIXFAST feed using b2bits's parser:
http://www.b2bits.com/performance_lab/cme-fixfast-market-data-adaptor.html

this benchmark is on not-very-impressive hardware running on windows... so im pretty sure it could be optimized by moving to a thinner OS...
-- edit --
:) found a test done on a high performance stack! using RHEL :) on the same parser
http://www.b2bits.com/performance_l...enna-cplusplus-in-high-performance-stack.html
It also includes a chart comparing the performance of on Open Source parser... should be helpful to benchmark your own parser
 
Last edited:
eusdaiki said:
Here are some numbers on the latency of CME's FIXFAST feed using b2bits's parser:
http://www.b2bits.com/performance_lab/cme-fixfast-market-data-adaptor.html

this benchmark is on not-very-impressive hardware running on windows... so im pretty sure it could be optimized by moving to a thinner OS...
-- edit --
:) found a test done on a high performance stack! using RHEL :) on the same parser
http://www.b2bits.com/performance_l...enna-cplusplus-in-high-performance-stack.html
It also includes a chart comparing the performance of on Open Source parser... should be helpful to benchmark your own parser
More...

This is internal latency. I need to know about CME latency.
 
You have to contact an IT hosting firm in that facility to get accurate info. Do you know who you will be using? Who is your FCM?

1245
 
1245 said:
You have to contact an IT hosting firm in that facility to get accurate info. Do you know who you will be using? Who is your FCM?

1245
More...

They do not say nothing about latency... I tried via Rithmic and have 500-5000 microseconds roundtrip.
 
elabunsky said:
They do not say nothing about latency... I tried via Rithmic and have 500-5000 microseconds roundtrip.
More...

The times you are quoting through Rithmic include the time it took for your order to be processed by the exchange. These times are variable based upon the workload of the exchange and have very little to do with Rithmic's exchange connection, equipment or software.

For true CME latency we found that orders passed our tap on the way to the exchange and tcp ack's came back to the tap in 15 - 16 microseconds, very consistently (our tap sits between our routers and the exchange's routers so the times across our tap do not include the time across any of our other equipment). I expect that such a round trip time will be experienced at all exchange connections in Aurora.

The time a trader will experience will include time through the equipment his orders pass and the time through the software he uses. 500 microseconds from the release of an order to the exchange by our software until the receipt of a fill message from the exchange or even an order acknowledgement from the exchange does not seem very slow (though you were able to realize less than 375 microseconds). Not too long ago 2 milliseconds was the best the CME could do.
 
You must log in or register to reply here.
Back
Top