Tuesday, March 15, 2011

Program Trading Overdrive

Several decades ago Wall Street began to experiment with automated trading to respond to market moves more quickly than a human could react. They wrote programs to take a data feed in over the network, and output trading orders. The programs were viewed skeptically at first, but produced excellent returns.

As time went by they switched these programs from TCP to UDP. There was no value in retransmitting lost packets: it was too late to act on it anyway. TCP added too much latency. The UDP program traders reacted more quickly, and produced better returns than TCP.

Later they switched these programs over to a raw socket, reading in Ethernet frames and implementing any needed protocols in user space. The kernel protocol stack added too much latency, with its queuing disciplines and general bloat. The raw socket program traders reacted more quickly, and produced better returns than UDP.

Then they started running the programs within the NIC firmware, with help from the vendor. Interrupts added too much latency. The NIC firmware reacted more quickly, and produced better returns.

Now Wall Street is implementing the highest speed trading in FPGAs, pre-loaded with rules of what to match in incoming packets and what to do if found. Software adds too much latency.

Its a brave new world.

Update as this came up almost immediately: I suspect the Flash Crash of 2010 is only the beginning, but I believe we crossed that particular line long ago. I don't think the differences between 1 msec -> 10 usecs -> 100 nsecs are making us vulnerabile to out-of-control feedback loops in the stock market. We're already vulnerable, and have been for years.