Date: Wed, 13 Jan 1999 08:58:46 +0000 From: Brian Somers <brian@Awfulhak.org> To: Doug White <dwhite@pond.net> Cc: Bill Fenner <fenner@parc.xerox.com>, hackers@FreeBSD.ORG Subject: Re: using raw sockets Message-ID: <199901130858.IAA74669@keep.lan.Awfulhak.org> In-Reply-To: Your message of "Tue, 12 Jan 1999 15:43:47 PST." <Pine.BSF.3.96.990112153755.6791A-100000@guppy.pond.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 12 Jan 1999, Bill Fenner wrote: > > > What OS version, and what kind of ethernet card, are you using when you > > see the BPF symptoms that you mention? I've never seen either of the > > problems you describe. It seems to me that fixing bpf is a much better > > target than creating a whole new mechanism. > > I'm on 2.2.7-RELEASE with a 3Com 3c509 (ep0). I'm using a program I wrote > that's derived from ppp(8), which operates in a select() loop. I don't > know exactly where the holdup is, but from my debugging output I don't > think it's my code (it reads the packets I send out immediately, just not > any inbound packets). [.....] I don't know if it'll help, but if you enable the (rather verbose) ``timer'' diagnostics going to the screen of an interactive session, you may be able to determine if something's holding up the select(). Normal logs are probably useless as you've got the syslogd latency added in. Something like ``set log local timer'' will show you what descriptors are being added to what fd_set's. It may give you a "feel" for whether the select() is being done as required. Also, I'm not sure if you've merged version 1.32 of timer.c from the HEAD branch into your current sources. If you have, you might try backing that out and seeing if that improves things. The change reduces ppps interrupt overheads, but exposes any small latency problems, making them into more serious errors. This sounds quite plausible given your latency timings (just over a second). There are a number of other timers that are set at one second (the modem carrier timer and the throughput timers spring to mind) which will break ppp out of the select() and cause another batch of *_UpdateSet() calls. The danger here (or the thing to be wary of) is that if you return from your local *_UpdateSet() function without updating any of the passed fd_set's, you won't be called again for an arbitrary amount of time. This means that you sometimes need to recurse in *_UpdateSet() - take a look at datalink.c for an example. There are a few places in datalink_UpdateSet() that ``return datalink_UpdateSet()'' after altering the datalink::state. If recursing isn't appropriate (you really have nothing else to do at the moment, but would like to be called again pretty soon), you need to implement a ``timer'' (which doesn't actually need to do anything). That'll drop ppp out of the select() and cause a new call to all the *_UpdateSet() functions too. > Doug White | Pacific Crest Networks > Internet: dwhite@pond.net | http://www.pond.net/ -- Brian <brian@Awfulhak.org> <brian@FreeBSD.org> <brian@OpenBSD.org> <http://www.Awfulhak.org>; Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901130858.IAA74669>