2009 May 16 - Sat
High Performance Messaging
The most mention I hear of low latency trading is from data vendors who say their market data feeds are 'the best' because they are
nearest the data source, and that their infrastructures have been designed for high availability and performance.
I've always thought though, that market data source adjacency forms only a portion of the overall delay budget. It seems to me that
'closeness' to the execution side of things is just as important, if not more so. This is confirmed through some articles I've recently
seen that discuss some colocation facilities situated to optimally provide this 'betweenness', aka
Smart Proximity Hosting.
The third aspect of low-latency trading resides within the compute engine, the engine that receives market data, calculates the
trades, performs risk management, sends out the execution requests, and receives the execution confirmations. Copying data from and into
packets as well as receiving and transmitting them can be a time consuming processing. Buffer management is a serious consideration in
high frequency trading scenarios (the concept of high-frequency trading being intimately intertwinded with the concept of low-latency
market data feeds).
I came across
Topics in High-Performance Messaging in relation to someone's generic
question about how to test throughput on links. Buffer sizing is one of many important topics in optimizing throughput and reducing
latency. This paper makes obvious many of the hidden gotchas for the compute engine, the links (how many, what kind, and how they are
joined), the feed types, and the supporting L2/L3 infrastructure. Even though I came across it as a generic response to throughput
testing, I see it is written by a group that has spent much time on investigating low-latency issues in trading. I see the article as
being very usful for optimizing additional milliseconds/microseconds out of the execution cycle time.
Another view on this low-latency issue arises in a blog entry from The Blog of James:
Does the need to process volumes of data prohibit lower latency?
There is a news site dedicated to news regarding low latency trading issues:
low-latency.com.
[/Trading/AutomatedTrading]
permanent link
Martians
In terms of managing addresses on for the public internet, there are a set of address
ranges which one should never see... publically. Privately, that is, within someone's local
network, they can be seen, are seen, and should be seen.
- 0.0.0.0/8: not seen as an address but as a default route.
- 10.0.0.0/8: a common internal rfc 1918 range.
- 127.0.0.0/8: localhost addresses, ie, loopbacks on individual machines, with 127.0.0.1 the most common. I've used addional
addresses for setting proxy forwarding with ssh port forwarding configurations
- 169.254.0.0/16: rfc 3927 for internal networks without dhcp and no addressing
structure
- 172.16.0.0/12: a common internal rfc1918 range.
- 192.0.2.0/24: rfc 3330 for documentation and example code
- 192.168.0.0/16: a common internal rfc1918 range.
- 198.18.0.0/15: rfc 2544 network benchmark tests
- 223.0.0.0/8: reserved
- 224.0.0.0/3: multicasting
More information on IPv4 addressing can be found at Wikipedia.
[/Networks]
permanent link
|
