Date: Mon, 15 Oct 2001 20:44:24 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-net@FreeBSD.ORG Subject: Re: strange results with increased net.inet.ip.intr_queue_maxlen (solved) Message-ID: <200110160344.f9G3iOd33944@arch20m.dellroad.org> In-Reply-To: <el0nst0h6lu5ndsioa7o5p2fhuu4tg8c9a@4ax.com> "from Mike Tancsa at Oct 15, 2001 08:52:55 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Tancsa writes: > >> Is it better for the networking layer to deal with this (potentially > >> introducing some latency) as opposed to letting the application ? > > > >But no, the network should just do "best effort".. that is, unless > >you are a telco type in which case, go back to your X.25 :-) This > >is a religious issue to some degree, but in practice the war is over > >and the Internet won (vs. the telco way of doing things). > > Thanks for the info. Lugi Rizzo was kind enough to figure out what has > been going on. I increased the queue size to 512 on both my OC-3 equipped > machine (via the en device) as well as my pure FastE (via fxp) machines and > the problems have gone away. As to why this solved the problem Lugi wrote, > > -------------- > oh, did you see drops go to 0 when the queue size is 256 ? I missed > this. Then it means another thing, you are receiving a very large > burst of packet from the interface, larger than ipintrq, and this > is why they get dropped. This makes sense.. and that's is exactly what queues are for: absorbing bursts. If you have big bursts then you'll need big queues.. in general this is the only reason to have them. -Archie __________________________________________________________________________ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110160344.f9G3iOd33944>