[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/e61537c4 - PLEASE DO NOT REPLY BY MAIL.]
> Then there is no use for a new Tag if the measurement is from the time > my system sends a Business message and receives its associated response > Business message. > > Then the only way is to collect real latency statistics is using > real business messages during real load times when the same > hardware is running all applications that are used in real > production trading periods. I fully agree with that. For example, the remote end could fool a quicker response to the PI/PO or other new msg types. As you point out below, it can be fooled. It could be used to give you a rough idea but I prefer to see the real performance our customers experience on their trades instead of a rough idea. > > I suggested PI and PO messages as a "tool" to measure end to end round > trip time and the truth is "any tool and be fooled" :-( > > > 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 -~----------~----~----~----~------~----~------~--~---
