Forum

Hi guys,

Need some help troubleshooting a problem I've been having:

I have a USB drive connected to my RPi and share it over the network with samba.
I noticed that copying files from the disk connected to to Pi to my laptop or other device, over the network could take hours, specially if it was a HD movie, for example, so I installed a network speed monitor (Readerror's NetMeter, to be precise) on my laptop and stared to copy a large file from the Pi to the laptop.
Noticed that it started copying at a rate around 5MB/s for a few seconds and then dropped to 0 for a few second as well, and then back to 5MB/s and so on...
So basically it takes so long to copy a file because most of the time, it's actually not copying anything.

Ran the top command on the pi, and compared what was happening on both ends.
When it was copying at 5MB/s, the smbd process in the pi was consuming around 70% of the CPU.
When the transfer rate dropped to 0, the IO-wait percentage of the CPU in the Pi was over 90%.

So, i think it's safe to assume I have a bottleneck accessing the USB drive. Why can that be? How can I overcome this?

Would appreciate if someone can point me in the right direction.

Thanks!

---

Oh... Just remembered that the USB drive is connected to the Pi through a Powered USB Hub. And apparently the HUB is the problem on my setup.

Tried connecting the hard drive directly to the Pi and copy the file again and everything seemed to work just fine.

So, the question that remains is: is this bound to happen with any USB hub or do I have a faulty one?
If the problem is with mine, would you recommend any in particular? Is the PIHUB any good?

Thanks!

Well, guess a faulty USB Hub was in fact the problem. Tried with a different one I had laying around, even though it was not powered so I had to power my hard drive using a smartphone charger and a split cable, and everything worked fine. No huge IO-Wait any more...

Would still like to hear your opinions on the PIHub or other powered hubs, but I guess that may be a discussion for another thread.

Anyway, the problem is solved and so the post was a bit useless. Sorry about that, but only remembered that the problem could be from the USB hub after posting it. It may help someone facing a similar problem though.

Thanks!

@Deep6

regardless of USB/RPI design flaws migration to 3.13,14,15 kernels is making a difference (specially on the side of IO Wait times - kernel internal locks).