[This message was posted by Ian Hoenisch of ESP Technologies LLC <[EMAIL PROTECTED]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/cf99d4c2 - PLEASE DO NOT REPLY BY MAIL.]
Whatever solution you chose can NOT involve the downstream system to insert/modify/etc any tags. Also, the clock slew you'd try to contend with makes any 2 clock system invalid. You have to measure on a single system, so you have to use an echo type of solution, where you 1. send a message, start timer 2. receive the return msg, stop timer 3. Calculate difference Ian > What if the counterparty FIX Driver does not provide the time it > received a message truly instead puts a time which "makes it look > faster"? as a developer, to make my FIX engine and Trading application > faster, I populate this new Tag RelatedRequestMessageReceiptTime (1427 > since 1426 is the last used tag number in FIX.5.0-SP1) as Sending time > (52) of my out message minus 10 milliseconds - so always my system would > appear to have 10 ms response time. > > Its the same logic like what Ryan stated "a system with slow business > logic might persuade their engine vendor to implement PI/PO messages in > the engine itself". There is no end to this kind of cheating. > > > I agree with Ian. If a FIX Driver that receives a message would > > include the time received & the time the response is sent back, to the > > microsecond, when it acknowledges, processes (e.g. trades) or rejects > > a message (e.g. order), then we would know the total time used on the > > far- end as a black box. Subtract this from the total time as recorded > > at the sender and you can determine the bi-directional in-flight wire > > time regardless of any clock-drift between the machines. This > > information is very useful, and it would be additionally nice to see > > it collected & returned for each hop. > > > > Thanks! -Joey > > > > > Hi guys, > > > > > > One point to ponder, if you try to measure at the application layer, > > > you have to make sure you have consistent application performance, > > > otherwise your test results will be skewed by what the CPU is doing > > > at the time (i.e. shared with other apps). > > > > > > A better approach may be to look at the network level. Tying the > > > outbound message with the return message, tricky, but do-able. Then > > > measure the latency difference between the messages will give you a > > > much more precise external latency measurement. > > > > > > Ian > > > [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
