<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 3:48 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:</div><div class=""><p dir="ltr" class="">It's not at all obvious how we'd detect that. Packets are staying in the queue for less time than the codel target, which is exactly what you'd get if you weren't saturated at all.</p></div></blockquote></div><div class="">That makes complete sense when you put it that way. Cake has no way of knowing why the input rate is lower than expected, even if it’s part of the cause.</div><div class=""><br class=""></div><div class="">I don’t think flent can know this either. It can’t easily know the cause for its total output to be lower than expected.</div><div class=""><br class=""></div><div class="">All I know is, this is a common problem in deployments, particularly on low-end hardware like ER-Xs, that can be tricky for users to figure out.</div><div class=""><br class=""></div><div class="">I don’t even think monitoring CPU in general would work. The CPU could be high because it’s doing other calculations, but there’s still enough for cake at a low rate, and there’s no need to warn in that case. I’d be interested in any ideas on how to know this is happening in the system as a whole. So far, there are just various clues that one needs to piece together (no or few drops or marks, less total throughput that expected, high cpu without other external usage, etc). Then it needs to be proven with a test.</div><div class=""><br class=""></div><div class="">Anyway thanks, your clue was what I needed! I need to remember to review the qdisc stats when something unexpected happens.</div></body></html>