Re: altq again

[Jukka Marin <jmarin%embedtronics.fi@localhost>]

On Mon, Nov 26, 2012 at 09:06:15PM +0000, Michael van Elst wrote:
> jmarin%embedtronics.fi@localhost (Jukka Marin) writes:
> 
> >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.

The transmit packets are being dropped, but I guess they could be
UDP packets from the OpenVPN tunnels.

> 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.

timecounter: Timecounter "clockinterrupt" frequency 1000 Hz quality 0

> >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.

Can I increase the buffer space?  Packets are getting dropped even when
the ADSL capacity is only partially used, so I think more buffering might
help?  Increasing the qlimit parameter in altq didn't seem to help (I
changed it from 100 to 1000 and didn't notice the difference).

On Mon, Nov 26, 2012 at 04:41:19PM -0500, Darrel wrote:
> Do you use /etc/altq.conf?  Is it only for very old versions of Packet 
> Filter?

No, I don't have altqd running.. I don't know if it's needed.  The altqd
manual doesn't mention pf, neither does the pf manual mention altqd.

  -jm