Date: Thu, 11 Oct 2001 18:16:14 -0700 (PDT) From: Archie Cobbs <archie@dellroad.org> To: Mike Tancsa <mike@sentex.net> Cc: rizzo@aciri.org, freebsd-net@FreeBSD.ORG Subject: Re: strange results with increased net.inet.ip.intr_queue_maxlen Message-ID: <200110120116.f9C1GEv18196@arch20m.dellroad.org> In-Reply-To: <5.1.0.14.0.20011011164834.0728c2e0@marble.sentex.ca> "from Mike Tancsa at Oct 11, 2001 04:50:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Tancsa writes: > > > net.inet.ip.intr_queue_maxlen from 50 to 100. and there didnt seem to be > > > any positive results in terms of lessening the rate of > > > net.inet.ip.intr_queue_drops. > > > >This is consistent with the situation where packets are received > >at a rate faster than they are being consumed. No matter how big > >your queue is, it's going to fill up eventually and overflow, and > >all you're doing by increasing the queue length is adding latency > >to all of those packets that you do process. > > Hi, thanks for the info. But wont I still pay a price, presumably at the > application layer for any packets that are lost and retransmitted ? Apart > from pinging the other side of the OC-3 or ethernet connection and > measuring the response time, how can I see how much latency is added by > increasing these buffers ? If the forwarding path is maxed out, then it is the application layer's responsibility to back off (think TCP). Pinging is an excellent way to determine latency. -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?200110120116.f9C1GEv18196>