Date: Sun, 7 Dec 1997 21:20:51 -0800 From: John-Mark Gurney <gurney_j@efn.org> To: Charles Mott <cmott@srv.net> Cc: Brad Karp <karp@eecs.harvard.edu>, pst@shockwave.com, freebsd-hackers@FreeBSD.ORG, karp@dominator.eecs.harvard.edu Subject: Re: FreeBSD Metricom driver: I wrote one in September... Message-ID: <19971207212051.48451@hydrogen.nike.efn.org> In-Reply-To: <Pine.BSF.3.96.971207211444.21258A-100000@darkstar.home>; from Charles Mott on Sun, Dec 07, 1997 at 09:24:10PM -0700 References: <19971207193932.61833@hydrogen.nike.efn.org> <Pine.BSF.3.96.971207211444.21258A-100000@darkstar.home>
next in thread | previous in thread | raw e-mail | index | archive | help
Charles Mott scribbled this message on Dec 7: > > > 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)... > > On late model Pentiums, I think kernel-user context switch is down to > about 5 microseconds (it's about 60 microseconds on my 386) for an > individual system call. However, maybe one or two OS quantums (10 > milliseconds) are added for hauling the packets around. Is this the > problem you are talking about? (I don't know the answer and am trying ot > understand system timing better). basicly the user/kernel context switch is just a minor part... it goes along with scheduling that may not happen immediately.. and then you hit problems where the process will be delayed because other users processes are scheduled before your (this is actually quite a bit better in FreeBSD than other OS's I've used) process... so then you could have up to LA * 10ms before your packet gets processed instead of immediately like in the kernel... one way would be to stick it on the real time prio queue... but then if the processes goes in an infinate loop, the machine dies... also, remeber, the data originally came from the kernel, then it goes through conversion by your user process... just to be deliever back to the hands of the kernel process... I've personally never traced the whole path by hand... but after working with the code, you have a pretty good idea of what the code path looks like.. :) -- 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?19971207212051.48451>