[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: altq again
On Tue, Nov 27, 2012 at 09:22:39AM +0200, Jukka Marin wrote:
> The transmit packets are being dropped, but I guess they could be
> UDP packets from the OpenVPN tunnels.
I have no experience with OpenVPN, but in UDP mode it should just
encapsulate IP datagrams.
> > 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
That was good enough for a 10Mbps ethernet.
> > >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?
The altq policies usually have a 'tbrsize' (token bucket regulator)
parameter, that's the "bucket" for outgoing packets. It defaults
to something related to interface speed. Making it much larger
won't help, if altq cannot throttle the sender it will always overflow.
As a rule of thumb, a size worth of 1 second of data should be ok.
> 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).
The most consistent results I had with the simple CBQ policy...
> 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.
I have used altq only with altqd. altqd just pushes the configuration
into the kernel. If you use pf, the configuration for altq is embedded
into the pf configuration and you don't need altqd.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |