Date: Mon, 08 Dec 97 21:26:03 -0500 From: Brad Karp <karp@eecs.harvard.edu> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, karp@dominator.eecs.harvard.edu, mankin@isi.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... Message-ID: <199712090226.VAA05276@dominator.eecs.harvard.edu> In-Reply-To: Your message of "Sun, 07 Dec 97 19:39:32 PST." <19971207193932.61833@hydrogen.nike.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > My driver is written over the IP tunnel (tun), and is completely portable > > (no #ifdefs, even) between FreeBSD and NetBSD (I use it on both systems). It > > does neighbor discovery, dynamically handles IP-to-MAC mapping for the radios > > (with no centralized ARP server, despite the non-broadcast nature of Metricom's > > radios), and works very well, overall. > > hmmm... tun is nice for portability, but it still doesn't match the > performance of a kernel land driver... the extra context switches > do impact performance... a ping to a remote host has to traverse the > kernel/userland boundary three times when pinging a remote host... > (ping->kernel->tunnel->output to device/network)... Throughput: Metricom radios max out at about 58 Kbps, in my experience (TCP, greedy sender with data always available). I have confirmed this figure with Metricom's engineers, who verify it. Reasons include the fact that Metricom radios are half-duplex (so ACKs require send/receive switching) and frequency configuration time (spread spectrum, remember) for jumping to the receiver's current frequency on the RF side (for each packet sent, both data and ACK). Even if the 100 Kbps throughput were realizable, though, I'd expect a very underpowered CPU (say, a 486/66) to keep up with packet forwarding at such a low data rate (and with tiny CPU utilization), as the CPU usage will be throttled by the very low bandwidth of the radio. Saturating the radio leaves > 99% idle time on a Pentium 150, as one (non-fully-conclusive, but non-contradictory) data point. Latency: I do believe I experience more latency than is fundamentally required by the hardware, yes. I don't believe that this has materially to do with tun and context switches and copyin/copyout, however--again, I'd expect them to be noise on modern processors. The 10 ms process scheduling quantum should not effect latency adversely if the user-level driver process is run at a negative nice value (in effect, emulating a kernel driver's giving strict priority to tx/rx complete interrupts). I think that the real culprit is the way sio batches characters, scheduling software interrupts (scheduled at 10 ms granularity, I believe) to pass characters, and buffering them in the tty driver in the interest of reducing the hardware serial interrupt handler's latency. This should add latency to the _kernel_ ppp driver, as well, as my reading is that the kernel ppp driver is built atop sio, and should thus see the same latency due to sio's character batching. Can anyone confirm this? i.e., does the kernel ppp driver tend to deliver packets on 10 ms boundaries, when sio's software interrupts complete? Also, you need to keep in mind that the latency of data transmission on a Metricom radio is grossly dominated by the path through the radio hardware, waiting to jump to the other radio's frequency in the right slot, and through the radio hardware on the other side. A useful datapoint to substantiate my latency argument: The next-hop rtt of the Stanford (Linux kernel) driver is on the order of 167 ms according to the driver's author, whereas my user-level driver on FreeBSD gets a next-hop rtt of 140 ms! > I actually have the NetBSD kernel strip driver compiling... I just need > to test the driver... Is this the driver from Randy Katz's group, perchance? Can you let me know what rtt it gives to the next hop? I strongly suspect you'll get a figure very close to the one I do (140 ms). How about for the kernel ppp driver, if you have that figure handy? > I'd be willing to test and commit the driver, assuming no other commiters > object.. :) also, I assume that the license for the driver is similar > to the BSD license? and not GPL'd? The license will be similar to that for BSD, yes; it will have Harvard's and USC/ISI's (my funders') copyrights, and will allow redistribution in source form and modification as long as the copyright notice is left intact. I need add the copyright to the code and write up a brief man page, I suppose. Will let you know when it's ready to pick up, and where. > > Again, as I don't subscribe to freebsd-hackers, please address comments, > > questions, and/or requests for the code to me by email. > > ok, I'm adding you to my aliases... ttyl.. Actually, while I wish I did, I don't really have time to peruse the traffic in -hackers. Could you cut me from your forwarding list? (Thanks for thoughtfully including me, though!) Regards, -Brad, karp@eecs.harvard.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712090226.VAA05276>