Skip site navigation (1)Skip section navigation (2)
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>