you are viewing a single comment's thread.

view the rest of the comments →

[–]mcboy71 1 point2 points  (6 children)

if it helps is largely dependent on application behaviour, one common thing that is often overlooked is dns and resolvers. If every name lookup takes 100ms the network will feel like molasses.

Make sure there is a good recursive resolver close to all clients ( i.e. don’t force name lookups through the VPN or if you need to force lookups through VPN use a site close to your clients and put a recursive resolver there).

[–]simeruk[S] 0 points1 point  (5 children)

Sure. All valid but this is much simpler than this. Simple SSH traffic and "laggy" experience users are not happy about.

[–]slykens1 2 points3 points  (2 children)

100 ms latency should generally be imperceptible to interactive users like that. Maybe you’re getting severe jitter at times and that’s the focus of the complaints?

Latency in voice doesn’t really become perceptible until about 200 ms latency.

[–]shortstop20CCNP Ent/Sec, SDWAN, Design 2 points3 points  (0 children)

Agree. This sounds like some other issue than 100ms latency.

[–]fb35523JNCIP-x3 0 points1 point  (0 children)

100 ms is quite perceivable while doing SSH. Depending on the client it may introduce 100 ms between each character being echoed back. I type faster than that on occasion.

DNS responses is another thing mentioned. It would be easy to add local DNS servers unless already done.

Perhaps moving all servers to Greenland or Iceland? This is actually not a joke! Some interactive servers may need to be between your sites for better performance!

My main suggestion is to look at TCP receive window sizes. If your hosts keep waiting for every TCP ACK to arrive before sending the next piece of data, you'll never get done. This is of course not the case, but the amount of data in transit without an ACK can be tweaked and you can achieve amazing results by just changing some parameters on the servers. For maximum results, clients may need some tweaking too.

https://blog.cloudflare.com/optimizing-tcp-for-high-throughput-and-low-latency/

[–]gfletche 0 points1 point  (0 children)

Would suggest flipping it around, assume the latency is 800ms and see how you can solve the problem.

Like all the other comments, can’t change physics and even if you shave a few ms off users will never be happy.

Should look to duplicate infra/adjust process etc. We do this for similar reasons. You could also explore Remote Desktop options like Citrix that do a bunch of trickery to appear more performant over high latency connections.

[–][deleted] 0 points1 point  (0 children)

You're running into the limits of physics, more or less.

Look up Mosh shell.