<div dir="ltr"><div>Over here we have been having a great deal of fun speculating about some increasingly researchy ideas for the cake queuing discipline, and in the last section, discussing at more length means to cope with the 40ms, 15s bump (or bang) presently in there while preserving correct behavior of existing congestion controls. Some great comments are here:</div><div><br></div><div><a href="https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit">https://docs.google.com/document/d/1tTYBPeaRdCO9AGTGQCpoiuLORQzN_bG3TAkEolJPh28/edit</a><br></div><div><br></div><div>so many unknowns! </div><div><br></div><div><div>One of the things we learned from the initial teardowns of the dishy was that it has a ntpd supported GPS chip, which means the dishy could be supplying really accurate time via ntp or pptp to routers downstream of it. It would be cool if it did that, but so far as I know, still doesn´t. A precisely synced router could more smartly buffer and drop packets. <br></div></div><div><br></div><div>How likely is it for this reconfiguration interval to remain a thing? I´d hate to burn the time coding up the concept (and slaving a router to another time sync source - I still have a couple of the 1 pps gps dongles we built as part of the thumbgps project lying around, more than a few people here have gps on their raspi hats) only to see it vanish, as much as I would like it to vanish. </div><div> </div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Oct 30: <a href="https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html" target="_blank">https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html</a></div><div>Dave Täht CSO, LibreQos<br></div></div></div></div>