On Mon, Mar 9, 2015 at 4:51 AM, Henning Brauer <hb-open...@ml.bsws.de> wrote: > * Daniel Melameth <dan...@melameth.com> [2015-01-23 22:38]: >> I noticed the following when downloading a large file: >> >> queue tcp_ack parent root on fxp0 bandwidth 2M qlimit 50 >> [ pkts: 289461 bytes: 15631434 dropped pkts: 16 bytes: 864 ] >> [ qlength: 0/ 50 ] >> [ measured: 3660.9 packets/s, 1.58Mb/s ] >> >> While the number of dropped packets is very small and probably >> insignificant, I would have expected zero dropped packets as little >> else is competing for the ~12Mbps that's available in the parent >> queue/circuit. I thought this might be related to qlength, but since >> this is, apparently, zero during the time of the download I'm not >> certain what would be causing this. What might I be missing here and >> how do I resolve (I don't want to set a min here if it can be >> avoided). > > First, get over the misconception that dropped packets are bad. The > opposite is almost true. With tcp, dropping a packet signals the sender > to slow down. > > You're seeing the few dropped packets because your queue at some time > hit its limits. > > Comparing an ever-growing counter (drops) with an averaged, somewhat > current rate can be very misleading.
I figured this might be the case. Thanks for taking the time to chime in Henning. >> FWIW, net.inet.ip.ifq.drops=0. > > 100% unrelated.
