Re: Business level functionality for consideration: ability to define message timeout for latency sensitive messages
Nathan Kidd / NMK Consulting Ltd
12 Jan 2011 11:06AM ET
Hi,
The problem I see (which seems quite relevant to this group) is that you cannot know when sending a message (especially via TCP) precisely how long it will take for that message to reach its ultimate destination.
If you know in advance that an order is very latency sensitive (for example trying to take advantage of on opportunity during a period when a market is very volatile), it might be useful to provide the timeout functionality as an optional restriction that can be applied to the message.
Where the restriction is not specified (which would be the case for most non-high frequency market participants) there would be no impact on performance.
Where it is specified, the performance impact would need to be tested. My guess is that this will IMPROVE matching engine performance. Since it is only likely to be specified at times of high volatility, it could actully reduce the number of orders which are matched, thereby reducing the amount of work that the matching engine needs to do.
I don’t think it could be implemented using the sweep mechanism as that assumes that the order will rest in the book?
Cheers
Nathan
> Nathan,
>
> I agree that enabling the message sender to determine the TIF of an order would be nice, but am doubtful that such a regime is feasible (granting in advance that I am no expert on the subject of clock synchronization).
>
> I would think that in order for such a regime to work, the order would have a timestamp. On receipt by the matching engine (the definition of such act being non-trivial), the matching engine would have to compare that timestamp with its own clock, evaluate the TIF instruction, and decide whether to discard the order.
>
> Presumably, this regime would have to apply to all inbound orders. The operation takes time and thus each inbound order would be taxed with some marginal delay, even when the owners of those orders do not wish to avail themselves of the feature.
>
> In essence, this regime adds complexity to the matching process and the cost of that complexity would be socialized.
>
> I stand to be corrected on my analysis, but to the extent it is valid, I would prefer for matching engines to play god on TIF instructions. On some type of cycle (probably determined by the OS), books can be swept for TIF validity. I think that is the most efficient, least complex approach.
>
> Best,
> John
>
>
>
> > For example, we might want to allow a client application to specify on an order message, that if the message does not reach the matching engine within 15ms of the sending time, the matching engine should discard the message.
> >
> > It could be seen as a high resolution extension to the current time in force logic, or as a new type of more generic message restriction that can be applied where supported.
> >
> > Downside is that it would require clocks to be kept tightly in sync. That could possibly be established during session initialisation however....
@FIXProtocol
