[This message was posted by Mahesh Kumaraguru of <[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/0e266a28 - PLEASE DO NOT REPLY BY MAIL.]
We cannot compare the round trip from PI-PO with other message type like D-8 or V-WXY. The comparision would be between PI-PO messages at different times. For example at start of day PI-PO took 70 milliseconds, mid day its taking 120 milliseconds, then we can conclude that midday the latency is more. Since PI-PO messages can be sent by either side buy and sell, they could both send it around same time and compare values which cannot be done with other business messages like D-8 etc. 1-0 can be used bidirectionally, but as I mentioned in my previous post in this Thread, 1-0 covers only time between FIX engines not between end Applications. "All" FIX users need not use these messages just because they are present. Those who find use for it would use it and those you do not find any use for it do not use it. I am just adding a new tool which is presently not in the FIX toolkit in the hope it is found useful. > > > > 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 am sure that PI/PO messages will not give you a real performance. > Let’s say you are running some broker-dealer company executing > customer orders. In this case you have to consider what exactly > performance you want to measure. I have two ideas: > > 1) Minimum, maximum and average time of order confirmation. This is > a time between the order was sent by client and confirmation > received. This should be measured on client side. You may also > measure the same on server side to figure out the network > latency, yours and your client’s performance. > 2) The quality of execution, how quickly client receives > executions. > > In both cases described above, PI/PO messages will not give you any > result. Just imagine how these messages will be processed. In real life, > your server will be loaded with business logic processing orders, > maintaining the book, asking dark pools for liquidity, routing orders to > the street etc. All these tasks requires a large amount of work to be > done and, therefore, takes time. To process PI message and reply with PO > server has almost nothing to do. Finally, when two of these tasks are > being processed in parallel, client might experience a performance > issues but will always get quick reply to its PI messages. > > Some time ago, for one of our client I have done a simple utility to > measure performance. The delays were calculated in milliseconds between > the time when original order was sent and the time when confirmation was > received for that order. The following chains was considered as a > request/response: > > New order request / Execution report “New” New order request / > Execution report “Partial Fill” (only if Execution report > “New” was not received for given order) New order request / > Execution report “Fill” (only if Execution report “New” was > not received for given order) > > Order cancel-replace request / Execution report “Replaced” Order > cancel-replace request / Execution report "Filled” Order cancel- > replace request / Order cancel reject > > Order cancel request / Execution report “Cancelled” Order cancel- > replace request / Execution report "Filled” Order cancel request / > Order cancel reject > > It worked pretty well with FIX engine log files in both real-time and > overnight modes. > > There are many other ways to get this information. For example, you can > use “tcpdump” utility, parse the packets and calculate delays using > information from network packets. But there is absolutely no reason to > have PI/PO messages unless you want to measure time of processing > exactly those messages and maybe cover some network latency. > > Best regards, Vlad Lazarenko [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 -~----------~----~----~----~------~----~------~--~---
