2

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.

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=5057&sid=ee346e3e7cea48d2858a143bcf086362

2 Answers 2

1

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

3
  • 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, 2017 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, 2017 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. Jan 20, 2017 at 19:07
1

So, you suspect a high IO wait.

First, make sure that this is the case. Instead of top, try vmstat 5 and let it run. You might even try a shorter interval.

Of course, this will merely confirm what your top says for the waitio, but it also shows some additional information. For example: how is your swap doing? If swap in or swap out is high, this uses your disk too. It is added to your regular disk usage. The block in/block out columns also give information about how heavy IO is being done.

In generally, if you go hunting for performance issues, you should install

apt-get install sysstat
apt-get install iotop

iostat -v will give you a better insight on your disk usage. iotop will give you the top IO users.

The theoretical maximum for an SD card is around 20 MB/s, so your 16.5 is a good number.

If you have a lot of swapping, you could consider adding a USB disk and let the data go to another disk then the swapping. Note that the USB bus will be limited as well in performance, and that the network adapter is on the USB bus ass well.

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.