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.)
