I don't wish to be rude but could we maybe have this discussion elsewhere, as it is going off topic to what I asked.
Back to that...
Is there anything I can do to optimise the setup? I'll run some tests and post them later.
It's not off topic; but if you don't wish to risk electrocution determining what phase your devices are on (I don't blame you)...you can try ferrite (iron) beads (choke) on your leading cables. If you have electronic noise causing latency, then electricity is on topic.
1 Like
The main things are:
- Run cat5e/cat6 but obviously if this were easy you'd have done it
- Try powerline with an RFI filter power strip or a clip on ferrite choke on the VDSL modem's power supply to see if you can get away with powerline without destroying your WAN connection
- Try switching channels/reduce congestion on the wifi. particularly try doing your relay backhaul via 5ghz
- Enable RTS/CTS on your relay device if possible, this might help with interference if the relay device is pretty far from the main device (it may not be able to hear quiet devices connected close to the main device), you could set the RTS/CTS threshold to something like 100-200 bytes.
- DSCP tag your important latency sensitive packets, CS6 tag is a good one to use, these packets will get put in the WMM VOICE queue and generally go ahead of the other packets. If you tag medium priority packets CS5 it should go to VIDEO queue, and if you tag low-importance packets CS1 it should go to the background queue.
2 Likes
I would recommend to actually test this, the advantage of WMM VOICE (AC_VO) is that it has a significantly higher probabulity to get the next air-time slot as compared to the other 3 access classes (this is what can result in lower latency and lower jitter), BUT it does not allow aggregation (which for real VoIP traffic should not be a problem). The problem is that not using aggregation will reduce the total bandwidth available noticeably (the wifi preamble part of each transmission takes so long that typically a bunch of packets are sent as an aggregate to reduce the otherwide unfortunate payload to overhead ratio).
So by all means try CS6/AC_VO, but also measure the effect on total throughput so you will not be surprised if AC-VO traffic clobbers your other flows.
Best Regards
I think game traffic also would benefit from voice wmm queue, I agree that you wouldn't want to send high bandwidth flows through the voice queue. The video queue makes more sense for things like preventing your Netflix or IPTV streams from buffering or prioritizing your DNS lookups so webpages don't stall waiting for address resolution, or stuff like that.
Still, a repeater setup is inevitably going to add latency, particularly on a congested channel.
@Gigabit - Sounds very similar to my setup, and a (stupid) issue I had too.
Are you sure it's straight latency? What's ping-time from connected client to "repeater", then from repeater to base? Out to (say) 8.8.8.8?
Then try resolving DNS, preferably something that wouldn't be in cache.
*Mine was a manually configured DNS entry on a (Hyper V) virt nic on my client, because of reasons. Don't forget basic sanity-check troubleshooting!
How would I measure that please?
$ ping -c 10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=8.06 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=8.15 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=121 time=11.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=121 time=7.79 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=121 time=7.95 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=121 time=13.2 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=121 time=7.70 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=121 time=7.80 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=121 time=8.01 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=121 time=8.27 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 7.708/8.859/13.213/1.824 ms
(replace 8.8.8.8 with an IP address or resolvable host name)
Really fast and stable wifi run on free software: Just use ath9k based devices. Their 450Mbit is normaly more then enough. Connect all those with WDS to each other and then there should not exist any more problems.
I don't understand your post @wgqoufsn? I am using the TP-LINK Archer C7 if that helps. The repeater is a TP-LINK WDR3600.
Tried powerline with the ferrite and sadly made little difference so I won't be using powerline networking.
There has been at least on forum member that believes that a device that has an opaque, downloadable firmware ("blob") is somehow evil. I have heard this extreme position around ath9k vs. other wireless chipsets before.
@Gigabit
My answer was maybe too short.
I have set up more then 10 bigger wifi networks based on ath9k+wds. They dont have the lag you was talking about. Thats why i recommend to setup WDS+ath9k. In your example you could try out to use a second WDR3600 and replace the Archer C7 with the WDR3600 to match out.
@jeff
If a "downloadable firmware" is free enough for you, then just stay at the vendor blob instead of using free and opensource software like OpenWrt. The vendor provide in nearly all cases a "downloadable firmware" on his website for the wifi-router he is building/selling.