Latency calculation

, ,
1

Imported from previous forum

2

I would like to know how the latency is to be calculated. Is that by system wide message delivery through multiple line handlers? Is that the time between an order message send out, and an Order ack received a latency?

3

I would like to know how the latency is to be calculated. Is that by
system wide message delivery through multiple line handlers? Is that
the time between an order message send out, and an Order ack received
a latency?
I tested with a single FIX session, and delivered 5000 messages in a second.

4

I would like to know how the latency is to be calculated. Is that by
system wide message delivery through multiple line handlers? Is that
the time between an order message send out, and an Order ack received
a latency?
I tested with a single FIX session, and delivered 5000 messages
in a second.

Latency is a generic term, it depends on the level at which you are interested in calculating the latency. From connectivity point of view on buy side perspective, Latency is measured as the response time on your order messages. It is the time difference between your order message leaving your FIX gateway and the response (typically Ack)received from your couterparty. You can observe the latency by looking at the time stamps on your FIX logs Inbound and Outbound messages.

5

Latency can mean several things, as stated above.
I think the three most relevant figures are
-One way: Time it takes from the source to the destination. Which is in fact very hard to get unless you control both ends.
-Round trip, which is an end to end latency between an order was sent and the acknowledgment was received. Doesn’t work for one way messenging (like market data).
-Hop to hop: the time it takes for a message to travel through a specific set of software and hardware routers.

This can be done at the software level (aka looking at time stamps or log times), or at the network level (packet timestamps).
Although software is the easiest approach, it has several inherent flaws. Indeed, what you are seeing in a log is the time the software understood the message and printed the message (after message was buffered in the network layers, repackaged, read, decoded and formatted), which might be quite different from the time it was received.

You may also want to bear in mind that if a message travels through multipler servers, their system time will not be synchronized.

In my humble opinion, the two must important numbers are:

  • What is perceived by the end user. Which has quite poor granularity (Wow, Ok, Fire the IT guy).
  • What gets published in your company PRs. Which is a surprisingly low number that only happened once in completely unrealistic conditions.
6

Latency can mean several things, as stated above. I think the three
most relevant figures are -One way: Time it takes from the source to
the destination. Which is in fact very hard to get unless you control
both ends. -Round trip, which is an end to end latency between an
order was sent and the acknowledgment was received. Doesn’t work for
one way messenging (like market data). -Hop to hop: the time it takes
for a message to travel through a specific set of software and
hardware routers.

This can be done at the software level (aka looking at time stamps or
log times), or at the network level (packet timestamps). Although
software is the easiest approach, it has several inherent flaws. Indeed,
what you are seeing in a log is the time the software understood the
message and printed the message (after message was buffered in the
network layers, repackaged, read, decoded and formatted), which might be
quite different from the time it was received.

You may also want to bear in mind that if a message travels through
multipler servers, their system time will not be synchronized.

In my humble opinion, the two must important numbers are:

  • What is perceived by the end user. Which has quite poor granularity
    (Wow, Ok, Fire the IT guy).
  • What gets published in your company PRs. Which is a surprisingly low
    number that only happened once in completely unrealistic conditions.

Can’t agree more with Jean here! Latency is indeed only as low as it is perceived by the end user. Having worked on numerous latency issues, its up to the sell side to NOT rely just on what they see (app logs/network logs etc…)A good start would be to

  1. Get some kind of feedback (i-e logs) from the end users
  2. Set realistic expectations

Diff buy sides measure latency in their own way and hence have to be looked at differently.