[This message was posted by Vladyslav Lazarenko of Jet SnaiL, 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/55adcc19 - PLEASE DO NOT REPLY BY MAIL.]
>
> 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
-~----------~----~----~----~------~----~------~--~---
