Posted: Sun Jan 07, 2024 0:36 Post subject: Gigabit Fiber best practices vs Gigabit Cable
Background:
I just switched my ISP from gigabit cable to gigabit fiber. Fiber offers several distinct advantages: bidirectional gigabit speeds (vs 50, and then lowered to 35 mbit for cable), lower latency, and better packet handling. As such I've already disabled the QoS algorithm (the reason for which I purchased an x86 router with an intel modem) I had running.
It never really worked right for anything on WiFi, since the bandwidth limit I'd set to match what the ISP could provide exceeded what my WiFi was capable of (Except for upload which is at least something). Almost all my devices, including my main PC, are running over WiFi.
What I've done already:
Now besides disabling QoS on the router, I'm looking at what other optimizations I can perform. I said fibers offers superior packet handling, but that's just a guess on my part to explain why I experience almost no bufferbloat on the network.
I might experiment with different congestion control algorithms, something I had played with when I initially set up my current network. I found Westwood gave the best results on the dslreports speedtest (which incidentally doesn't work for me anymore).
One annoying thing I have on my network that didn't used to be there: I have latency up to 5ms over WiFi:
Code:
56 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=3.680 ms
56 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=3.817 ms
56 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=5.394 ms
56 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.594 ms
56 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=2.754 ms
56 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.454 ms
56 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.305 ms
56 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.517 ms
It was behaving here.... in fact switching to CUBIC congestion control might have done it. Before it inexplicably increased, it was solidly at 0.7ms inter-network regardless if on WiFi or not.
Are there other recommendations here? _________________ Google is Spyware
I re-enabled QoS and set it to 900 mbit up/down. This caused the bufferbloat on the network (as tested by speedtest.net) to fall to under 1ms for both upload and download on a hardwired connection:
Whereas without QoS I had 8ms, 23ms under download, and 16ms under upload.
I'll have to see if this translates into WiFi positively, negatively, or not at all. _________________ Google is Spyware
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Sun Jan 07, 2024 15:43 Post subject:
Fried Chicken wrote:
I re-enabled QoS and set it to 900 mbit up/down. This caused the bufferbloat on the network (as tested by speedtest.net) to fall to under 1ms for both upload and download on a hardwired connection:
Would one require QoS if only one thing is being done in the connection? To check the best speed, shouldn't you limit the amount of uploads and downlaods to just one?
Also, make sure that your connection was not being spammed, at least, not when using a remote website. I have download problems from YouTube from time to time.
Ignore me if you are really testing QoS' balancing instead of best network performance. _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!
I re-enabled QoS and set it to 900 mbit up/down. This caused the bufferbloat on the network (as tested by speedtest.net) to fall to under 1ms for both upload and download on a hardwired connection:
Would one require QoS if only one thing is being done in the connection? To check the best speed, shouldn't you limit the amount of uploads and downlaods to just one?
Also, make sure that your connection was not being spammed, at least, not when using a remote website. I have download problems from YouTube from time to time.
Ignore me if you are really testing QoS' balancing instead of best network performance.
Well it's rare that a home network is ever completely silent _________________ Google is Spyware
