John- >> Which part of the Linux issue... sustained throughput or latency? I >> wouldn't be surprised to find that latency >> hasn't >> improved substantially because it's not a priority for server software. >> Even VoIP applications are not concerned >> about a 1 msec improvement... whereas that makes or breaks a wireless MAC. > > I know that in the early days of Linux development, David Miller spent > a lot of time making sure that the Ethernet layer could reliably send > and receive more than 1 MByte/sec via TCP over 10 megabit Ethernet, > and more than 10 MBytes/sec over TCP on 100 megabit Ethernet. I watched > his measurements and his kernel evolve to make it happen (learning from and > improving on Van Jacobson's early work making 68000-based Sun-2's move >>1MByte/sec over TCP on original Ethernet). > > You might say, "That's only 90%, surely he can do better," but > that's 90% of the raw bit rate, delivered flow controlled and error-free > at the TCP socket layer (all the overhead, from interframe spacing to > preambles to CRCs to packet headers, goes in the 10%). > > As you might expect, pumping the data through required keeping all > parts of both systems working in overlap. "One packet being assembled > to transmit, one received packet being picked apart, and one packet > flying on the medium", at all times. If these two software jobs can > both run in one packet time, you win (and don't need much if any > buffering, keeping latency very low). These code paths were heavily > scrutinized and optimized for the common cases. > > I haven't kept track of who's measuring Linux kernel GigE thruput > recently. Here's a pointer to a 2001 study: > > http://www.csm.ornl.gov/~dunigan/netperf/bulk.html > > Most people care about TCP speed, but making fast paths for TCP > usually makes even faster paths for the UDP packets that USRP2 will be > using soon.
I can believe Linux Ethernet handling is fast and gets faster all the time... but with most of the emphasis on throughput. I'm still looking for studies that focus on latency; i.e. turn-around time (or RTT), and use recent Linux and motherboards. Probably such data is harder to find becuase in most applications (over long routes), improving RTT at the motherboard + kernel level won't be worth the effort. -Jeff _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
