NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: altq again

Is dropping the packets the only way of limiting bw?

For sending TCP you can delay outgoing packets and assume that
TCP will slow down accordingly. But for receiving (or something
like ICMP or UDP), there is nothing but dropping packets.

Why do the connections
actually work better without the limit (even though there's only 1 Mbps
available, limited or not)?

altq requires a fast system clock to handle "large" data rates. The
standard HZ=100 is maybe good enough to schedule output to a serial
port (10-100kbit/s), but for Ethernet the behaviour will be a bit erratic.

I also see ping whining about "no buffer space" when the limit is active.

altq buffers output that is queued too fast (and sends out the buffer
contents at its own pace). When the buffer is full you get ENOBUFS.

Do you use /etc/altq.conf? Is it only for very old versions of Packet Filter?


Home | Main Index | Thread Index | Old Index