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?
