"slow" relay servers

Feature
1

Hi,

I just experienced a somewhat uncomfortable situation. I wanted to sync an android tablet via WLAN / eduroam / indoor network in Berlin to a workstation connected via vpn tunnel with exit point somewhere in Munich (800km) . So data packets from the PC here drop out in Munich. Both clients are looking at each other at a 30cm distance. Some people want to see the world burn. That’s ok.

So far so good, that is an evil setup, I know. After waiting serveral minutes (10 - 20), rescans, restarts whatever we tried suddenly the two machines registered each other. All took much much … much longer as expected, so we finally got sync started. But then we had extreme slow rates, about 10 kiloBytes and lower per second.

I hunted it down to the relayserver we were magically connected to:

for what reason ever: the Munich part ended up on a relay server in .cz with 99 clients, > 500 sessions and an bandwidth limit of 150 kB/s.

For me, fixing this is no problem at all, I took the relay-ip, went to the web page, found the relay server I was connected to and was technically able to calculate that this was the culprit. Even reconfiguring each client to use our own 10 GbE relayserver was no problem. I now get about 20-40 MegaByte/s .

But I’m thinking about people who just experience unresponsiveness, slow rates, and connection problems using the defaults after getting redirected to a bw-limited strelaysrv.

How is it even possible a 150 kB/s relay is getting hundreds of clients ?

I see it’s nice to have a lot of relays, this is why we also provide one. But I fear due to such slowdowns like the above mentioned some people start thinking twice before using syncthing. “Yeah, I tried it. Nice. But too slow.”

Maybe we could have a look at the relay selection algorithm for default setup ?

Cheers, Peter

2 Likes
2

The idea is to not use a relay. If you are using a relay, it’s usually because you have to, and if you have to, “something” is better than “nothing”.

3

The original post refers to Android, but doesn’t state the version used.

This could be related to the current 0.14.45 syncing issues, which I am also experiencing. On my device, the normal connection by discovery server kept failing, and the Android app started trying to connect using relays (and failing too).

So before we assume there is a chronic algorithm problem, let’s make sure it isn’t the connection issue that all users of St-Android 0.10.5 are experiencing.

4

Phrases like

[…] Some people want to see the world burn. That’s ok.

So far so good, that is an evil setup, I know. […]

[…] Even reconfiguring each client to use our own 10 GbE relayserver was no problem. I now get about 20-40 MegaByte/s .

suggests to me that Peter is perfectly aware that the root problem is the setup and the recent Android problem hardly is connected. One thing that Audrius refers to: Setting up your own relay to connect devices sitting 30cm from each other may work wonders, but why not connect them directly? That’s what Audrius is referring to: Relays are a last resort when other means of connection fail. But I don’t think that’s the point of interest in this discussion.

I think the main question is: How does Syncthing decide to which relay to connect to?

5 
// relayAddressesOrder checks the latency to each relay, rounds latency down to
// the closest 50ms, and puts them in buckets of 50ms latency ranges. Then
// shuffles each bucket, and returns all addresses starting with the ones from
// the lowest latency bucket, ending with the highest latency buceket.

We then pick the first that works, I think.

This is essentially optimized for getting a relay on the same continent. There is no other value judgement. Some will provide better service than others. In most cases you get better service than you paid for. :slight_smile:

2 Likes
6

Sorry, but I intentionally didn’t mention the version number, since I don’t consider this a bug report, but a needed fix to prevent bad user experience.

Relaying is explicitly documented as Relaying — Syncthing v1 documentation for “when it’s not possible to establish a direct connection”.

We’re trying to introduce Syncthing as an open source alternative to dropbox/Onedrive/googledrive and even {own,next}cloud, since it’s principle covers almost all of our use cases.

In the default settings I ended up yesterday on a 150kB/s limited relay. Today I find my mobile device, which is not able to establish a direct connection to my workstation due to firewalls, via local guest WLAN on a relay in Paris. Ping to Paris 14ms. Our own relay pings @ 0.250 ms.

This is not a question of “something” vs “nothing”. If a direct connection was possible, there are tons of ways to keep data synced. In my view Syncthing is a game changer due to its ability to relay.

And again, I’m able to configure/fix it. I’m talking about the defaults. Global user experience :sunglasses:

1 Like
7

Exactly. Relays are essential, they’re the reason I started looking for solutions (and found Syncthing) in the first place. If I had a direct connection possibility (including even sneakernet) I wouldn’t have needed syncthing. For all the devices I use I am never in a position to adjust firewalls or routes. I can (and have, on occasion), edited syncthing config to find a better relay, but that’s all (and it’s not reliable because that relay may not be available at all times). So the normal use case is always “install and run”, no config except introducing devices and folders.

3 Likes