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

[Jeff Brower]

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