Michael Durbin <[EMAIL PROTECTED]> wrote: > We are preparing to write some components with much more stringent > latency/throughput requirements than what we've done so far and are > seriously considering writing these in Linux.
Are you concerned about TCP latency or kernel latency? In the kernel space, there are linux kernels optimized fo reduce (or at least make predictable) the inherent kernel latency. Many of these are targeted at telecommunications applications where latency is mandated. Google for "Carrier Grade Linux". TCP as a protocol is not intended to provide any latency guarantees, but that happens outside any operating system or implementation space. Picking Windows over Linux or vice- versa won't buy you much if the other already has you against the wall. >From the little you've told us, I'd be much more concerned about the Windows legacy code and interoperability. These aspects of your project are beyond your control and represent a risk you cannot adequately quantify. I'm working a case now where the manufacturer (for their own reasons) has decided to discontinue their product and we have a decade or so of our work product dependent on having their hardware available. Needless to say we're feeling a bit blindsided by this right now. If there is an interoperability interface you can shoot towards (where you can say you're going to let one OS own this side and the other one own that side) you can at least partition the risk and build substitute components for one side while leaving the other alone. Once you get down into the code, however, it's pretty much all the same, I'd expect. If you're /really/ stressing the system, you may need the extra control you get with something you can own (Linux, Free Software, etc.) -- Steve Holton [EMAIL PROTECTED] "Convenience causes blindness. Think about it." -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
