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
