I have a RPi 1 Model B+ running the 11/25/16 release of Raspbian Jessie Lite. It is running off a 64GB UHS 1 Class 10 Micro SDXC card. It is connected directly to my router via ethernet. I have it setup as a headless server on which I am running deluged (the Deluge daemon) as a systemd service. I've installed hardly anything else and no other processes using significant resources are running (as far as I am aware).

The issue is that while a torrent is actively downloading, the download speed consistently goes between being reasonably fast to super slow. In other words, it will have a fast download speed for several seconds and then the download speed will completely tank for several seconds. This occurs cyclicly. Running top shows a strong correlation between a fast download speed and high cpu utilization by the deluged process. It also shows a strong correlation between a slow download speed and very little cpu utilization by deluged (or other processes) as well as very high iowait (90+).

My interpretation is that deluged cycles between reasonably fast data downloading and then not being able to download more due to being blocked on io.

Unfortunately, I don't understand why this is occurring. I've spent a lot of time searching for an answer and have only come across a couple of similar situations with no useful solution.

Looking at this question:

Why is my SD card slow?

I tested the write speed by running:

dd if=/dev/zero of=test bs=8M count=25
25+0 records in
25+0 records out
209715200 bytes (210 MB) copied, 12.7349 s, 16.5 MB/s

I don't know if this way of testing is necessarily admissible. I've read that there can be a difference in write speeds between sequential writes and random writes. In the case of a torrent client, I read it would predominantly be making random writes (which makes sense). Thus, this could be a potential bottleneck. However, the "fast" download speeds I'm referring to are just between 2-3 MB/s (my internet is capped at 3-3.5 MB/s). So currently, the writes are supposedly even slower than that (which doesn't seem reasonable).

With that in mind, I'm hoping someone can help me identify exactly what is causing the iowait bottleneck and what I can do to fix it.

EDIT: This thread seems potentially relevant, but it's rather old now. I'm not sure if the problem discussed there has already been fixed (if there is a fix at all). But either way, the write speeds I seem to be getting are astoundingly slow, so I suspect this may be a different issue.



I had the same problem before switching to transmission. I would recommend going online and looking up how to tweak the settings and optimizing transmission for the raspberrypi.

See my question here: Deluge fluctuating download speeds

  • Interesting, what was the behavior after you switched to Transmission? After switching to rtorrent, I've observed far less iowait and much less dl speed fluctuation. It's not a perfect solution though, as the dl speed seems to stabilize at about 1.5 MB/s which is half of what the network is able to provide. For reference, I have no trouble reaching the network bound dl speed on my laptop. I'm curious what speeds you're seeing with Transmission? Furthermore, what sorts of tweaks did you find useful? – fvgs Jan 20 '17 at 12:09
  • Reading your question, it sounds as though limiting the number of connections and prioritizing connections that can offer higher bandwidth might be a good strategy. – fvgs Jan 20 '17 at 12:09
  • Transmission has worked smoothly for me, very easy to setup, and it fixed the fluctuating speeds in deluge. I think the 1.5MB/s limit that you're seeing in rtorrent is due to the hardware or lack thereof in the raspberry pi, especially since it uses a shared network & USB IO bus, which could definitely limit network speeds when running CPU intensive applications, such as a torrent client. – Carlo Revelli Jan 20 '17 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.