Date: Mon, 8 Dec 1997 18:56:09 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Brad Karp <karp@eecs.harvard.edu> Cc: pst@shockwave.com, freebsd-hackers@freebsd.org, mankin@isi.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... Message-ID: <19971208185609.10013@hydrogen.nike.efn.org> In-Reply-To: <199712090226.VAA05276@dominator.eecs.harvard.edu>; from Brad Karp on Mon, Dec 08, 1997 at 09:26:03PM -0500 References: <19971207193932.61833@hydrogen.nike.efn.org> <199712090226.VAA05276@dominator.eecs.harvard.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Karp scribbled this message on Dec 8: > > > 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. true.. many of these do work on fast machines.. but right now my notebook is limited to a 486dx2/50... so it's quite slow... and then my fastest machine at home right now is a k5/90.. so I'm quite sensitive to the performance of code (heck, I still run a 386/25sx w/ 6megs too.. :) ) > 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. yes... it probably is compared to the rest of the hardware that we have to deal with... I'll just have to use the driver to check it out... > 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! interesting... so does that mean pings are 140ms?? I'd be VERY interested... right now I have to put up with about 350ms rtt on the modems to the university's network... and then you add in a 28.8k modem (that is about 200ms due to the way it's connected), and using your home machine is quite slow.. > > 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? nope... I just have it compiling.. I haven't been able to test it yet as there were some problems will building a -current world to install on my notebook... but I'm doing the install now... > > 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. thanks... hopefully ricochet will start to give better support to the non-microsoft people... only releasing an updater for windows and macs is really a pain... last time software came out, I had to use a friends notebook, as none of my machines (at the time) had a microsoft os on it... > > > 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!) this isn't a forwarding list.. this is just a way that makes it easier for me to send you mail in the future.. (and I personally HATE forwarding lists, they suck, I've gotten to much junk mail from people that way)... ttyl.. -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971208185609.10013>