Anyway for those of you trying to share the network with more apps and people than normal and have solid, stable videoconferencing no matter the load.... It's usually most important to fix the ISP caused bufferbloat. ( https://gettys.wordpress.com/ ), and then the wifi. For major bufferbloat-fixing latency improvements at home, below 400mbit, in the commercial space, presently the evenroute v3 is benchmarking out as the least bloated, ever, on both the wifi and the uplink. They have both fq_codel on the wifi (rfc8290) and cake on the ISP down and uplinks. They autoconfig well and their "sag" feature for detecting upstream bloat seems to work fairly well, especially on dsl, and they are, so far as I know, the only ones to get dsl framing more right out of the box. (I have no financial relationship with evenroute, but they do use all our stuff) 100 people on this one, with a big download from someone else during the test. near-zero latency impact, totally transparent videoconferencing, even over wifi: http://www.dslreports.com/speedtest/62398495 Above 400Mbit I generally recommend rolling a custom x86 fw+sqm solution built around openwrt, ubuntu linux, ipfire, untangle, or (distant last, but if you like bsd), pfsense. There's dozens of others, of course... free.fr's dsl routers do three tiers of fq_codel at "line rate" because they wrote their own debloated dsl driver. Sadly, it's the only debloated dsl driver I know of, and everybody else has to shape. ubnt's edgerouter's sqm, and pfsense's implementations of fq_codel both work ok, but require some configuration, eero's SQM implementation is a little too "automatic" for my taste, and in all these products don't do dsl compensation right, so you have to shape much lower than is theoretically possible to get good latency. There is an out of tree build of "cake" for the edgerouters, which does do dsl framing compensation right. coping with link compensation for cable, fiber, or ethernet is just fine on everything, however. Of course, openwrt, dd-wrt, ipfire, asus-merlin, vyatta, gargoyle, a couple dozen others, have been shipping a decent fq_codel + sqm-derived system for the past 5 years or so, if you haven't taken the time to configure yours, it might contribute to familial harmony if you do.... if you have an old junked router in your closet worth reflashing... some spare time... netduma routers have a fq_codel derived sqm solution but it seems a bit flaky. On just the wifi front... All the broadcom wifi products I have tried... suck. Mt76, ath9k, and and many commercial ath10k based products seem to work ok, but until last month, openwrt's ath10k implementation sucked ( https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/ ) and the fixes are not in a shipping release. yet. eero labs wifi has fq_codel and has an "automagic" sqm implementation but, it's a little too automagic for my taste. Google wifi does have fq_codel, but not sqm. I don't know what plume does except that they do all sorts of snoopy things and claim it's great. Google nest is terrible. The impact of cloudy security cams in general on yer uplink can be terrible. ll the cell phone - tether setups I've tried are terrible - 1.6 sec of bloat, and terrible jitter, regardless. mikrotik's PCQ is sfq-based and is not the greatest, but if that's all you have, turn it on. I have been finding out that while pie is often enabled on docsis 3.1 modems quite a few docsis 3.1 modems are being configured still in a docsis 3.0 mode. You can find out if you are configured for 3.0 sometimes by looking at the config screen (sometimes). Even then I'm unsure if pie is enabled unless my upload speedtest is under 90ms and I see random looking packet loss. still pie usually >10x better than what docsis 3.0 used to do, when it is actually on. Regardless I slam an openwrt box with sqm in front of it, as pie only fixes uplink bloat. I recently had a report on AT&T fiber's 45Mbit symmetric service - over 480ms of bloat on the uplink: http://www.dslreports.com/speedtest/62767361 (They are turning the sqm-scripts on) I'm not equipped to give recommendations for better videoconferencing at home, on other gear. Prioritizing udp not on port 433 almost seems sane, as does implementing sfq or wred if you have it. Saner solutions wanted, zoom in particular wants all kinds of ports prioritized. So far I've seen next to no attempts at diffserv usage either from the videoconferencing world, in packet captures from zoom and other services. On the ipv6 front, so far: zoom does not use ipv6. bluejeans and google hangouts do. jitsi works with ipv6 also. It's unclear if janus meetecho can be configured correctly for ipv6 (any tips?). Haven't tried BBB (anyone?), however I'm told their jitterbuffer was woefully misconfigured in the current release. anyway... in the hope that this helps with familial harmony when you try to share the network at home... I'd love to know you dslreports results and mitigations and more about the QOE of your videoconferences. And I do wish that the unending stream of other PSAs and corporate blog posts about how the internet is holding up would be replaced with useful metrics to those videoconferencing a lot, about loss, jitter and delay. and why is rmcat dead? dave -- Make Music, Not War Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729
