When I change the queue properties ( for instance, I change queue tree from 4000kbps to 3000kbps ) then I see packet loss. It's almost like the interface is undergoing some sort of "on/off" very quickly. The packetloss is minimal, but on voip it' spretty bad, I can hear it. Is there any way to make changes to the queues not needing an interface up/down or reset ?... I'd like it to just dynamically update queue properties. Is that possible ?

Cheers.

*bump*

Does anyone have any idea's ?

If I understand the behavior you describe correctly, you are reducing the limit and then you see momentary packet loss.

The only way to throttle TCP/IP is to drop packets. When you restrict the data rate packets from the source will be dropped at the router until incoming packets are within the queue data limit. This applies to both directions... source from client and source with client as destination. If the data rate exceeds the limit, packets are dropped to slow TCP/IP, with the caveat that a few packets are buffered... but VoIP would reject the buffered packets as they would arrive too late to be useful.

Hi LastResort, thanks for your reply.

I understand what you are trying to say, but I must have explained my issue wrong. In order to clarify, let me try to explain again.

The packet drop doesn't occur because of the queues dropping TCP packets, it seems to occur because of physical ports being shut down and started up again. This takes no more than let's say 600 milliseconds, but it's enough to lose packets.

This problem not only occurs when moving the queue size down, but also up. It even occurs when not changing anything, but just "reloading" the queue config, which points to me that it's not the throttling but something deeper that's droppign packets, like a physical interface.

Any more idea's ?

Don't do work on the queues while people are using the internet?

It's like making changes to anything, if you change the profile on a pppoe connection, it's going to redial, if you change the queue-type settings, it's going to reset the queues. There's not much you can do other than to schedule changes and if needed assign an outage window so your users know in advance.

Sorry if this sounds a bit curt, but it really is the same with all these sort of changes. If you need a dynamically adjusting queue I'd recommend further investigating PCQ as a solution to that need.

I see the same thing. I don't know if this is inherent in how the underlying Linux facilities handle packets.

I, too, was surprised that queue changes drop traffic for a second, and so were my customers. I can change queue parameters on Cisco and Juniper on the fly and outside of the expected drops when I lower queue capacity traffic is not affected. Increasing queue size leads to no packet drop whatsoever.

Sometimes I have to increase queue sizes on the fly, particularly when a customer asks for an increase in bandwidth and wants it done immediately. I sell short lived connections, and by tomorrow the customer may no longer be on the premises.

That said, I can work around it by just warning customers and getting write off so it is not a big deal.

Omega :

Some of our customers use highly unreliable rural ADSL connections. They will have 12000 mbkbps one minute, then it rains and they get 1000kbps. I use a script to change queue sizes depending on how much speed is available. This script runs all the time, and changes queues as needed. It works well, except for the packet loss. On Cisco changing QOS won't reset the whole interface or drop packets.

You mention that PCQ is not afected. I use PCQ, but I have the same problem with PCQ.

Cheers

Sorry: to clarify, I mean you should use PCQ as it can be setup to handle traffic dynamically, however it is still affected same as the rest if you're making config changes to the queues while they're in use.

A better way might be to create both sets of queues and see if you can retag traffic to go to one queue or another on-the-fly rather than actually having to modify the queue bandwidth values.

That's a neat idea for a workaround. Even if you're not switching between two queues all the time if the drops are unacceptable you could make a temp queue with the same values, switch to it, edit the original queue, and switch back to it. If you're naming queues after the marks or otherwise have an easy way to determine a link between the two it would be fairly easy to write a script where you just replace two variables at the top and can paste the whole thing in, making it as easy as changing an existing queue.

Omega and Fewi,

Thanks for your replies. I will have a go at changing the script to use other queues. I'll make a few standard queues ( 20 ) and direct traffic dynamically to the different queues. I'll let you know if the packetloss problem is fixed when I have it running. ( We're flooded atm, so very busy )