Date: Mon, 15 Oct 2001 20:52:55 -0400 From: Mike Tancsa <mike@sentex.net> To: archie@dellroad.org (Archie Cobbs) Cc: freebsd-net@FreeBSD.ORG Subject: Re: strange results with increased net.inet.ip.intr_queue_maxlen (solved) Message-ID: <el0nst0h6lu5ndsioa7o5p2fhuu4tg8c9a@4ax.com> In-Reply-To: <SEN.1003186827.86914163@news.sentex.net> References: <5.1.0.14.0.20011012121150.072325d0@marble.sentex.ca> <SEN.1003186827.86914163@news.sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Oct 2001 23:00:27 +0000 (UTC), in sentex.lists.freebsd.net you wrote: >Mike Tancsa writes: >> >If the forwarding path is maxed out, then it is the application = layer's >> >responsibility to back off (think TCP). >>=20 >> Is it better for the networking layer to deal with this (potentially=20 >> introducing some latency) as opposed to letting the application ? > >Oops, can substitute "transport" for "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). > >There is probably a good paper somewhere outlining the "best effort" >philosophy but I don't know what it is. Another way to look at it >is intelligence in the leaf nodes rather than in the network. This >is one of the central idea of the Internet dating back to a long >time ago. I guess the other big idea is packets instead of dedicated >circuits (which hog resources). 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. In fact, processing is done like this: in the interrupt driver, while you have packets you fetch them from the device and queue them in ipintrq. Once you are done with this (which could take very long and drain a lot of packets if either packets come in very fast, or the device queue is long and interrupts come late), you go up and process packets in ipintrq. Now, I am not 100% sure but the "en" device seems to have 512 slots in the receive queue, hence the problem... Normally, using fastforwarding would help because bypasses ipintrq and calls directly ip_input(), except that "en" calls atm_intr() which does not know anything about fastforwarding. I think the above should explain the problem, and then you can probably either set ipq_maxlen to a large enough value (like 512) or slightly modify the "en" driver to limit the burst of packets it produces to some more reasonable amount. Not my area though, you should contact the author of the device driver to see if this is possible. ----------------------------- ---Mike Mike Tancsa (mdtancsa@sentex.net) =09 Sentex Communications Corp, =09 Waterloo, Ontario, Canada "Given enough time, 100 monkeys on 100 routers=20 could setup a national IP network." (KDW2) 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?el0nst0h6lu5ndsioa7o5p2fhuu4tg8c9a>