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 On Thu, Nov 8, 2012 at 6:36 PM, Johan Beisser <j...@caustic.org> wrote: > On Thu, Nov 8, 2012 at 4:12 AM, Dan Shechter <dans...@gmail.com> wrote: > > Hi All, > > > > <current situation> > > A windows 2008 server is receiving TCP traffic from a stock exchange > > and sends it, almost as is, using UDP multicast to automated high > > frequancy traders. > > > > StockExchange --TCP---> windows2008 ---MCAST-UDP----> > > > > On average, the time it take to do the TCP to UDP translation, using > > winsock, is 240 micro seconds. It can even be as high as 60,000 micro > > seconds. > > </current situation> > > > > <my idea> > > 1. Use port mirroring to get the TCP data sent to a dedicated OpenBSD > > box with two NICs. One for the TCP, the other for the multicast UDP. > > You'll incur an extra penalty offloading to the kernel. Winsock is > already doing that, though. > > > 2. Put the TCP port in a promiscuous mode. > > Why? You can just set up the right bits to listen to on the network, > and pull raw frames to be processed. Or, just let the network stack > behave as it should. > > > 3. Write my TCP->UDP logic directly into ether_input.c > > Any reason to not use pf for this translation? > > > </my idea> > > > > Now for the questions: > > 1. Am I on the right track? or in other words how crazy is my idea? > > Pretty crazy. You may want to see if there's hardware accelerated or > on NIC TCP off-load options instead. > > > 2. What would be the latency? Can I achieve 50 microseconds between > > getting the interrupt and until sending the new packet through the > > NIC? > > See above. You'll end up having to do some tuning. > > > 3. Which NIC/CPU/Memory should I use? Money is not a problem. > > Custom order a few NICs, hire a developer to write a driver to offload > TCP/UDP on the NIC, and enable as little kernel interference as > possible. > > Money's not a problem, right?