Hi all, I have been experiencing choppy voice/video calls over WiFi for a while now and tried different channels and bands with no success. At times I would even go and sit next to the router to see if the signals strength is an issue, but that would only provide a marginal improvement. During my calls I am the only user, so this is not caused by a congestion. I am mostly running the non-CT firmware (the latest), but tried with CT for a few days and did not see any major difference.
I am currently running a few day's old build of 19.07 on a Netgear R7800 router. The line is VDSL2 50M/10M and is always in a perfect shape with ~11ms ping 24/7: wired gaming is awesome.
Could I be missing some configuration/tuning? Are there any troubleshooting steps I could take to isolate the issue?
Yes, I think so. When I am in the office myself the quality of calls is very good from all participants. When I am remote, I am having the same choppy audio/video with people in other geographies. It is definitely on my end.
might be intresting to fire up $ noping -i.05 8.8.8.8 on a wifi device an see how that fares.
the combination of a wired-wireless bridge and a lot of ssid's might indicate a lot of "background-traffic noise" on your wifi-channel.
ping as user will not go below .2s but as root it will. noping will do everything as user and give live stats and graph for better overview.
.2s = 5Hz is probaly not realistic for simulating voip. 0.1 - 0.01 (100Hz) moreso
This is not an apartment building and I see 12 APs on 5GHz band and over 50 on 2Ghz, but at least 2/3 of them are reported as 50% signal and lower.
In the mean time, I have dropped SQM up/down limits from 95% to 90%. I also found an old thread of mine where it was suggested to me to disable offloads and flow control on the interfaces (SQM might not be handling packets of several hundred kilobytes in size very well). So far I have had two video calls over the last two days of great quality.
I do not know if those changes have fixed the issue or it is just a coincidence. I will monitor for now.
Thx, I will run this test later if things get worse again.
These are way too many already. And while the signal from them might not look much, if a client is closer to you than his access point, it may cause interference that is hard to detect.
Please look for something that is called channel utilization. It some kind of measure for the capacity left on your WiFi and measures energy (?).
Then I'm at home I can look for a script.
those with config defaults from the 90's maybe, but anything "2k19 internet scale" wont care for 100pps of 64byte icmp traffic. (watching a youtube video will incur in the order of 500pps 100byte+ http-acks).
Well, they should still do. It's not just about whether the beefy machine can handle it, it's more about whether the beefy machine can be used as a reflector for enormous quantities of spoofed traffic from disseminated botnets etc.
Imagine if 1 million hacked IP cameras are sending 100Hz ping floods with spoofed sources... Suddenly corporation X is getting 100 million pings per second from their DNS provider...
Of course, a site like 8.8.8.8 might just limit the total ping output... in which case one guy asking for 100Hz would be ok... but as soon as you're up to 2000 ping packets per second, the rest are dropped on the floor. That'd be a decent strategy.
I have done this so far with sudo ping -i 0.01 8.8.8.8. It does not seem to look too-too terrible, but I have not had big video/voice issues in the last several days.
This is with today's build of 19.07 (I use the image builder, so my build is a little behind GitHub sources) and the latest and greatest non-CT firmware (I package the latest board-2.bin and firmware-5.bin from kvalo).
2.4GHz, channel 11 / 20 MHz width, RSSI -65 dBm (5GHz band does not reach this location very well).
--- 8.8.8.8 ping statistics ---
100000 packets transmitted, 99918 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 11.089/15.630/248.881/7.584 ms
--- 8.8.8.8 ping statistics ---
10000 packets transmitted, 9993 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 11.244/14.949/137.560/5.539 ms
--- 8.8.8.8 ping statistics ---
10000 packets transmitted, 9998 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.064/15.022/99.108/5.142 ms
yea, but the ping amplification factor of 1 isn't going to scare anyone (compared with dns(-sec) or various db's ...) we are talking about 100*64byte=6,4Kbyte/s ...
also
TIL: neither ping-program will send out pings in parallel, so they're capped at 1000ms/rtt=pps (100Hz@10ms)
@fantom-x your stats dont look too bad.
would be interested to see measurements from when your problem manifests again.
True, it's always way worse when the amplification factor is greater than 1. But if Google DNS is sending you a reflected ping flood, then how well is your entire corporate network going to work when it relies on being able to look up DNS entries from google?
In any case, it's easy to cap ping responses in aggregate rather than per host, and that's a reasonable strategy, if Google's entire local server farm is limited to a total of 2000 pings/second leaving the site, it probably doesn't affect anything google legitimately needs to do, and it's a good way to avoid any serious flooding.
I always tell people to check their neighborhood and pick the clearest channel, the autoselect often seems to do a lousy job of managing this.
Try going narrower vs wider in bandwith, it lowers your interference footprint. In some cases you might get better thruput despite the lower max speed. Disabling legacy rates might help a bit as well.
Finding your sweet spot in SQM settings is good, too. Sounds like backing the rate down did sonething for you. The more advanced tuning instructions are worth checking out.
Lastly, if you're not using it already, the DSLReports Speedtest test, with the high res bufferbloat and suggested settings turned on, (a thread here I dont have handy has them) is instructive with hi res graphs of latency to help with your tuning efforts.
