First of all, I want to say that I am not sure whether this is a generic problem, or rather something limited to my Android devices only. Anyhow, on two different multi-core devices, I have observed that Syncthing seems to treat them as single-core. With the default
MaxFolderConcurrency (i.e. “0”), only one folder is being scanned at a time, even though the devices have a dual-core and a quad-core CPUs.
The first CPU is Exynos 4210 Dual (Dual-core 1.2 GHz Cortex-A9). The second CPU is Exynos 4412 Quad (Quad-core 1.6 GHz Cortex-A9). Both seem to be treated as single-core by Syncthing, which means that both
hashers, etc. are set to
1, and need to be adjusted manually for optimal performance.
If you open settings, then the preview for the usage reporting data, then select a version, then scroll down until you see
numCPU - what does it report there?
I see ““numCPU”: 8,” on my xiaomi mi8 phone.
So not generally broken then.
"numCPU": 1 here .
This is Android 4.4. Later, I will try checking it on a device with Android 7.1.
Looking at the Go sources, I think that value is straight from what the OS reports using some system call… though the OS can limit the number of CPUs available to the app of course.
I have installed Android 7.1 on the same device (with Exynos 4210 Dual) and now the reported value is
so the problem may be either about Go and the older versions of Android, or just the older Android itself misreporting something.
I am sorry for “blaming” Syncthing , although I believe that the information may still be useful for those stuck on the older Android releases.
I would like to add one observation related to this problem. When using the Android wrapper, it seems to reset settings like
hashers to the default values on each start. In this case, this is a big problem, as I am unable to manually modify these settings, ending with
hashers = 1 on a quad-core device.
Is this a bug, by design, or perhaps simply an oversight?
In ST Fork, it is enforced to “1” due to issue https://github.com/syncthing/syncthing-android/issues/384 . Maybe as phones get faster and more rock solid android versions over time this decision will proove useless in the future - what I’ve heard around tells me “phones should be able to phone at every possible time” so the user is happy for its functionality even during a Syncthing scan in the background. Those reports like “my phone suddenly reboots under load, apps that I rely on are terminated, cell connection drops on heavy load” personally scared me and took me to this decision. Maybe we’ll make it configurable for you some day :-).
I can understand the logic, but in the case of older devices with multi-core CPUs, yet very weak single-core performance, this really hurts when it comes to scanning performance and time. I would personally much prefer it being limited e.g. to half of the available cores, instead of using all of them, as in the “normal” Syncthing.
Hmm honestly I need to update myself reading the docs about the new maxConcurrency option, maybe that’s just the better solution I waited for since I know Syncthing. Originally, I limited hashers on spinning disks to limit heavy IO slowing the system down, but one hasher per folder isn’t a good approach. It just helps in older ST versions if you also have two or three folders (therefore assumed to be the average mobile sync user)
What strikes my thoughts even more: scanning might be a one time need for most users because then they have little deltas making discussion of scan performance less important. Would be cool if a folder is first scanned or syncthing had discovered how much files need scanning and that’s quite much the ui would offer a gui toggle “hey, you’re scanning a lot atm - we are scanning at medium priority. Would you like to lower or increase that?”
You have a point here, as for me too, it is usually the first scanning that takes forever with
hashes set to
1. I am not a regular user though, as I have been doing a lot of testing with different versions of Syncthing and Android, which means starting from scratch all the time, and I also sync my Joplin notes (10000 files) and DecSync calendars (35000 files), which means a huge number of tiny little files to scan.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.