<div dir="ltr"><div>

<div dir="ltr" style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">On Tue, Jul 24, 2018 at 4:44 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 25 Jul, 2018, at 12:39 am, Benjamin Cronce <<a href="mailto:bcronce@gmail.com" style="color:rgb(17,85,204)" target="_blank">bcronce@gmail.com</a>> wrote:<br>><span> </span><br>> Just looking visual at the DSLReport graphs, I more normally see maybe a few 40ms-150ms ping spikes, while my own attempts to shape can get me several 300ms spikes. I would really need a lot more samples and actually run the numbers on them, but just causally looking at them, I get the sense that mine is worse.<br><br>That could just be an artefact of your browser's scheduling latency.  Try running an independent ping test alongside for verification.<br><br>Currently one of my machines has Chrome exhibiting frequent and very noticeable "hitching", while Firefox on the same machine is much smoother.  Similar behaviour would easily be enough to cause such data anomalies.<br><br> - Jonathan Morton</blockquote>

<br></div><div>Challenge accepted. 10 pings per second at my ISP's speedtest server. My wife was watching Sing for the millionth time on Netflix during these tests.</div><div><br></div><div>Idle</div><div>Packets: sent=300, rcvd=300, error=0, lost=0 (0.0% loss) in 29.903240 sec</div><div>RTTs in ms: min/avg/max/dev: 1.554 / 2.160 / 3.368 / 0.179</div><div>Bandwidth in kbytes/sec: sent=0.601, rcvd=0.601</div><div> </div><div>shaping</div><div>------------------------</div><div>During download</div><div>Packets: sent=123, rcvd=122, error=0, lost=1 (0.8% loss) in 12.203803 sec</div><div>RTTs in ms: min/avg/max/dev: 1.459 / 2.831 / 8.281 / 0.955</div><div>Bandwidth in kbytes/sec: sent=0.604, rcvd=0.599</div><div><br></div><div>During upload</div><div>Packets: sent=196, rcvd=195, error=0, lost=1 (0.5% loss) in 19.503948 sec</div><div>RTTs in ms: min/avg/max/dev: 1.608 / 3.247 / 5.471 / 0.853</div><div>Bandwidth in kbytes/sec: sent=0.602, rcvd=0.599</div><div><br></div><div>no shaping</div><div>-----------------------------</div><div>During download</div><div>Packets: sent=147, rcvd=147, error=0, lost=0 (0.0% loss) in 14.604027 sec</div><div>RTTs in ms: min/avg/max/dev: 1.161 / 2.110 / 13.525 / 1.069</div><div>Bandwidth in kbytes/sec: sent=0.603, rcvd=0.603</div><div><br></div><div>During upload</div><div>Packets: sent=199, rcvd=199, error=0, lost=0 (0.0% loss) in 19.802377 sec</div><div>RTTs in ms: min/avg/max/dev: 1.238 / 2.071 / 4.715 / 0.373</div><div>Bandwidth in kbytes/sec: sent=0.602, rcvd=0.602</div><div><br></div><div>Now I really feel like disabling shaping on my end. The TCP streams have increased loss without shaping, but my ICMP looks better. Better flow isolation? Need me some fq_Codel or Cake. Going to set fq_Codel to something like target 3ms and 45ms RTT. Due to CDNs and regional gaming servers, something like 95% of everything is less than 30ms away and something like 80% is like less than 15ms away. </div><div><br></div><div>Akamai 1-2ms </div><div>Netflix 2-3ms</div><div>Hulu 2-3ms</div><div>Cloudflare 9ms</div><div>Discord 9ms</div><div>World of Warcraft/Battle.Net 9ms</div><div>Youtube 12ms</div><div><br></div><div>Too short of tests, but interesting.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 24, 2018 at 4:58 PM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 24, 2018 at 2:39 PM Benjamin Cronce <<a href="mailto:bcronce@gmail.com" target="_blank">bcronce@gmail.com</a>> wrote:<br>
> Just looking visual at the DSLReport graphs, I more normally see maybe a few 40ms-150ms ping spikes, while my own attempts to shape can get me several 300ms spikes. I would really need a lot more samples and actually run the numbers on them, but just causally looking at them, I get the sense that mine is worse.<br>
<br>
too gentle we are perhaps. out of cpu you may be.<br><br></blockquote><div>Possible FairQ uses more CPU than expected, but I have load tested my firewall, using HFSC  with ~ 8 queues shaped to 1Gb/s and Codel on the queues. Using iperf, I was able to send ~1.4Mil pps, about 1Gb/s of 64byte UDP packets. pfSense was claiming about 1.4Mpps ingress the LAN and 1.4Mpps egress the WAN. CPU was hovering around 17% on my quad core with CPU load roughly equal across all 4 cores. Core i5 with low latency DDR3 and Intel i350 NIC is nice.</div><div><br></div><div>MTU sized packets iperf using bi-directional TCP results in about 1.85Gb/s, which is inline with the ~940Mb/s per direction on Ethernet, and something ridiculous like 4% CPU and 150 interrupts per second. This NIC is magical. I'm assuming soft interrupts.</div></div></div>