Community
Laggy due to increase in work-at-home -- coronavirus
Links used in this discussion
Using v6.10.10.0 on Host and Remote,
As of late, the last few days, I've had multiple clients calling me to say that RU is extremely laggy, fails to connect, and drops connections. I can confirm RU's failing because both [censored] and RDP are as quick as ever, suffering no lag and I've tested the circuit and find no issues. I surmise RU is lagging due to routing server overload due to the explosive increase in remote working due to coronavirus. All endpoints are in the US.
So, curious... Does RU route traffic through their infrastructure only for establishing the initial connection and then convert to a true peer-to-peer connection utilizing dynamic firewall pinhole? OR, does RU route all traffic through their infrastructure for the duration of the connection?
Regardless, any insight if my suspicions are correct? Anyone else seeing this?
cheers
Thank you for your message.
The number of users has indeed increased but I can assure you that our servers are still not at their full load. Besides, we expanded our infrastructure in North America and Europe these days just in case anyway. Our servers are capable to withstand a far greater load so I'm inclined to this that this has something to do with local "bottlenecks" since the overall Internet traffic in the world now has increased greatly.
Direct comparisons with competitors are not allowed on this forum. I am sorry for that.
First of all, hey, I love recommending RU to my clients. Works well, decent pricing, and the autopan? feature (moving the viewport as the mouse nears an edge) is great. I first found RU about three years ago and was excited to recommend as an affordable solution to my clients.Conrad Sallian wrote:
Hello Robert,
Thank you for your message.
The number of users has indeed increased but I can assure you that our servers are still not at their full load. Besides, we expanded our infrastructure in North America and Europe these days just in case anyway. Our servers are capable to withstand a far greater load so I'm inclined to this that this has something to do with local "bottlenecks" since the overall Internet traffic in the world now has increased greatly.
Direct comparisons with competitors are not allowed on this forum. I am sorry for that.
When you say "local bottlenecks" -- In RU's local infrastructure (CDN?) or the ISPs in general? As I indicated, I performed several tests to ensure a reliable circuit. And additionally, as I mentioned above, the competitors are working fine (no lag whatsoever) even as I compare RU's performance side-by-side. So it can't be (only) local ISP congestion.
As recently as yesterday, RU is suffering severe lag and connection issues among multiple clients on various ISPs where RUs competitors (at least the two I tried) are not. That's what brought me here. Had I observed these symptoms outside RU then I would not have posted.
Thanks for the rapid reply, I do appreciate that. I'll see how the next few days go.
(And, sorry, but redacting competitor names is silly and petty. We're all adults here and are probably mostly professionals.)
cheers.
The infrastructure was expanded just recently. It may take some time for the load to spread evenly across the servers. I recommend that you try in a few hours to see if there are still any issues and let us know.
Will do. Thanks again.Conrad Sallian wrote:
Hi Robert,
The infrastructure was expanded just recently. It may take some time for the load to spread evenly across the servers. I recommend that you try in a few hours to see if there are still any issues and let us know.
Next time you experience lag, use a program like mtr (winMtr, https://sourceforge.net/projects/winmtr/ ) to check the loss between you and the RUT relay server. After connecting to the host, grab the IP fr om the "IP address/DNS" column in the viewer and enter that into winmtr and click start. That will tell you wh ere the bottleneck is actually happening.Robert Ricketts wrote:
Will do. Thanks again.Conrad Sallian wrote:
Hi Robert,
The infrastructure was expanded just recently. It may take some time for the load to spread evenly across the servers. I recommend that you try in a few hours to see if there are still any issues and let us know.
A couple of years ago, I was really frustrated by the lag and RU said their servers were barely being utilized. This made sense because the problem wasn't their server itself, the problem was the connection to the datacenter their server was hosted in was bottle necked and dropping 80% packets. There are several connections into major data centers, so not everyone would experience this issue. So when RU checks the stats of their server, they'll see it running perfectly fine with lots of capacity available, but the issue is that they have zero insight into network issues outside of the server. The client doesn't do any failover or checking to see which RU server is closer or anything complex like that. RU setting up multiple remote ping monitors will help catch when this happens, but even when it does happen, that would just confirm outages and wouldn't do anything smart to route around the problem.
tl;dr If most of your clients are local, setting up a local relay server would make a huge difference. Also, if you have access to clients router and can configure port forwards, direct access is 10X better than using relay whether its yours or RU's server.
Ever since this pandemic started we have expanded our server network significantly to compensate for the sudden increase in demand for our software. I'm sure many of our competitors had to do the same thing.
Besides, RU servers are spread out across North America and Europe and in most cases the connection is routed via the server closest to the customer.
Thanks.
Conrad, does RUT use hole punching to facilitate a P2P connection after the RUT relay server has established a "trust" between the remote and host?
Unfortunately, no. However, the program can detect whether there is direct connectivity between Viewer and Host and use direct route even if you use Internet-ID connection.
* Website time zone: America/New_York (UTC -4)