Re: [Discuss-gnuradio] MAC layer development and USRP2

[John Gilmore]

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

        John