<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 3, 2015 at 3:27 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>kbps = quantum = time</div><div><div>20000 = 3000 = 1.2ms</div><div>30000 = 6000 = 1.6ms</div><div>40000 = 12000 = 2.4ms</div><div>50000 = 24000 = 3.84ms</div><div>60000 = 48000 = 6.4ms</div><div>80000 = 96000 = 9.6ms</div></div></div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>So it appears that the goal of these values was to keep increases the quantum as rates went up to provide more bytes per operation, but that's going to risk adding latency as the time-per-quantum crosses the delay target in fq_codel (if I'm understanding this correctly).</div><div><br></div><div>So one thing that I can do is play around with this, and see if I can keep that quantum time at a linear level (ie, 10ms, which seems _awfully_ long), or continue increasing it (which seems like a bad idea).  I'd love to hear from whoever put this in as to what it's goal was (or was it just empirically tuned?)</div></div></div></div></blockquote><div><br></div></div></div><div>Empirical and tested only to about 60Mbits. I got back about 15% cpu to do it this way at the time I did it on the wndr3800.</div></div></div></div></blockquote><div><br></div><div>Basically, increasing the quantums to get more cpu available...  So a too-small quantum is going to be excessive cpu, and a too-large quantum is going to be poor fairness?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and WOW, thx for the analysis! I did not think much about this crossover point at the time - because we'd maxed on cpu long beforehand. <br></div></div></div></div></blockquote><div><br></div><div>No problem, this is the sort of thing I _can_ help with, since I don't know the kernel internals very well.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>I can certainly see this batching interacting with the codel target.<br></div></div></div></div></blockquote><div><br></div><div>Which may also explain your comments about poor fairness on my 3800 results when up at 60-80Mbps, when htb's quantum has crossed over fq_codel's target?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>On the other hand, you gotta not be running out of cpu in the first place. I am liking where cake is going.<br></div></div></div></div></blockquote><div><br></div><div>Yeah.  That's what I _also_ need to figure out.  Load seems "reasonable", but load and cpu stats get reported oddly on multi-core (some things are per-core, some are per-total available, etc).  I know I've seen the "soft_irq" thread at 70% in top doing some tests (in the past).  I wouldn't be surprised if this is a single-core-only bit of code?  (or can htb processing and fq_codel processing be shoved to separate cores?)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>One of my daydreams is that once we have writable custom ethernet hardware that we can easily do hardware outbound rate limiting/shaping merely by programming a register to return a completion interrupt at the set rate rather than the actual rate. </div></div></div></div></blockquote><div><br></div><div>well, inbound is certainly more of an issue than outbound right now...</div><div><br></div><div>So, for my next rounds of tests, I can play around with different quantum values/schemes, and also play with simple.qos vs. simplest.qos, and instrument the whole thing to capture processor utilization vs. bandwidth.</div><div><br></div><div>-Aaron</div></div></div></div>