What are the minimum possible delays for the FIX mechanism to send a FIX message from client to server?

Question

I am creating a FIX engine in C ++, but I have no reference to what would be considered a good performance number. Given network time and FIX parsing time, what would be a good microsecond time for a client to send a FIX message to the server? Also, does anyone know the current minimum possible delays expected for this simple FIX-message-from-client-server operation?

Answer 1

This will depend on how fast your FIX engine can parse bytes into a FixMessage object and, more importantly, how fast your network code is. Are you also writing a network stack? Writing a FIX engine looks simple from the outside, but in fact it is a difficult task, in which there are too many corner cases and functions that you need to cover. Are you going to support a retransmission? Asynchronous audit? FIX Session Timers? Duplicate groups within repeating groups? You should consider using an open or commercial FIX mechanism.

As for latencies, you should expect, I don’t know a single FIX engine that can go below 4.5 μs. Since the one-way total time for writing the FixMessage object to ByteBuffer transfers the ByteBuffer over the network to the server, the server then reads the ByteBuffer from the network and analyzes it back to the FixMessage object. If you use the FIX descent mechanism, the network I / O bottleneck will be the bottleneck, not FIX parsing.

To give you a few numbers, here is an example for CoralFIX , which is a FIX engine written in Java. If you can go below this, please let me know :)

 Messages: 1,800,000 (one-way) Avg Time: 4.774 micros Min Time: 4.535 micros Max Time: 69.516 micros 75% = [avg: 4.712 micros, max: 4.774 micros] 90% = [avg: 4.726 micros, max: 4.825 micros] 99% = [avg: 4.761 micros, max: 5.46 micros] 99.9% = [avg: 4.769 micros, max: 7.07 micros] 99.99% = [avg: 4.772 micros, max: 9.481 micros] 99.999% = [avg: 4.773 micros, max: 24.017 micros] 

Disclaimer I am one of the CoralFIX developers.

Answer 2

Hannibal ante portas! ,, do not waste time optimizing in the wrong place

For the highest achievable numbers, be sure to check the ASIC / FPGA solutions based on the FIX protocol. Any serial / parallel serial processing has difficult times to become faster than a parallel processor solution.

You can not get much deeper than about 25 ns when measuring the code aStopwatch.start();callProcessUnderTest();aStopwatch.stop() , but the real problems and problems are somewhere else.

To have some comparison, the 20 ns latency is just 5 meters of AOC / active optical cables in 120 Gb / s connections in colocation / HPC homes.

0: Identify reference points: avoid comparing oranges with apples

Performance tuning and minimizing latency is an exciting and wonderful effort.

At first glance, asking the world about the "least possible" anything "seems attractive, if not sexy, as is commonly heard in the latest media, but any serious attempt to answer the indicated " Lowest possible " is difficult without proper care, spent troubleshooting (if not even demystifying (especially to avoid getting MAP / COM promises) to get answers before asking / Instant Kharma / Eternal Heaven et al, you know them well enough to mention more) )

There is nothing new under the sun, for this reason ITU-T / ITU-R and the later IETF have put a lot of effort into systematically defining specifications to avoid any potential misunderstanding, the less erroneous interpretations (whether in standard definitions or acceptance tests or specifications with the minimum specifications that a product or service must meet in order to be fully interchangeable).

So, before accepting any digit , be it in [ms], [us] or [ns], I’m sure if everyone has the same link -setup S ystem- U nder- T est and with a double guarantee , for which two anchor points [FROM]-[TO] represented by the figure was actually measured.

---

1: Define SCENARIO TEST (including FIX-Protocol message) End-to-End

 ________________________________________________________________________ +0 [us]-[__BaseLINE__] a decision to send anything is made @ <localhost> | |- <localhost> process wishes to request | a FIX-MarketData | Streaming Updates | for a single item EURCHF | during LON session opening time | |- <localhost> process wishes to request | a FIX-MarketData | Single FullRefresh | for an itemset of: | { EURUSD, GBPUSD, USDJPY, | AUDUSD, USDCAD, USDCHF } | during LON session opening time | + [us]-o======< REFERENCE POINT[A] >=================================== | |- transfer all DATA to a formatting / assembly process-entity | + [us]-o======< REFERENCE POINT[B] >=================================== | |- completed a FIX-message payload to be sent | + [us]-o======< REFERENCE POINT[C] >=================================== | |- completed a FIX-message Header/Trailer/CRC to dispatch | + [us]-o======< REFERENCE POINT[D] >=================================== | |- inlined SSH/DES/AES cryptor communication service processing | + [us]-o======< REFERENCE POINT[E] >=================================== | |- L3/2 transport service protocol SAR / PMD | + [us]-o======< REFERENCE POINT[F] >=================================== | |- L2/1 PHY-device wire-on/off-load process ( NIC / FPGA )-engine | + [us]-o======< REFERENCE POINT[G] >=================================== | |- E2E transport xmit/delivery processing / latency | + [us]-o======< REFERENCE POINT[H] >=================================== | |- L1/2 PHY-device on "receiving"-side wire-on/off-load process | + [us]-o======< REFERENCE POINT[I] >=================================== | |- L2/3 transport recv/handshaking processing / latency | + [us]-o======< REFERENCE POINT[J] >=================================== | |- inlined SSH/DES/AES decryptor processing | + [us]-o======< REFERENCE POINT[K] >=================================== | |- incoming FIX-message Header/Trailer/CRC check-in | + [us]-o======< REFERENCE POINT[L] >=================================== | |- authentication / FIX-Protocol message-counter cross-validation | + [us]-o======< REFERENCE POINT[M] >=================================== | |- FIX-message requested service content de-mapping | + [us]-o======< REFERENCE POINT[N] >=================================== | |- FIX-message requested service execution / handling | + [us]-o======< REFERENCE POINT[O] >=================================== | |- FIX-message requested service response pre-processing / assy | + [us]-o======< REFERENCE POINT[P] >=================================== | [__FinishLINE__] Ready To Send anything back to <localhost> | + [us]-o======< REFERENCE POINT[Q] >=================================== ________|_______________________________________________________________ : SUBTOTAL BEFORE A REQUESTED SERVICE RESPONSE-DELIVERY STARTS ________________________________________________________________________ 

---

As an aspiration, try to imagine something similar to a single waiting time reporting structure for all suppliers (or for your internal Dev / Test team developers), like this example.

---

2.Define FULL CONTEXT (including when / what background parallel actions (workload / noise) you are testing)

Answer 3

If you need the lowest latency, then the FIX client and the FIX server must be on the same server, even in the same application, using an IPC solution like disruptor

Answer 4

I attended the presentation of the Singapore Stock Exchange several years ago. They recently acquired the Nasdaq OMX platform and announced the shortest reconciliation time at that time of about 8 microseconds if messages were sent via their own protocol. Then they said they support FIX, which would lead to 2-3 microseconds in addition to the reconciliation time ...

I suggest that you can use this number in 2-3 microseconds as a kind of FIX minimum overhead, which the exchange is claimed to have reached most quickly :)