[LARTC] Transfer speed exceeding the ceil

[LARTC] Transfer speed exceeding the ceil

[Ryan Castellucci]

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/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Transfer speed exceeding the ceil

[Andy Furniss]

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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Transfer speed exceeding the ceil

[Ryan Castellucci]

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/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Transfer speed exceeding the ceil

[Andy Furniss]

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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Transfer speed exceeding the ceil

[Ryan Castellucci]

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/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Transfer speed exceeding the ceil

[Andy Furniss]

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.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc