What''s going on here? I''m spewing UDP traffic at this thing, and it is exceeding the ceil. Anyone know how to fix this? class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b overhead 0b level 0 Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) rate 412384bit 6pps backlog 0b 126p requeues 0 lended: 887 borrowed: 3146 giants: 1748 tokens: -1605047 ctokens: -32828 -- Ryan Castellucci http://ryanc.org/
Upon futher examination, traffic seems to flow at about 4x whatever the ceil is set to. On 11/14/05, Ryan Castellucci <ryan.castellucci@gmail.com> wrote:> What''s going on here? I''m spewing UDP traffic at this thing, and it is > exceeding the ceil. Anyone know how to fix this? > > class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit > ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b > overhead 0b level 0 > Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) > rate 412384bit 6pps backlog 0b 126p requeues 0 > lended: 887 borrowed: 3146 giants: 1748 > tokens: -1605047 ctokens: -32828 > > -- > Ryan Castellucci http://ryanc.org/ >-- Ryan Castellucci http://ryanc.org/
Ryan Castellucci wrote:> What''s going on here? I''m spewing UDP traffic at this thing, and it is > exceeding the ceil. Anyone know how to fix this? > > class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit > ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b > overhead 0b level 0 > Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) > rate 412384bit 6pps backlog 0b 126p requeues 0 > lended: 887 borrowed: 3146 giants: 1748 > tokens: -1605047 ctokens: -32828Try and verify rate of udp arrival at the target machine with tcpdump -ttt. The sent counter is actually an enqueue rather than dequeue count so blatting with udp may cause bogus rates (not that I''ve checked how exactly htb does rate calculations). Andy.
On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote:> Ryan Castellucci wrote: > > What''s going on here? I''m spewing UDP traffic at this thing, and it is > > exceeding the ceil. Anyone know how to fix this? > > > > class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit > > ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b > > overhead 0b level 0 > > Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) > > rate 412384bit 6pps backlog 0b 126p requeues 0 > > lended: 887 borrowed: 3146 giants: 1748 > > tokens: -1605047 ctokens: -32828 > > Try and verify rate of udp arrival at the target machine with tcpdump -ttt. > > The sent counter is actually an enqueue rather than dequeue count so > blatting with udp may cause bogus rates (not that I''ve checked how > exactly htb does rate calculations). > > Andy.I checked it with iftop, which confirms what tc is showing. I had determined that this is an issue with fragmented packets rather then specificly UDP, take a look at the other messages i posted to the mailing list. is the is bug in tc/htb? or is this perhpse something that could be corrected by enlarging the quantum? -- Ryan Castellucci http://ryanc.org/
Ryan Castellucci wrote:> On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote: > >>Ryan Castellucci wrote: >> >>>What''s going on here? I''m spewing UDP traffic at this thing, and it is >>>exceeding the ceil. Anyone know how to fix this? >>> >>>class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit >>>ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b >>>overhead 0b level 0 >>>Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) >>>rate 412384bit 6pps backlog 0b 126p requeues 0 >>>lended: 887 borrowed: 3146 giants: 1748 >>>tokens: -1605047 ctokens: -32828 >> >>Try and verify rate of udp arrival at the target machine with tcpdump -ttt. >> >>The sent counter is actually an enqueue rather than dequeue count so >>blatting with udp may cause bogus rates (not that I''ve checked how >>exactly htb does rate calculations). >> >>Andy. > > > I checked it with iftop, which confirms what tc is showing. I had > determined that this is an issue with fragmented packets rather then > specificly UDP, take a look at the other messages i posted to the > mailing list. is the is bug in tc/htb? or is this perhpse something > that could be corrected by enlarging the quantum?I tried fragged udp and it seemed OK for me - whats the mtu on the interface - if it''s bigger than normal then try specifying it along with rate/ceils to htb - Looking as I type I can see giants 1748 above (I should have noticed that earlier) - htb does not shape big packets properly unless you use the mtu option. The list is down for me today. Andy.
On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote:> Ryan Castellucci wrote: > > On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote: > > > >>Ryan Castellucci wrote: > >> > >>>What''s going on here? I''m spewing UDP traffic at this thing, and it is > >>>exceeding the ceil. Anyone know how to fix this? > >>> > >>>class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit > >>>ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b > >>>overhead 0b level 0 > >>>Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) > >>>rate 412384bit 6pps backlog 0b 126p requeues 0 > >>>lended: 887 borrowed: 3146 giants: 1748 > >>>tokens: -1605047 ctokens: -32828 > >> > >>Try and verify rate of udp arrival at the target machine with tcpdump -ttt. > >> > >>The sent counter is actually an enqueue rather than dequeue count so > >>blatting with udp may cause bogus rates (not that I''ve checked how > >>exactly htb does rate calculations). > >> > >>Andy. > > > > > > I checked it with iftop, which confirms what tc is showing. I had > > determined that this is an issue with fragmented packets rather then > > specificly UDP, take a look at the other messages i posted to the > > mailing list. is the is bug in tc/htb? or is this perhpse something > > that could be corrected by enlarging the quantum? > > I tried fragged udp and it seemed OK for me - whats the mtu on the > interface - if it''s bigger than normal then try specifying it along with > rate/ceils to htb - Looking as I type I can see giants 1748 above (I > should have noticed that earlier) - htb does not shape big packets > properly unless you use the mtu option. > > The list is down for me today.I was not manualy setting the MTU. The interfaces I''m using have MTU of 1500, but I''ll try setting the MTU for my classes to 1500 and see if that resolves the problem. Thanks! -- Ryan Castellucci http://ryanc.org/
Ryan Castellucci wrote:> On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote: > >>Ryan Castellucci wrote: >> >>>On 11/16/05, Andy Furniss <andy.furniss@dsl.pipex.com> wrote: >>> >>> >>>>Ryan Castellucci wrote: >>>> >>>> >>>>>What''s going on here? I''m spewing UDP traffic at this thing, and it is >>>>>exceeding the ceil. Anyone know how to fix this? >>>>> >>>>>class htb 1:613 parent 1:5 leaf 613: prio 6 quantum 2560 rate 20480bit >>>>>ceil 103360bit burst 15Kb/8 mpu 0b overhead 0b cburst 1728b/8 mpu 0b >>>>>overhead 0b level 0 >>>>>Sent 16591370 bytes 4159 pkt (dropped 39449, overlimits 0 requeues 0) >>>>>rate 412384bit 6pps backlog 0b 126p requeues 0 >>>>>lended: 887 borrowed: 3146 giants: 1748 >>>>>tokens: -1605047 ctokens: -32828 >>>> >>>>Try and verify rate of udp arrival at the target machine with tcpdump -ttt. >>>> >>>>The sent counter is actually an enqueue rather than dequeue count so >>>>blatting with udp may cause bogus rates (not that I''ve checked how >>>>exactly htb does rate calculations). >>>> >>>>Andy. >>> >>> >>>I checked it with iftop, which confirms what tc is showing. I had >>>determined that this is an issue with fragmented packets rather then >>>specificly UDP, take a look at the other messages i posted to the >>>mailing list. is the is bug in tc/htb? or is this perhpse something >>>that could be corrected by enlarging the quantum? >> >>I tried fragged udp and it seemed OK for me - whats the mtu on the >>interface - if it''s bigger than normal then try specifying it along with >>rate/ceils to htb - Looking as I type I can see giants 1748 above (I >>should have noticed that earlier) - htb does not shape big packets >>properly unless you use the mtu option. >> >>The list is down for me today. > > > I was not manualy setting the MTU. The interfaces I''m using have MTU > of 1500, but I''ll try setting the MTU for my classes to 1500 and see > if that resolves the problem.Hmm - 1500 should work by default and you should see no giants - so if the mtu on the interface was 1500 I can''t see how htb counted 1748 giants. Andy.