When connecting devices over a LAN cable, what factors influence the time required to complete the connection? In previous trials, the variability has ranged from a few tens of seconds to over 60 seconds. Is this variability normal? Additionally, are there any settings or methods to speed up the connection or make the variability constant?
Connection attempts are made on an interval, which by default is 60s.
@calmh I have a question tangentially related to this: as you may be aware, iOS shuts down an app when it goes to the background (until the user re-activates the app and/or when iOS allows the app to become active at specific times). Between activations the network conditions may change but it appears the Syncthing code is not immediately aware of closed connections. (Additionally I guess network conditions (Wi-Fi, cellular) change a bit more rapidly on a smartphone than in traditional Syncthing usage scenarios.) The intervals ensure that eventually a connection attempt is made, but waiting for 60s (and then for the connection attempts themselves) is a long time for a user who just wants to quickly open the app to get it syncing.
Is there a way/what would you think is a good approach to (programmatically) trigger Syncthing’s code to check the liveness of its connections and/or nudge it to try and reconnect? I would then trigger this on app activation or when iOS notifies the app about a network condition change.
Similar functionality could be of use for OP (I could imagine a button “Attempt to connect” somewhere).
The iOS situation is indeed quite unusual, in that the process gets paused entirely in the background and then resumes after time travelling into the future with connections stalled and whatnot. IIRC you get a notification from iOS when entering background and have a few seconds to do cleanup. It might be an idea to pause devices then (connections drop) and resume them on resume (new connection attempts happen immediately).
Right, that would be a pragmatic solution.
It does rely on the assumption that Synthing will make a connection attempt quite quickly after resuming a peer (this seems to be what it’s doing today anyway but seems a bit implicit). Of course the same assumption is made at app startup.
(Implementing it is also a bit more involved than just flipping the Paused setting. As pausing/resuming peers will be reflected in config, and the user can also explicitly pause peers in the app, I need to do some bookkeeping in the app to ensure I am not resuming peers that were explicitly paused by the user, and this needs to persist so it works even when the app is force-quit or crashes while deactivated.
And indeed, you can ask iOS for some ‘overtime’ after deactivation. iOS will provide an indication of how much time is left. The app should probably ‘linger’ during part of that period, just to prevent disconnect/reconnecting too quickly, so that the user can quickly switch between apps and not notice it).
Thank you for your reply.
I changed the parameter ‘reconnection interval’ and tried several times, but the result remained the same.
The OS used is Linux ‘Ubuntu’ and the device is a Raspi 4. Do you think this method is useful for Ubuntu?
So all of the devices are RPi4’s running Ubuntu?
What’s the LAN setup like? Are all of the devices on the same subnet?
Syncthing is running directly in Ubuntu and not in Docker or some other type of container system?
Yes, ubuntu is running on Raspi4.
Currently, two Raspi are connected directly with a LAN cable.
Syncthing is running directly in Ubuntu.
Could you provide a network diagram? (Details about the IP address configuration would also be very helpful.)
Personally, Syncthing generally finds its peers within a few seconds. I don’t recall ever waiting for over 10 seconds for a connection to be established.
Ah… when you said “cable”, instead of the plural “cables”, I assumed you literally meant a single crossover network connection, but wanted to be sure.
So, it’s not due to the use of the RPi – it could just as easily be two laptops, desktops, and/or any other combo.
Since your point-to-point crossover network connection doesn’t involve a connection to the internet, neither device has use of Syncthing’s discovery servers for looking up each other’s IP address. The two devices then have to rely on local discovery, i.e. broadcasting over the LAN.
Since it’s more than likely that both RPi’s have static IP addresses, on each side for Syncthing, manually specify the IP address for the peer device (Device panel → Edit → Advanced → Addresses).
So you are saying that it is not a specific issue of RasPi, but can also happen with other device combinations?
I had not tried it with other device combinations, so I considered the possibility that it could simply be caused by the RasPi’s slow processing speed.
I will test this with other device combinations.
If it is not a specific issue of RasPi, what is the solution? Once again, the problem is defined as follows.
- the device IDs of both parties are already registered in each other’s connection.
- operationally, the connection and disconnection must be repeated periodically.
- it takes a few ten seconds to over a minute from the physical connection of the LAN cable to‘DeviceConnected’ shown in the event log.
Correct.
No, Syncthing’s device connection stage isn’t CPU-intensive. With the same network setup, the same thing would happen if the RPI was replaced with a pair of high-powered Linux / Windows / macOS machines.
It’s like if you didn’t know that Syncthing’s homepage was at syncthing.net, trying to search the entire internet for it could be time-consuming. So to speed things up you’d likely run a search on google.com, but if you didn’t have access to google.com then you wouldn’t be able to do the search.
According to your network diagram, Syncthing on your RPi boxes cannot do a search at Syncthing’s discovery servers, so they have to try and find each other without it, which can take a lot longer.
So the solution is to tell Syncthing what the IP address is of the other device rather than have Syncthing spend time trying to find out on its own.
For the remote Syncthing device, click [Edit] → [Advanced] and change the “Addresses” field from “dynamic” to a fixed IP address – e.g. tcp://1.2.3.4:22000 (replace 1.2.3.4 with the one for the RPi). Do the same for each RPi, pointing Syncthing at the other.
Sorry for the late reply.
I have tried the above method.
I thought that registering the address in one of the syncs would improve the connection speed a little, but unfortunately, there was no change.
I guess it is only effective if both of us have registered our addresses.
I will keep trying.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.