Another option is to try to tag voice/video packets with DSCP as they enter your router, so they get into a higher WMM queue... ideally WMM VO for the voice and VI for the video...
That is a good point, but I ain't going there: I want to spend less time managing the network, not more 
Thx, I will try all of these over the next several days.
That is at least debatable, sure the IEEE 802.11e access class names AC_VI and AC_VO imply this usage, as does RFC8325 https://tools.ietf.org/html/rfc8325, but there is precious little literature about testing this idea in the real world. In principle and in normal situation it should work well, but the AC_VO trumps all others, AC_VI is only trumped by AC_VO and the common AC_BE is trumped by both AC_VI and AC_VO, which, if there is too much traffic in the higher priority ACs, can lead to almost complete starvation of lower priority traffic.
As long as neither the AC_VO + AC_VO traffic saturates the links forward progress for all flows should be guaranteed, so typically measured use of the higher ACs can be a good thing, one just needs to keep the potential side-effects in mind.
Yes, it's definitely the case that VO traffic should be a small fraction of the capacity in order to play nicely. Fortunately, modern voice traffic is going to use typically less than 200kbps for both directions total, per call, and capacity of the link is very typically 25-150 Mbps... so even with 10 simultaneous calls you're going to use less than 10% of the link.
Video might use a megabit or two, so you can still do 4 or 5 simultaneous video calls on typical connections.
My experience is that tagging voice RTP packets AC_VO works well for up to 2 or 3 calls simultaneously in typical home environments. I haven't tested more than that.
all this being said, when I have the option of answering my cordless phone connected to a wired ATA instead of using Bria on my Android phone, I do it... much less hassle with things like turning around and suddenly my head is shielding the phone from talking to the AP on 5GHz etc.
1 Like
Hey folks, traffic prioritization was not an issue here: there was a single wireless client in a voice/video call. There was supposed to be plenty of bandwidth and muscle left to handle it (Netgear R7800) Let’s not digress, pls.
This might just be a dead spot problem. I got a spare gl-ar750 to repurpose to an AP with a dedicated SSID and place it in different locations with a wired backbone.
What I noticed so far is that when placed 2m away from my desk, my laptop connects to 5GHz and stays there. Once I move it to my desk, it downgrades to 2Ghz within a few minutes.
1 Like
Could this be a problem with 802.11w or 802.11r?
I do not use 11r (at least not knowingly). I have just disabled 11w on the AP on both bands and will watch it.
while i agree that manual priorisation is very rarely adviseable/neccesary, i think @moeller0 was refering to the practice of using dscp for wifi-admission control which could be influencing your quality of experience if employed by your own or other ap's on the channel.
but yea, it's probably something else 
1 Like
Other APs on the same frequency can still take away tx_ops from your call, worse these might be located such that onlt the STA or the AP actually sees them (hidden node problem), in that unlikely case prioritization might help, as higher AC have considerably higher probability to grab air time (it will not help against the hidden node problem though, as either AP or STA by virtue of not "sensing" the hidden node will send concurrent frames).
That should be easy to test, no? Just try moving the laptop around and or reposition the AP and/or its antennae.
If you have neighbors on the same channels then the WMM class affects your results even if you yourself have relatively little traffic. Also the issue isn't with bandwidth sharing but latency. Devices like smartphones do heavy power saving that can make latency go into the hundreds of ms. they will generally perform better on VO access class by not waiting to aggregate small packets.
Ok, pardon my ignorance: I did not know that. Either way, this is not “low hanging fruit” solution and I will leave it for last.
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.
Big players such as Google, GitHub or Cloudflare have to deal with DDoS attacks using SYN flood over 100+ GBps connections. Anything you can do from a single computer is not going to cause a dent to their systems.
For example of real world limits, see https://blog.cloudflare.com/how-to-drop-10-million-packets/ and https://blog.cloudflare.com/the-root-cause-of-large-ddos-ip-spoofing/ and https://github.blog/2018-03-01-ddos-incident-report/
Yes, but anything they let you do from a single computer, you can do from a botnet of 1 million computers and get 1 million times the effect too. The point was from a security standpoint I would still expect people to filter ping traffic. There is no legitimate use for say a gigabit/s of ping traffic coming from a FTTH network to be responded to by google.
This is off topic though. Evidently they don't mind 100Hz pings, so go for it if you want to look at latency variation for small packets.
1 Like
So, on a somewhat related note, 8.8.8.8 and gstatic.com for that matter actually respond to ICMP echo requests @ 100Hz, but they started only returning small ICMP return packets:
laptop:~ user$ ping -c 1 -s 1400 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1400 data bytes
76 bytes from 8.8.8.8: icmp_seq=0 ttl=53 time=8.950 ms
wrong total length 96 instead of 1428
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.950/8.950/8.950/0.000 ms
laptop:~ user$ ping -c 1 -s 1400 gstatic.com
PING gstatic.com (172.217.23.163): 1400 data bytes
76 bytes from 172.217.23.163: icmp_seq=0 ttl=53 time=8.957 ms
wrong total length 96 instead of 1428
--- gstatic.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.957/8.957/8.957/0.000 ms
A real pitty, and potentially a chance...
1 Like
So, it was indeed a bad location. I now got myself a dedicated AP (GL-B1300) and it is running pretty well.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.