Thanks to all that replied. Trial and error it is ... I'm now waiting (22 hours later) for it to break again after I changed the priority on the "default" catch-all class. It lasted five days before. I'm looking at CBQ but it's not at all friendly relative to HTB. If I'm forced to go down the proprietary traffic-shaping route. What's good for really cheap gigabit, redundant, high throughput (including during 64-byte UDP attacks) shapers ? Suggestions appreciated. Chris 2009/12/9 Nickola Kolev <nikky@mnet.bg>
На Wed, 09 Dec 2009 06:38:31 +0000 gordon b slater <gordslater@ieee.org> написа:
On Wed, 2009-12-09 at 08:02 +0200, Bazy wrote:
Hi Chris,
Try setting txqueuelen to 1000 on the interfaces and see if you still get a lot of packet loss.
Yes, good point and well worth a try. Rereading Chris's post about "250Mbps" and "forty queues", the "egress" could well be bumping the end of a default fifo line.
If 1000 is too high for your kit try pushing it upwards gradually from the default of 100 (?) but back off if you get drops or strangeness in ifconfig output on the egress i/f.
The default *is* 1000. From the ifconfig man page:
txqueuelen length
Set the length of the transmit queue of the device. It is useful to set this to small values for slower devices with a high atency (modem links, ISDN) to prevent fast bulk transfers from disturbing interactive traffic like telnet too much.
So, if you should touch it if and only if you want to have (supposedly) finer grained control on queueing, as the hardware device also does some reordering before it puts the data on the wire.
I append grep-ped ifconfig outputs into a file every hour on a cron job until I'm happy that strangeness doesn't happen, they never do when you're watching sadly.
TC problems aren't always about the TC itself, the physical interfaces are inherently part of the "system", as my long rambling 5am+ up-all-night-over-ssh post about reseating NICs was trying to hint at.
Nice one Bazy
Gord
-- Regards, Nickola