Re: clogging qdisc

Perhaps you should post an example of your tc setup?

I had a bug a few months back where traffic in important queues would 
seemingly randomly get 100% drop rate (as in your example below).  Upon 
penning an email with the tc setup I realised that I had a leaf class on 
the wrong branch and was trying to guarantee 99.9+% of traffic for that 
leaf if it had significant traffic... Number 1:2 was swapped for number 
1:1 and everything went back to normal.

Alan

On 27/12/2018 22:26, Grzegorz Gwóźdź wrote:
>
>> Are there any "hacks" in TC allowing to look in the guts?
>>
>> It looks like it's changing state to "clogged" but
>>
>> tc -s class ls dev eth0
>>
>> looks completely normal (only grows number of sfq queues created 
>> dynamically for every connection since more and more connections are 
>> created but not closed) 
>
>
> In fact i've noticed something interesting during "clugged" state...
>
> a few runs of:
>
> tc -s class ls dev eth0
>
> shows that filters sort packets well but packets that goes into 
> suitable classes are dropped:
>
> class hfsc 1:1012 parent 1: leaf 1012: sc m1 6144Kbit d 10.0s m2 
> 4096Kbit ul m1 6144Kbit d 10.0s m2 4096Kbit
>  Sent 103306048 bytes 75008 pkt (dropped 12, overlimits 0 requeues 0)
>  backlog 39Kb 127p requeues 0
>  period 13718 work 103306048 bytes rtwork 103306048 bytes level 0
>
> and after a while:
>
> class hfsc 1:1012 parent 1: leaf 1012: sc m1 6144Kbit d 10.0s m2 
> 4096Kbit ul m1 6144Kbit d 10.0s m2 4096Kbit
>  Sent 103306048 bytes 75008 pkt (dropped 116, overlimits 0 requeues 0)
>  backlog 39160b 127p requeues 0
>  period 13718 work 103306048 bytes rtwork 103306048 bytes level 0
>
> "Sent" stands still and all packets are "dropped"
>
> Some classes passes packets but as time goes by more and more classes 
> stops passing and starts dropping.
>
>
> GG
>