What's new

Best setting to reduce latency for real-time audio applications

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I assume you mean minimum as lower latency is better. There is no one value. It based on your network and number of devices and what they are doing.
 
The best way to reduce latency is not use wireless. Latency will always be higher and variable on wifi. The fastest latency will always be hardwired direct to your ISP modem/ONT (not the safest thing), second lowest will be hardwired to a router.

I'm assuming you're gaming, and your game system is not somewhere you can hardwire it? You can do some googling and check over at dslreports - there are some things that can be tweaked and tuned but you end up pulling your hair out as something that seems to help latency now won't later - it was just coincidence etc. I don't think you're going to find any setting that makes any significant difference.

The biggest things you can do is disable legacy clients (B, G, A, etc), ensure your channels are not overlapping with any others nearby (nearly impossible with 2.4ghz especially since you can't see all the bluetooth noise in your area), and use minimum RSSI to kick off clients that have a poor signal. Best you can probably do is dedicate the 5Ghz network to your 1 device that you want good latency on and don't let anything else use it.
 
I have an ASUS RT-AX88U AX6000 with Merlin Firmware, and I'm wondering what wireless settings would reduce latency?
what's the ping to your destination from your wireless device? does it improve if you use a wired connection? Are you running spdMerlin to monitor ping and jitter from your router to your ISP or a server you connect to regularly (google, steam...)?
my router pings my ISP's servers every 10 mins or so, and that varies from upper 6ms ping+jitter to ~15ms (avg <8ms) on a FTTN DSL connection with native IPv6, but I can't tell you how many miles of fibre-optic cabling is between here and there even if I'm only 30ish miles as the crow flies from the datacenter.

distance from router and barriers between router/client would add latency. remove them by adding a copper connection - much less frustrating ultimately than endlessly tweaking and testing.
best would be to have a direct connection with the other computer you're communicating with, but those direct connections are a little expensive unless it's only to the next room. IPv6 might help cut a few nanoseconds off the ping if the other end is using it too, but unless you can choose servers for the fewest hops (either v4 or v6), it pretty much is what it is.

Another thing to have a look at is SQM/QoS - if your ISP has it enabled on their gateway/modem, it might be to help keep their network limping along smoothly for them. You can probably bridge their equipment, use your router to "sign in" to your ISP and use your own QoS to try to eliminate bufferbloat and packet loss, which may "speed up" your internet feel - buffering (like NAT) induces a slight (or sometimes significant) latency that can interfere with "real time/live action" internet activities.

so, while its a lot to look into and get familiar with and possibly change, I hope this helps. remember - you asked ;p lol
 
Unfortunately home internet (whether it be cable or FIOS) suffers from shared technology. FIOS is arguably better due to the far higher bandwidth that it can handle, but it uses TDM technology to share a single fiber with up to 32 other households (through the use of passive beam splitters/combiners). That adds latency ad also jitter, as you have to wait for your "turn" (timeslot) for every packet you send. However they don't have to use as much encoding and compression and there is unlikely to be saturation, unless a lot of people on your segment have gigabit and are using it heavily (they'll usually groom some people onto another fiber in that case). Cable uses heavy encoding and compression (concatenation) to pack more and more bandwidth onto a segment and is also shared with multiple people, often more than FIOS, and has lower capacity to the node (no matter how much encoding you use, there is only so much you can do with 1Ghz, especially when a chunk of that is used up by HD and UHD video streams). So either way, you're not going to get as good latency or jitter as if you had a commercial type point to point ethernet circuit. Even though most of those are also shared, they carve out dedicated bandwidth and it is just switched ethernet without the need for TDM or compression/encoding.

So in other words, there isn't much you can do beyond your carrier's equipment, but you may be able to improve your end of the connection. As I mentioned, hardwiring is the single best thing you can do to improve your latency and jitter. Tweaking wireless settings isn't going to gain a whole lot, in some cases you may make things worse.
 
what's the ping to your destination from your wireless device? does it improve if you use a wired connection? Are you running spdMerlin to monitor ping and jitter from your router to your ISP or a server you connect to regularly (google, steam...)?
my router pings my ISP's servers every 10 mins or so, and that varies from upper 6ms ping+jitter to ~15ms (avg <8ms) on a FTTN DSL connection with native IPv6, but I can't tell you how many miles of fibre-optic cabling is between here and there even if I'm only 30ish miles as the crow flies from the datacenter.

distance from router and barriers between router/client would add latency. remove them by adding a copper connection - much less frustrating ultimately than endlessly tweaking and testing.
best would be to have a direct connection with the other computer you're communicating with, but those direct connections are a little expensive unless it's only to the next room. IPv6 might help cut a few nanoseconds off the ping if the other end is using it too, but unless you can choose servers for the fewest hops (either v4 or v6), it pretty much is what it is.

Another thing to have a look at is SQM/QoS - if your ISP has it enabled on their gateway/modem, it might be to help keep their network limping along smoothly for them. You can probably bridge their equipment, use your router to "sign in" to your ISP and use your own QoS to try to eliminate bufferbloat and packet loss, which may "speed up" your internet feel - buffering (like NAT) induces a slight (or sometimes significant) latency that can interfere with "real time/live action" internet activities.

so, while its a lot to look into and get familiar with and possibly change, I hope this helps. remember - you asked ;p lol

Ping is a really bad indicator of latency. For many years it has been de-prioritized and even before that, can really only be trusted to like 1-2msec granularity. Yes, it can give you an indication and is better than nothing, but not by much. UDP jitter is the best probe to use but finding a destination that supports that can be challenging (they do exist). TCP ping is the next best, again you need to find someone that supports that, but the results aren't as accurate as UDP since UDP measures two separate streams, one outbound, and a separate inbound, where TCP and ICMP measure round trip.

I did extensive testing with Cisco IPSLA (used for monitoring latency and jitter, as well as uptime etc) and the above is based on my findings. Even when ICMP was given the same priority as all other network traffic, it was nowhere near as accurate as the other two. ICMP could fluctuate nearly 1msec, TCP about 500uSec, and UDP was extremely consistent except when the monitoring box was heavily loaded with lots of monitors, even then it was a consistent increase, i.e. having 100 probes running would add 50uSec but that 50uSec didn't change from one test to the next.

IPv6 itself is not any faster or slower. Eliminating NAT can yield some latency improvements, but the much larger header on IPv6 actually adds latency, so it ends up being a wash. A lot of testing has been done and there has been no consistent result. Some found IPv6 slightly faster, some found it actually slower. Since the internet has fewer native IPV6 end-to-end paths than IPv4 (though they are nearing parity at this point) that can have a negative effect on latency also. Some ISPs are still using tunnels and 4to6/6to4 conversions which hurts you too. In reality it comes down to the path you take and the end server. The vast majority of people are still using IPv4 so companies still focus the majority of their capacity on that, putting in a few IPv6 servers to serve the users that are on that. There are a couple exceptions like Google and Facebook who have dedicated a lot of resources to their IPv6 deployment, however if your path to them is longer than the IPv4 route, again, could be worse in the long run.

Fiber distance to your ISPs central office or POP is pretty inconsequential. Around 3.3 uSec per kilometer or 8.xx microseconds per mile.
 
so much you can do with 1Ghz,
You can do plenty with that amount of bandwidth.

My Cell Phone will do 600-700mbps with 100mhz that's shared with tons of users off the same cell.

Cable being async / muxed does fine as well with D3.1, of course it would be nice if D4/FDX were deployed to enable higher speeds and sync bandwidth but, of course they like to drag their feet and keep milking customers at slower speeds. If people realized much faster speeds were available in other countries at 75-80% less per month they would revolt against ISP's.
 
The original post doesn't provide much context/information. Assuming there is an unspecified intermittent problem, and the problem is under your control, my vote for most promising single setting goes to
Adaptive qos/qos/cake.
Good luck

Regards
 
Ping ... can really only be trusted to like 1-2msec granularity.
Which for practical purposes is just fine. Expecting/measuring sub 1 ms latency on an ISP connection or even a home network is not realistic.
 
You can do plenty with that amount of bandwidth.

My Cell Phone will do 600-700mbps with 100mhz that's shared with tons of users off the same cell.

Cable being async / muxed does fine as well with D3.1, of course it would be nice if D4/FDX were deployed to enable higher speeds and sync bandwidth but, of course they like to drag their feet and keep milking customers at slower speeds. If people realized much faster speeds were available in other countries at 75-80% less per month they would revolt against ISP's.

You can do a lot with 1Ghz, but like I said, only so much, and you have to employ lots of encoding and compression both of which introduce latency. You can do a whole lot more with fiber. That's why FIOS HD video clocks in at about 20 megabits per second and cable is about 1/4 that and gets all blocky when there is fast motion.

If you're getting 600 to 700M on your phone, you definitely aren't sharing that cell with tons of other users. Even if they weren't doing any data at all they would still be using up timeslots and killing your throughput. Plus the latency of 5G is worse than even cable in most cases (and this thread is about latency). A lot better than LTE though. I've yet to see speeds that fast except on mmWave and there is an antenna every 100 feet or so for that and anyone who hasn't upgraded to a capable phone isn't using those mini cells, they're using the regular cell sites.
 
Which for practical purposes is just fine. Expecting/measuring sub 1 ms latency on an ISP connection or even a home network is not realistic.

Well if one ping is +2 and the other is -2 that's 4msec off. Not saying a home user needs to be measuring sub-msec but if you're trying to tweak latency and remove a msec or two, then ping is just going to be counterproductive, since it won't be telling you whether what you did actually helped or not. It may appear to have helped then later actually be worse.

What I'm saying is you need something that is consistent and ping just isn't these days.
 
600 to 700M on your phone, you definitely aren't sharing that cell with tons of other users
1650247040172.png

I would find it hard to think there aren't a ton of users in a city of ~2.5M. It did kind of surprise me though it was that high after testing some other providers / plans / sim's in the same area with wide variations in speeds. This is using Tello (MVNO) but all of he TMO MVNO's are testing with these sorts of speeds / network stats. VZW on the other hand fell flat which is funny because i can literally see the node on the pole across the street.
 
View attachment 40864
I would find it hard to think there aren't a ton of users in a city of ~2.5M. It did kind of surprise me though it was that high after testing some other providers / plans / sim's in the same area with wide variations in speeds. This is using Tello (MVNO) but all of he TMO MVNO's are testing with these sorts of speeds / network stats. VZW on the other hand fell flat which is funny because i can literally see the node on the pole across the street.

Nice speeds. Possibly you're on one of the newest bands that only phones from the last year or so support, or maybe they're beefing up infrastructure in your area trying to sell the home internet offering, they seem to be focusing on larger cities for that right now. But the fact that you're on an MVNO and seeing speeds that fast would seem to imply that your tower isn't anywhere near heavily loaded, as you clearly aren't getting deprioritized. I have a Tmo 5G antenna a couple hundred feet from my house (hidden under a steeple on top of an old school thank god) in a suburban area and get around 200M on my Pixel 4A 5G (which supports all the Tmo bands) and that is consistent all the time. But as you can see, there is a latency penalty even on your really fast connection.
 
VZW on the other hand fell flat which is funny because i can literally see the node on the pole across the street.

Curious if you tried other speedtest servers? Something I found out real quick after I got gigabit FiOS is that Verizon underprovisions their speedtest servers, or at least the one nearest to me is. I can semi-reliably get ethernet wire speed (930+Mbps) both up and down to the Comcast speedtest server across town, but Verizon's theoretically-closer server usually reads a very sad fraction of that. In any case, the results vary by time of day and so on, so there are bottlenecks in between. Reading @drinkingbird's point upthread about FiOS being shared with some neighbors, I wonder how much of that is contention with my neighbors and how much is congestion out on the net. Don't suppose there's any good way to tell.
 
FiOS being shared with some neighbors, I wonder how much of that is contention with my neighbors and how much is congestion out on the net. Don't suppose there's any good way to tell.
Everyone knocks cable but, FIOS / telco implementations have their drawbacks as well with passive aggregators in the path that introduce more delays.



It comes down to how VZ laid the fiber and how much total BW is being fed to each "hub" and then split off into the nodes in a neighborhood.
 
What I'm saying is you need something that is consistent and ping just isn't these days.
I beg to differ --- I find ping to be really useful for debugging/optimizing a home network. I agree that pinging random servers out on the net isn't going to give you much beyond a basic connectivity check. But there's nothing you can do about conditions out on the net anyway. What you can do something about is your home net, and logging ping results over time can give you a lot of insight into that.

As an example, awhile back I set up a cron script to steadily ping various other machines (particularly my routers) from my primary workstation, and discovered that the wireless connection to my FiOS router was dropping close to 1% of pings. That's frickin' awful, and it accounted for a lot of the visible performance problems I was having, such as slow web page loads. That eventually drove me to pay somebody to pull ethernet cable to replace that wireless link, something that's improved matters quite a bit. I've also used ping drop rates and round-trip-time stats to determine whether wireless AP placements are good and whether wireless interference is tolerable.

Sure, you are not going to see consistent-to-sub-millisecond ping times across a wireless link, but that's not the point. It's the fraction of dropped or very slow pings that matters.
 
It's the fraction of dropped or very slow pings that matters.
Working for an ISP back in the day and troubleshooting customers the worst connections were ViaSat @ 2000-5000ms pings from our backbone to the customer. Making changes on those devices was painful waiting for the text to catch up to the screen. Scripting things out in notepad and pasting them into the buffer made more sense.

It could always be worse. ;)
 
Curious if you tried other speedtest servers? Something I found out real quick after I got gigabit FiOS is that Verizon underprovisions their speedtest servers, or at least the one nearest to me is. I can semi-reliably get ethernet wire speed (930+Mbps) both up and down to the Comcast speedtest server across town, but Verizon's theoretically-closer server usually reads a very sad fraction of that. In any case, the results vary by time of day and so on, so there are bottlenecks in between. Reading @drinkingbird's point upthread about FiOS being shared with some neighbors, I wonder how much of that is contention with my neighbors and how much is congestion out on the net. Don't suppose there's any good way to tell.

Verizon's speedtest servers use different methodology. The biggest difference (unless Verizon has changed something) is that speedtest.net does multiple streams of data in parallel to better saturate the connection. Speedtest.net also has a lot more servers out there where Verizon just has one or two per region.

Speedtest also adjusts the speed to account for network overhead, in other words it doesn't just report the payload data but the entire packet. Not sure if Verizon does that or not. Generally in my area the two are pretty similar but I'm only at 300M speed tier.

In the past using the verizon speedtest would net better results as you never left their network, but as the speeds have increased, the speedtest.net parallel streams handles the higher speeds better.
 
Everyone knocks cable but, FIOS / telco implementations have their drawbacks as well with passive aggregators in the path that introduce more delays.



It comes down to how VZ laid the fiber and how much total BW is being fed to each "hub" and then split off into the nodes in a neighborhood.
The beam splitters/combiners (passive aggregators) don't introduce any latency, it is the TDM (time division multiplexing) where each user on the shared fiber gets a time slot and has to wait their turn to send each packet. This only impacts upload for the most part but since every TCP connection is 2-way, it impacts your latency. As long as you don't have a ton of other people sharing your fiber it is usually a negligible difference.

While both are shared technology and both have their limitations, FTTP is far better technology. They opted for the passive approach to save having to deploy electric meters on every street and have powered switches with battery backups etc. Or having to do "home runs" of fiber which would have been cost prohibitive. But it still has a lot higher bandwidth (virtually unlimited, just a matter of upgrading equipment to get more capacity) and far less encoding and compression involved.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top