In https://github.com/syncthing/syncthing/issues/4306, I described bandwidth limiting to remote machines seemingly not functioning anymore (did work with earlier versions), but the issue was closed a few minutes later and I was redirected here by AudriusButkevicius.
So, here we go again:
It seems to that in version 0.14.36 the global outgoing bandwidth limit isn’t respected correctly (which worked before). I’ve tried with 0.14.36 on both 64-bit Linux (Ubuntu 14.04.5) and 64-bit Windows 7.
On my side, the linux machines are limited to 210 KB/s. When watching the outbound data rate to another system, it stays at 0 B/s for a while, jumps to 445 KB/s and transfers data, then VERY shortly jumps to 210 KB/s and back to 0 again. In earlier versions, using the same machines, it steadily transmitted around 210 KB/s, maybe +/- 5 KB/s.
On a colleague’s (Windows 7) machine, it does the same. We limited him to around 35 KB/s since he has only an upload of 444 kbit/s and needs some headroom, say for streaming to an internet radio and/or using Mumble. In earlier versions, this worked fine, i.e. no interruptions when streaming/talking, now we hear interrupts whenever Syncthing starts using the full bandwidth.
Any ideas?
Nothing has changed in that area of code for tens of releases now, so if you still want to talk about this, forum is probably the right place, as it doesn’t seem to me like an obvious bug.
Hm. The settings haven’t been changed, all participating (all remote) machines are in use between one and two years now, over many versions, and syncing about 1.2 mio files over the internet. And I’m looking at the single remote machine’s transfer rates in the GUI.
Has anyone else also experienced this behaviour?
Any ideas what can be checked or done to make it work again?
Here’s some more info. The GUI shows upload rates of up to 7.60 Mbps while I only have 2.362 kbps!
“studio1” system:
Syncthing 0.14.36
OS: Ubuntu Studio 14.04.5 LTS
“lenny” system (remote):
Syncthing 0.14.36
OS: Linux Mint 17.3/Cinnamon (based on Ubuntu 14.04)
Browser: Firefox 54.0 (64-bit)
Maybe it’s (partly?) a GUI/Browser/Javascript problem?
It definitely did not behave like this in earlier versions. Can’t say which exactly, maybe 5-10 versions back, since we’ve been using Syncthing for about 2 years now and after initial testing just leave it running and updating 24/7.
Screenshots:
(Sorry the forum tells me I can only upload 1 image per post, so I’ll need to follow up)
The limiter uses a burst size of 512 KiB, so small transfers can exceed the set rate. If there is more data to send it’ll even out the rate. I’m not really sure what’s going on with the rate in the Syncthing GUI (maybe try reloading it?), but what you see in the fritzbox is <210 KiB/s at least.
Would that explain that I experience no “stuttering” problems with 2362 kbit/s upload while the colleague with only 444 kbit/s does? Because maybe it uses HIS full bandwidth for a short time?
I actually went and checked on my Fritzbox (unfortunately I can’t check the other one) and it seems to eat up around 2.000 kbit/s constantly, with slight deviations, effectively leaving enough headroom for doing something else (like a 128 kbit/s stream using IDJC).
210 * 8 gives only 1680 but I assume the rest is protocol overhead?
I still wonder why (at least the GUI display) now shows 0 most oft the time, plus the short “bursts”. Previously, it showed more like a consistent data rate with very short “0” phases in between. Could that be some changed display refresh rate or maybe even Firefox’s new “multi-thread” approach?
Questions over questions … sorry. The main question, of course, is still: Can we reliably limit bandwidth for low bandwidth upload connections in a way that would not congest and thus leave the possibility for stutter-free talking (i.e., Mumble) or streaming (i.e., IDJC)?
Syncthing GUI when transmitting one big video file (~513 MB) for testing to both “lenny” and “studio”.
Global “Upload” switches between ca. 10s of “0 B” and 6–8s of too high KiB/s, like 409 KiB/s in this screenshot, ended by a short (maybe tenth of a second) value that lies BELOW the specified limit.
Like:
10s — 0 B
6-8s — 409 Kib/s
1/10s – 205 KiB/s
10s – 0 B
6-8s — 613 KiB/s
1/10s – 210 KiB/s
and so on
I am not sure whether that works reliably: In my case connections are often at a random port (currently e.g. 36436). As I understood the listen port (usually 22000) is always used for the initial connection, but another port might be used for the actual transaction.
It’s always the configured sync port (by default 22000) on one side, something random on the other. So wweich’s case should cover both. Well, unless there is a uPnP-created port forward, which will make the listen port random as well.
@wweich: Actually not a bad idea if … someone has a modern FritzBox and quite new FritzOS and a fixed port.
Unfortunately, not all have. Or aren’t knowledgeable or willing to change things within their routers.
The beauty of Syncthing for many is that it’s kind of install, setup, forget and it just works software.
On my side, I could of course test, change and do almost anything, but not for some peers. And on my side I have enough upload bandwidth so things work anyway, more or less. Not so for some low-bandwidth peers, unfortunately.
Today, with the Firefox update to v55.0.2 (64-Bit), the GUI responds correctly again, i.e., shows between “205 KiB/s” and “218 KiB/s” permanently (instead of jumping).
So maybe it really was a problem with Firefox’ new “multithreading” system after all.
