Your first paragraph is not really true. For financial data UDP multicast is more efficient and can be considerably faster than TCP, even if you need to check integrity (which isn't always the case). Most market data feeds are UDP multicast for a reason.
FPGAs can be very fast but they do have obvious disadvantages over a general purpose platform. Which can be very fast too, often fast enough. 50 microseconds should be within reach. You are right that running this stuff on Windows is not a good idea though :-). On Sun, Nov 11, 2012 at 07:35:32AM -0500, Nico Kadel-Garcia wrote: > On Thu, Nov 8, 2012 at 12:58 PM, Ariel Burbaickij > <ariel.burbaic...@gmail.com> wrote: > > If money is not a problem -- go buy high-trading on the chip solutions and > > have sub-microsecond resolution. > > > > http://lmgtfy.com/?q=high+frequency+trading+FPGA > > Seconded as a much more viable approach. The existing multicast > approach for such data is much like trying to hurl apple pies with F-6 > jets. By the time you've packaged the original data, blown it across > the wire, re-assembled it, *and tagged and checksummed it for validity > and correct packet order*, you're rarely any faster than a normal TCP > transmission. This doesn't matter much for streaming video, but when > you're talking about billion dollar stock prices and tracking and > responding to very small changes in prices of large companies, the > validity of each packet becomes critical. > > Other factors also start becoming critical. Normal kernels on aren't > very good about consistently treating one service as incredibly high > priority *and evening out the delays as they handle other processes* > too keep behavior consistent. That's why I would *never* run such > processing on Windows, between fancy graphics, unnecessary daemons, > and critical anti-virus software, you just don't know when things will > be delayed. And that's one of the many reasons that the ability to use > FPGA'a, which entirely sidestep the "what else is the kernel doing" > process, are ideal for putting on much smaller, more module devices. > And the devices don't need anything so powerful or complex as even a > stripped, optimized, BSD style kernel. (Though these can admittedly > be very lean and very fast as OS kernels go.)
