# SQM Reporting? **URL:** \ **Category:** Installing and Using OpenWrt\ **Created:** [April 8, 2020, 8:15pm UTC](https://forum.openwrt.org/t/sqm-reporting/59960 "2020-04-08T20:15:49Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![ldir](https://forum.openwrt.org/user_avatar/forum.openwrt.org/ldir/32/39861_2.png) [@ldir](https://forum.openwrt.org/u/ldir)\ **Post date:** [April 9, 2020, 12:33pm UTC](https://forum.openwrt.org/t/sqm-reporting/59960/6 "2020-04-09T12:33:58Z")
oh boy, can open, worms all over the place. I can advise on some aspects of cake but not much else. The good news is that tc can output in json format which probably makes things easier in terms of not scraping screen output. 'tc -d qdisc show' will show basic config for all qdiscs on all interfaces and isn't particularly interesting/helpful 'tc -d qdisc show dev eth0' will do the same but for just the specified interface. Adding a '-j' flag will return same output/s in json format. The more interesting stuff is in the '-s' statistics output as @hnyman posted above. In terms of cake output, cake can be viewed as an overall shaper with traffic classified into groups called Tins. A cake instance can have 1, 3, 4 or 8 tins. A 4 tin configured cake looks like: ``` qdisc cake 8081: root refcnt 9 bandwidth 19900Kbit diffserv4 dual-srchost nat nowash ack-filter split-gso rtt 100.0ms ptm overhead 26 mpu 72 Sent 100593447 bytes 224203 pkt (dropped 7430, overlimits 326315 requeues 64) backlog 0b 0p requeues 64 memory used: 237416b of 4Mb capacity estimate: 19900Kbit min/max network layer size: 28 / 1500 min/max overhead-adjusted size: 74 / 1550 average network hdr offset: 14 Bulk Best Effort Video Voice thresh 1243Kbit 19900Kbit 9950Kbit 4975Kbit target 14.6ms 5.0ms 5.0ms 5.0ms interval 109.6ms 100.0ms 100.0ms 100.0ms pk_delay 764us 2.5ms 43us 72us av_delay 117us 279us 29us 16us sp_delay 6us 23us 21us 16us backlog 0b 0b 0b 0b pkts 45927 184129 1260 317 bytes 15150132 87582439 79573 16302 way_inds 360 754 0 0 way_miss 257 1312 216 2 way_cols 0 0 0 0 drops 33 1145 0 0 marks 0 0 0 0 ack_drop 4936 1316 0 0 sp_flows 1 0 1 1 bk_flows 0 1 0 0 un_flows 0 0 0 0 max_len 11245 7570 603 54 quantum 300 607 303 300 qdisc ingress ffff: parent ffff:fff1 ---------------- Sent 234180120 bytes 245510 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 ``` For the 3 & 4 tin category instances of cake, the tins are given a descriptive name, the other instances they're just called 'Tin 'n''. Tins on the left have lower priority than tins on the right. Tin selection is (usually) determined by the packet's DSCP value. In terms of the stats values reported here's what they mean AFAIUI. Thres: Defines how much bandwidth is consume in this tin before it switches to a lower priority. In the above example, voice is guaranteed 5Mbit of bandwidth. If video needed up to 10Mbit and voice was consuming more than 5Mbit, video would start stealing bandwidth from voice until the bandwidth minimums were reached. They're soft limits in that anyone can have all of the bandwidth as long as no one with higher priority needs it. target: the 'ideal' target delay that we'll tolerate for an individual flow. ie. how old stuff can be in the queue before we'll consider taking action, like shooting packets to tell people to slow down. interval: I need to check this! pk\_delay: peak packet delay, the oldest packet we had in the queue, ie. how long the oldest packet hung around before we got to dequeue it. av\_delay: the average delay of the packets in the queue that we dequeued. sp\_delay: the delay in the queue for sparse packets. Oh boy: packet flows that send on a continuous basis are regarded as 'bulk' flows (ftp transfer). Packets that flow occasionally are regarded as 'sparse' (think interactive ssh). So this tells you how delayed the 'interactive' packets have been. NB: All the above delay stats are EWMA averages so they can lag slightly or if there's no packet in a tin it can appear to stall. backlog: number of bytes in the queue, waiting to be sent when the shaper says there's space/time to be able to send. pkts(c): number of packets that have flowed through this tin bytes(c): number of bytes that have flowed through this tin way\_inds(c), way\_miss(c), way\_cols(c): Each packet flow is ideally put into an individual queue, these are almost like cache stats and show how succesful we were in achieving that. Mostly uninteresing. drops(c): number of packets we dropped as part of our queue control mechanism marks(c): number of packets we ECN marked (on ECN capable flows) in preference to dropping them. ack\_drop(c): If ack-filtering enabled, number of unnecessary ack only packets that were dropped. sp\_flows: the number of sparse packet flows in this tin bk\_flows: the number of bulk packet flows in this tin un\_flows: the number of unresponsive packet flows in this tin. If a flow doesn't respond to codel style 'slow down' signalling in a normal manner then it is considered unresponsive and is handled by the 'blue' aqm instead. maxlen: the largest packet we've seen in the queue. quantum: granularity in bytes of how much we can de-queue in our queues and release to the shaper. Most of the figures are an instantaneous snapshot or 'gauge' of the current state, I've indicated with a (c) where the values accumulate and thus would need 2 samples over time to produce a 'rate' In terms of key performance display I think: Traffic rate (bytes - prev\_bytes) backlog pk, av, sp delays (vs target) drops rate marks rate sparse, bulk, unresponsive flows --- _[View the full topic](https://forum.openwrt.org/t/sqm-reporting/59960)._