0
Guest TFR

Best budget device as torrent box?

Recommended Posts

Guest TFR

Hi guys,

 

After trying multiple things and not getting a satisfying result, I decided to just ask:

What is best device to use as a low power torrent downloader?

 

I tried with a raspberry pi 2, but kept getting huge fluctuations in speed, as soon as it had to write to usb (on an expensive high speed usb 3 stick).

 

I googled and googled, and came across the orange pi, which had a more powerfull soc, and didn't have the limitation of using a single usb hub that is shared for ethernet+storage. 

The boards (bought a PC and a one) finally arrived, but they disappoint. Using armbian, real world average speed seems to be even lower than the rpi2. I must admit I used a normal Sony USB3 stick, and not the expensive one yet. The transferspeeds of the stick are however quite a bit higher than the average speeds that I am getting.

 

So, is there anything that will work properly, without going x86 (power consumption is a big factor), and without spending silly money?

 

I read about the pogoplug, but they weren't sold here in Europe, and as such are very expensive to buy.

 

I don't think I am asking that much. I only get 2MB/s on my home connection, I would like to max that out. With the raspberry I got relatively close (1.4MB/s), with the OrangePi PC I'm sub 1MB/s.

A bit higher would be nice, I'm thinking of upgrading to a 100mbps connection, so getting between 5 and 10 MB/s would be nice, but seemingly not realistic?

Share this post


Link to post
Share on other sites

The boards (bought an OPC and a one).

With which Kernel did you run these devices while testing?

Did you install RPi-Monitor or how did you collect the data about storage speed?

 

Transmission-Daemon with Webinterface - this just out of curiosity?

Share this post


Link to post
Share on other sites

I must admit I used a normal Sony USB3 stick, and not the expensive one yet. The transferspeeds of the stick are however quite a bit higher than the average speeds that I am getting.

 

Interesting. Wouldn't this be a good starting point to blame your USB stick instead of the new board or the distro you chose? Have you already let f3 test your thumb drive?

 

This is Orange Pi PC USB transfer speed: http://linux-sunxi.org/USB/UAS (close to 40 MB/s with mainline kernel, you won't see any USB2.0 device in the world that is faster... and with 3.4.110 kernel you're using it's ~35MB/s)

 

This is Orange Pi PC network transfer speed: Yeah, only 95 Mbits/sec since it's just Fast Ethernet:

 

 

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.110-sun8i 

 

System load:   0.21            Up time:       3 min

Memory usage:  13 % of 1001Mb IP:            192.168.83.110

CPU temp:      28°C           

Usage of /:    33% of 7.3G   

 

[ 13 updates to install: apt-get upgrade ]

 

Last login: Mon Mar 14 12:50:41 2016 from macbookpro-tk.fritz.box

tk@orangepipc:~$ iperf -c 192.168.83.120

------------------------------------------------------------

Client connecting to 192.168.83.120, TCP port 5001

TCP window size: 21.0 KByte (default)

------------------------------------------------------------

[  3] local 192.168.83.110 port 48052 connected with 192.168.83.120 port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-10.0 sec   115 MBytes  96.5 Mbits/sec

tk@orangepipc:~$ iperf -s

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

[  4] local 192.168.83.110 port 5001 connected with 192.168.83.120 port 49118

[ ID] Interval       Transfer     Bandwidth

 

[  4]  0.0-10.1 sec   114 MBytes  94.1 Mbits/sec

 

 

 

Please try to start thinking about that you might have to blame something else for your slow speeds. The 2 devices you bought are perfectly useable with Armbian for the use case though I normally recommend using boards based on A20 (due to SATA which might not make any difference if it's about slow torrent stuff): http://linux-sunxi.org/Sunxi_devices_as_NAS

 

If you read carefully through this article you get an idea how to identify performance bottlenecks (you have to test storage/network individually and also have an eye on CPU utilisation and %iowait, so run 'sudo armbianmonitor -m' in another shell while performing iozone/iperf tests)

 

Next steps: 'sudo apt-get install iperf f3' and then the tests in question to identify the real bottleneck(s).

Share this post


Link to post
Share on other sites

@Guest_TFR_* the short answer is no save money and go for an x86 desktop and even though youll spend more money to begin with it will save you a looooot of time and give you more than decent performance, i will recommand you the AM1 platform from AMD its has a more than decent GPU, so it could easily download content and play it using kodi (which in my opinion is the best media center software ever) - itx motherboards for the AM1 socket are cheap so with lets say 100E you could have a pretty decent box (even less if you have some parts around)

 

the long answer 

i have a cubietruck (or i think i still have one - bad incident with a power supply last night - be aware when buying cheap stuff from china - save yourself the trouble and always buy power supply or other important stuff form reliable sources)

 

the cubietruck has at first great specs dual core soc, 2 gigs of ram, sata port, 1gig ethernet - unfortunately the specs are great only on paper (not talking about the soc or ram) but the performance of the sata port and the gigabit ethernet is at half at best. (but i could get continuous  write speeds arount 10MB/s  on a mechanical HDD @7200RPM) 

 

Software support (at least for this board) is great thanks to the great community here and thanks to Igor, i have been using his images for a long time, but as i said hardware is not up to the task.

 

So as suggested go for x86 if you value your time and money - at the moment the SBC world, in my opinion, is experimental others may have other options.

Share this post


Link to post
Share on other sites
Guest TFR

Hi,

 

Here's a benchmark of the used drive:

Starting benchmark.
Bechmarking H:(5C071053B5773BC184)
Started at 15/03/2016 13:52:18
Filename: H:\test.tmp
Starting large file benchmark. With 100MB file.
16384k:6 Write Speed:8,63MB/s
16384k:6 Write Speed:3,96MB/s
16384k:6 Write Speed:4,10MB/s
16384k:6 Average Write Speed:4,90MB/s
16384k:6 Read Speed:35,50MB/s
16384k:6 Read Speed:35,67MB/s
16384k:6 Read Speed:35,56MB/s
16384k:6 Average Read Speed:35,58MB/s
8192k:12 Write Speed:4,84MB/s
8192k:12 Write Speed:4,68MB/s
8192k:12 Write Speed:4,77MB/s
8192k:12 Average Write Speed:4,76MB/s
8192k:12 Read Speed:35,50MB/s
8192k:12 Read Speed:35,63MB/s
8192k:12 Read Speed:35,59MB/s
8192k:12 Average Read Speed:35,57MB/s
4096k:25 Write Speed:4,73MB/s
4096k:25 Write Speed:4,96MB/s
4096k:25 Write Speed:4,58MB/s
4096k:25 Average Write Speed:4,75MB/s
4096k:25 Read Speed:35,37MB/s
4096k:25 Read Speed:35,62MB/s
4096k:25 Read Speed:35,63MB/s
4096k:25 Average Read Speed:35,54MB/s
2048k:50 Write Speed:4,74MB/s
2048k:50 Write Speed:4,47MB/s
2048k:50 Write Speed:4,80MB/s
2048k:50 Average Write Speed:4,67MB/s
2048k:50 Read Speed:35,41MB/s
2048k:50 Read Speed:35,57MB/s
2048k:50 Read Speed:35,56MB/s
2048k:50 Average Read Speed:35,51MB/s
1024k:100 Write Speed:4,76MB/s
1024k:100 Write Speed:4,63MB/s
1024k:100 Write Speed:4,99MB/s
1024k:100 Average Write Speed:4,79MB/s
1024k:100 Read Speed:35,25MB/s
1024k:100 Read Speed:35,54MB/s
1024k:100 Read Speed:35,58MB/s
1024k:100 Average Read Speed:35,45MB/s
512k:200 Write Speed:4,44MB/s
512k:200 Write Speed:4,75MB/s
512k:200 Write Speed:4,69MB/s
512k:200 Average Write Speed:4,62MB/s
512k:200 Read Speed:35,33MB/s
512k:200 Read Speed:35,59MB/s
512k:200 Read Speed:35,52MB/s
512k:200 Average Read Speed:35,48MB/s
Deleting file.
Starting small file benchmark. With 10MB file.
256k:40 Write Speed:3,00MB/s
256k:40 Write Speed:3,76MB/s
256k:40 Write Speed:4,14MB/s
256k:40 Average Write Speed:3,57MB/s
256k:40 Read Speed:35,14MB/s
256k:40 Read Speed:35,19MB/s
256k:40 Read Speed:35,07MB/s
256k:40 Average Read Speed:35,13MB/s
128k:80 Write Speed:5,66MB/s
128k:80 Write Speed:4,05MB/s
128k:80 Write Speed:3,69MB/s
128k:80 Average Write Speed:4,32MB/s
128k:80 Read Speed:35,14MB/s
128k:80 Read Speed:34,89MB/s
128k:80 Read Speed:35,01MB/s
128k:80 Average Read Speed:35,01MB/s
64k:160 Write Speed:5,35MB/s
64k:160 Write Speed:4,76MB/s
64k:160 Write Speed:4,77MB/s
64k:160 Average Write Speed:4,94MB/s
64k:160 Read Speed:34,99MB/s
64k:160 Read Speed:34,89MB/s
64k:160 Read Speed:34,87MB/s
64k:160 Average Read Speed:34,92MB/s
32k:320 Write Speed:3,10MB/s
32k:320 Write Speed:3,07MB/s
32k:320 Write Speed:3,90MB/s
32k:320 Average Write Speed:3,31MB/s
32k:320 Read Speed:29,99MB/s
32k:320 Read Speed:30,01MB/s
32k:320 Read Speed:29,72MB/s
32k:320 Average Read Speed:29,91MB/s
Deleting file.
Starting tiny file benchmark. With 1MB file.
16k:320 Write Speed:0,91MB/s
16k:320 Write Speed:1,30MB/s
16k:320 Write Speed:1,59MB/s
16k:320 Average Write Speed:1,20MB/s
16k:320 Read Speed:17,69MB/s
16k:320 Read Speed:17,71MB/s
16k:320 Read Speed:17,76MB/s
16k:320 Average Read Speed:17,72MB/s
8k:640 Write Speed:0,90MB/s
8k:640 Write Speed:0,89MB/s
8k:640 Write Speed:0,90MB/s
8k:640 Average Write Speed:0,90MB/s
8k:640 Read Speed:11,54MB/s
8k:640 Read Speed:11,55MB/s
8k:640 Read Speed:11,36MB/s
8k:640 Average Read Speed:11,48MB/s
4k:1280 Write Speed:0,56MB/s
4k:1280 Write Speed:0,43MB/s
4k:1280 Write Speed:0,48MB/s
4k:1280 Average Write Speed:0,48MB/s
4k:1280 Read Speed:6,85MB/s
4k:1280 Read Speed:6,69MB/s
4k:1280 Read Speed:6,82MB/s
4k:1280 Average Read Speed:6,78MB/s
2k:2560 Write Speed:0,26MB/s
2k:2560 Write Speed:0,34MB/s
2k:2560 Write Speed:0,31MB/s
2k:2560 Average Write Speed:0,30MB/s
2k:2560 Read Speed:3,59MB/s
2k:2560 Read Speed:3,63MB/s
2k:2560 Read Speed:3,65MB/s
2k:2560 Average Read Speed:3,62MB/s
1k:5120 Write Speed:0,18MB/s
1k:5120 Write Speed:0,19MB/s
1k:5120 Write Speed:0,19MB/s
1k:5120 Average Write Speed:0,19MB/s
1k:5120 Read Speed:1,98MB/s
1k:5120 Read Speed:2,00MB/s
1k:5120 Read Speed:2,01MB/s
1k:5120 Average Read Speed:2,00MB/s
Deleting file.
Benchmark done.
Ended at 15/03/2016 14:03:45

I didn't change the settings of transmission, so the buffer is 4MB before it writes to flash. There shouldn't be an issue for my home connection speed, but I'll give it a shot with the faster stick (reason I didn't yet, is because it is in use on my raspberry).

 

I am not sure which kernel I used, but I can check when I'm at home. I downloaded the Armbian desktop image from here, probably ran sudo apt-get upgrade; sudo apt-get update and installed transmission.

I also tried with the server image from htpcguides, which was updated in March and uses the Armbian image as a base (link: http://www.htpcguides.com/orange-pi-pc-home-media-server-installer-image/)

 

Using htop to monitor: cpu and ram don't seem to be an issue at all.  

I noticed the same on the raspberry: as long as it downloads to the ram, there's no issue. One you start writing to usb, you run into problems.

 

As for the torrent benchmark: I used 3-5 of the most popular torrents, and let it run for some time. Total downloaded data/time=average speed. On the OrangePi, it was measured over 20 minutes or so, once the downloading started. Both with transmission and transmission daemon, you notice that the speeds burst a few seconds, and then drop to nearly a halt and burst again. Just like the raspberry, where you get high speeds until the cache is full and it has to start writing to the usb.

 

I am using the cheaper, non-sata boards as I am planning to download and upload to my (unlimited) amazon cloud storage, so I don't need to store much locally.

 

I'll do some more extensive testing tonight :)

Share this post


Link to post
Share on other sites
Guest TFR

EDIT (might have to go through the trouble to create an account after all :D):

A fullsized x86 uses a lot more power, which is the main reason I wanted to use a SBC. I wanted to try my setup with a MeegoPad (Chinese Intel Compute stick), but the one I could use got bricked, and I am waiting for the chip programmer to reflash the bios. This still doesn't use a lot of power, is nearly silent and doesn't cost that much (about 80 usd).

 

The issue with the MeegoPad, is that there is no good Linux support for it, so I'm not expecting satisfying results.

The uploading to Amazon part uses fuse, acd_cli and encfs. All that runs good under Linux, but not so much under Windows.

Share this post


Link to post
Share on other sites

but i could get continuous  write speeds arount 10MB/s  on a mechanical HDD @7200RPM

 

On a Cubietruck I was able to measure: write: 38 MB/s / read: 145 MB/s (and that was long ago back then when I had no clues what's special on these SBCs and before I met Armbian and contributed to). With any A20 device it's possible to get SATA speeds in the following range: 40-45 MB/s write and +180MB/s read (that's the SoC's limitation or drivers or whatever). If you get less then you've a good chance to increase the speeds by starting to investigate what's going wrong: http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks

 

And regarding a 'low power torrent downloader" that was asked for. An Orange Pi PC can do this job easily running Armbian 24/7 at less than 2.5W (if a large SD card is used or an energy efficient thumb drive). This might be less than the 'power off' consumption of the PSU used with a x86 machine. And BTW: OpenELEC runs also on an Orange Pi PC (suspend to RAM consumption less than 0.4W, HW accelerated video decoding of more formats than RPi is able to do)

Share this post


Link to post
Share on other sites

I noticed the same on the raspberry: as long as it downloads to the ram, there's no issue. One you start writing to usb, you run into problems.

 

That might be true for RPi but not for Orange Pi. I already did real-world tests with 3 USB disks and exceeded 100MB/s easily (mainline kernel, only one CPU core active running at 1008 MHz -- you use Armbian with 4 CPU cores active running at 1296 MHz when needed).

 

Please stay calm and try to identify the real bottleneck. It's neither the OPi PC nor Armbian :)

 

I don't know the tiny benchmark above but write speeds with 'small filesizes' are laughable. You should also keep in mind that sequential transfer speeds might be something completely different than random I/O. No idea how these torrent downloaders act but in case you're using flash media that's slow when it's about IOPS and software that tries to sync after each written block then your thumbdrive will become a huge bottleneck ('sudo armbianmonitor -m' will show you just that).

 

Everything that's needed to nail the problem down is already written above. And BTW: That's why I test new system all the times with peripherals that are known to work ok before. To be able to easily identify what has changed in a setup and where to search first when performance sucks.

Share this post


Link to post
Share on other sites
Guest TFR

 And BTW: OpenELEC runs also on an Orange Pi PC (suspend to RAM consumption less than 0.4W, HW accelerated video decoding of more formats than RPi is able to do)

This is something that I will probably use. I tried an x265 file yesterday and it played without problems.

Only disadvantage to the pi, is the lack of hdmi CEC, which is convenient.

 

If possible, I'd like to do it all on one device (torrent downloader/amazon upload/media player). This works reasonably on the raspberry, but you are limited with your downloadspeed, and playing+downloading at the same time doesn't work well.

 

I'm still debating between a Kodi setup or Plex. Plex seems to work smoother, but you'll always have to use 2 devices.

 

 

@tkaiser: That gives me hope! I'll do some more testing tonight. As I understand it, transmission caches 4MB in the ram and writes it to the disk. I'll also try some different cache sizes if the problem wouldn't be solved by using the faster usb drive. I could also give it a go with an SSD drive and a USB enclosure, but I'm not sure if the power supply will be sufficient for that (5v 2A, charger from an iomega iphone dock)

Share this post


Link to post
Share on other sites

This is something that I will probably use. I tried an x265 file yesterday and it played without problems.

Only disadvantage to the pi, is the lack of hdmi CEC, which is convenient.

 

Jernej already has patches for CEC in his OpenELEC repo. But regarding this you should better watch the thread in the otherwise not so useful Orange Pi forums. But since you already have an RPi why not using both devices? 

 

An Orange Pi PC combined with one or a few USB disks can perfectly serve as both NAS and media center (and this torrent stuff is laughable, should just work)

 

BTW: I'm just using an old Banana Pi without SD card or local storage that was booted through USB (FEL boot) and has its rootfs on NFS and watch a h.264 encoded 1080p video with sound (to my surprise the LCD I use has internal speakers -- adjusted to the maximum which caused almost coronary ;) ). Linux-sunxi community and Armbian devs did a really great job! Thx to all!

Share this post


Link to post
Share on other sites
Guest TFR

Jernej already has patches for CEC in his OpenELEC repo. But regarding this you should better watch the thread in the otherwise not so useful Orange Pi forums. But since you already have an RPi why not using both devices? 

 

An Orange Pi PC combined with one or a few USB disks can perfectly serve as both NAS and media center (and this torrent stuff is laughable, should just work)

 

BTW: I'm just using an old Banana Pi without SD card or local storage that was booted through USB (FEL boot) and has its rootfs on NFS and watch a h.264 encoded 1080p video with sound (to my surprise the LCD I use has internal speakers -- adjusted to the maximum which caused almost coronary ;) ). Linux-sunxi community and Armbian devs did a really great job! Thx to all!

The Raspberry is from my work, we use them there for digital signage. An all in one solution would be nice though, why use 2 devices if you can do it on 1! :) Looking forward to test this further, hopefully it'll get solved.

Thank you for all the help/advice by the way!

Share this post


Link to post
Share on other sites

hmm, I have the Banana R1 = A20 SoC with SATA and relatively fast Network.

 

If you want to spend less you get the same with Banana Pi.

I ordered on eBay a  HDD 750GB  (which was never used, Laptop upgrade to SSD) for this I spent about € 30.-

 

The Banana comes with a lot of RAM so I have set Transmission to 12 MB

Share this post


Link to post
Share on other sites
Guest TFR

It seemed better with the faster usb stick, at least for a while. 
Running transmission-daemon, I noticed that after a few minutes, there's always a single core on 100%, even though cpu usage is trivial according to htop.

 

 

Welcome to ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.110-sun8i

System load:   4.28             Up time:       37 min
Memory usage:  14 % of 1001Mb   IP:            192.168.1.8
CPU temp:      48°C
Usage of /:    22% of 7.4G      storage/:      12% of 58G

Last login: Tue Mar 15 23:03:47 2016
orangepi@orangepipc:~$ sudo armbianmonitor -m
[sudo] password for orangepi:
Stop monitoring using [ctrl]-[c]
 
Time        CPU    load %cpu %sys %usr %nice %io %irq
23:40:35: 1296MHz  4.59  26%   6%   2%   0%  16%   0%
23:40:40: 1296MHz  4.63  26%   6%   2%   0%  16%   0%
23:40:45: 1296MHz  4.74  26%   6%   2%   0%  16%   0%
23:40:50: 1296MHz  4.76  27%   6%   2%   0%  16%   0%
23:40:55: 1296MHz  4.86  27%   7%   2%   0%  16%   0%
23:41:00: 1296MHz  4.87  27%   7%   2%   0%  16%   0%
23:41:05: 1296MHz  4.96  27%   7%   2%   0%  16%   0%
23:41:10: 1296MHz  5.04  27%   7%   2%   0%  16%   0%
23:41:15: 1296MHz  5.04  27%   7%   2%   0%  16%   0%
23:41:20: 1296MHz  5.04  27%   7%   2%   0%  16%   0%
23:41:25: 1296MHz  5.03  27%   7%   2%   0%  16%   0%
23:41:30: 1296MHz  5.03  27%   7%   2%   0%  16%   0%
23:41:35: 1296MHz  4.87  27%   7%   2%   0%  16%   0%
23:41:40: 1296MHz  4.64  27%   7%   2%   0%  16%   0%
23:41:46: 1296MHz  4.59  27%   7%   2%   0%  16%   0%
23:41:51: 1296MHz  4.62  27%   7%   2%   0%  16%   0%
23:41:56: 1296MHz  4.65  27%   7%   2%   0%  16%   0%
23:42:01: 1296MHz  4.68  27%   7%   2%   0%  16%   0%
23:42:06: 1296MHz  4.62  27%   7%   2%   0%  16%   0%
23:42:11: 1296MHz  4.65  27%   7%   2%   0%  16%   0%
23:42:16: 1296MHz  4.68  27%   7%   2%   0%  16%   0%
23:42:21: 1296MHz  4.71  27%   7%   2%   0%  16%   0%
23:42:26: 1296MHz  4.73  27%   7%   2%   0%  16%   0%
23:42:31: 1296MHz  4.75  27%   7%   2%   0%  16%   0%
23:42:36: 1296MHz  4.69  27%   7%   2%   0%  16%   0%
23:42:41: 1296MHz  4.64  27%   7%   2%   0%  16%   0%
23:42:46: 1296MHz  4.67  27%   7%   2%   0%  16%   0%
23:42:51: 1296MHz  4.53  27%   7%   2%   0%  16%   0%
23:42:56: 1296MHz  4.49  27%   7%   2%   0%  16%   0%
23:43:01: 1296MHz  4.45  27%   8%   2%   0%  16%   0%
23:43:06: 1296MHz  4.33  28%   8%   2%   0%  16%   0%
23:43:11: 1296MHz  4.23  28%   8%   2%   0%  16%   0%
23:43:17: 1296MHz  4.21  28%   8%   2%   0%  16%   0%
23:43:22: 1296MHz  4.27  28%   8%   2%   0%  16%   0%
23:43:27: 1296MHz  4.41  28%   8%   2%   0%  16%   0%
23:43:32: 1296MHz  4.46  28%   8%   2%   0%  16%   0%
23:43:37: 1296MHz  4.42  28%   8%   2%   0%  16%   0%
23:43:42: 1296MHz  4.39  28%   8%   2%   0%  16%   0%
23:43:47: 1296MHz  4.44  28%   8%   2%   0%  16%   0%
 
  1  [|||||||||||||||||                                                              18.3%]     Tasks: 34, 44 thr; 2 running
  2  [|                                                                               0.5%]     Load average: 4.12 4.28 3.61
  3  [|||                                                                             2.6%]     Uptime: 00:42:03
  4  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||153/1001MB]
  Swp[                                                                             0/127MB]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 7352 orangepi   20   0  5064  1988  1048 R  1.0  0.2  0:00.47 htop
  629 plex       35  15  184M 24008   912 S  0.5  2.3  0:39.82 Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plug-ins-7be11e1/Framework.bundle/Contents/Resources/Vers
 5398 root       20   0  4280  1480   996 S  0.0  0.1  0:00.83 /bin/bash /usr/local/bin/armbianmonitor -m
  757 plex       20   0  220M 13964  1688 S  0.0  1.4  0:01.52 ./Plex Media Server
 5109 debian-tr  20   0 44084 19100  2280 S 42.4  1.9  2:34.00 /usr/bin/transmission-daemon -f --log-error -g /etc/transmission-daemon
 5110 debian-tr  20   0 44084 19100  2280 R 42.4  1.9  2:33.65 /usr/bin/transmission-daemon -f --log-error -g /etc/transmission-daemon
  950 plex       20   0  184M 24008   912 S  0.0  2.3  0:04.63 Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plug-ins-7be11e1/Framework.bundle/Contents/Resources/Vers
  749 plex       20   0  184M 24008   912 S  0.0  2.3  0:05.49 Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plug-ins-7be11e1/Framework.bundle/Contents/Resources/Vers
  762 plex       20   0  190M  5832  1380 S  0.0  0.6  0:03.08 /usr/lib/plexmediaserver/Plex DLNA Server
  416 root       20   0  7184  3520   444 S  0.0  0.3  0:02.92 /usr/sbin/haveged --Foreground --verbose=1 --write=1024
  751 plex       35  15  184M 24008   912 S  0.0  2.3  0:02.14 Plex Plug-in [com.plexapp.system] /usr/lib/plexmediaserver/Resources/Plug-ins-7be11e1/Framework.bundle/Contents/Resources/Vers
    1 root       20   0  4428  2260  1300 S  0.0  0.2  0:03.58 /sbin/init sunxi_no_mali_mem_reserve
  553 plex       20   0  220M 13964  1688 S  0.0  1.4  0:06.12 ./Plex Media Server
  754 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.20 ./Plex Media Server
  516 messagebu  20   0  4576  1368  1036 S  0.0  0.1  0:00.89 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
 5729 orangepi   20   0 10772  1648   968 S  0.0  0.2  0:00.04 sshd: orangepi@pts/0
  112 root       20   0  9684  1512  1280 S  0.0  0.1  0:00.68 /lib/systemd/systemd-journald
  113 root       20   0 10456  1224   644 S  0.0  0.1  0:00.25 /lib/systemd/systemd-udevd
  384 root       20   0  7768  4800   104 S  0.0  0.5  0:00.00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
  418 root       20   0  4420   948   752 S  0.0  0.1  0:00.02 /usr/sbin/cron -f
  419 root       20   0  6528  1884  1428 S  0.0  0.2  0:00.05 /usr/sbin/sshd -D
  421 root       20   0  3088  1192   936 S  0.0  0.1  0:00.38 /lib/systemd/systemd-logind
  512 ntp        20   0  4812  1552  1140 S  0.0  0.2  0:00.34 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:110
  518 root       20   0  3112   396   236 S  0.0  0.0  0:00.00 /usr/sbin/lircd --driver=devinput --device=/dev/input/
  522 root       20   0 31392  1672   856 S  0.0  0.2  0:00.03 /usr/sbin/rsyslogd -n
  523 root       20   0 31392  1672   856 S  0.0  0.2  0:00.00 /usr/sbin/rsyslogd -n
  524 root       20   0 31392  1672   856 S  0.0  0.2  0:00.07 /usr/sbin/rsyslogd -n
  520 root       20   0 31392  1672   856 S  0.0  0.2  0:00.14 /usr/sbin/rsyslogd -n
  531 root       20   0  3368   680   564 S  0.0  0.1  0:00.01 /sbin/agetty -L 115200 ttyS0 xterm
  540 root       20   0  4904  1436   980 S  0.0  0.1  0:00.18 /bin/login --
  541 plex       20   0  4004  1340  1032 S  0.0  0.1  0:00.05 /lib/systemd/systemd --user
  543 plex       20   0  5676  1028    20 S  0.0  0.1  0:00.00 (sd-pam)
  551 plex       20   0  1432   240   192 S  0.0  0.0  0:00.00 /bin/sh /usr/sbin/start_pms
  613 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.07 ./Plex Media Server
  616 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.04 ./Plex Media Server
  621 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.01 ./Plex Media Server
  622 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.01 ./Plex Media Server
  626 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.00 ./Plex Media Server
  627 plex       20   0  220M 13964  1688 S  0.0  1.4  0:00.27 ./Plex Media Server
F1Help  F2Setup F3SearchF4FilterF5Tree  F6SortByF7Nice -F8Nice +F9Kill  F10Quit

 

 

Plex was only installed, but it isn't doing anything. 

 

Average speed seems to be roughly twice of what I got with the other USB. I downloaded roughly 1GB in 20 minutes now.

Share this post


Link to post
Share on other sites

Made an account :)

Did some benchmarking!

wget --output-document=/dev/null http://speedtest.wdc01.softlayer.com/downloads/test500.zip

Averaged 2.23 MB/s, pretty much the max of my home connection. Will try at work tomorrow (got 350mbps down on speedtest.net there)

 

dd:

orangepi@orangepipc:~$ time sh -c "dd oflag=direct if=/dev/zero of=/media/usb/tmp bs=4K count=10000 && sync"
10000+0 records in
10000+0 records out
40960000 bytes (41 MB) copied, 26.2403 s, 1.6 MB/s

real    0m28.506s
user    0m0.000s
sys     0m0.950s
orangepi@orangepipc:~$ time sh -c "dd oflag=direct if=/dev/zero of=/media/usb/tmp bs=1M count=100 && sync"
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 5.26363 s, 19.9 MB/s

real    0m5.337s
user    0m0.000s
sys     0m0.170s

I did longer runs first, but my pc crashed when I was posting the result. Speeds were the same.

 

Bonnie++:


Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
orangepipc       2G   112  98 18230  12 12774   8   540  99 49408  12  96.2   3
Latency             90441us    1195ms    1196ms   17282us   10268us    1188ms
Version  1.97       ------Sequential Create------ --------Random Create--------
orangepipc          -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16  2664  18 +++++ +++ 11275  59  9487  63 +++++ +++  7905  42
Latency               755us    1947us    2037us     822us     135us    1733us
1.97,1.97,orangepipc,1,1458080683,2G,,112,98,18230,12,12774,8,540,99,49408,12,96.2,3,16,,,,,2664,18,+++++,+++,11275,59,9487,63,+++++,+++,7905,42,90441us,1195ms,1196ms,17282us,10268us,1188ms,755us,1947us,2037us,822us,135us,1733us

Share this post


Link to post
Share on other sites

Well, there's a reason you should not use dd, wget or bonnie++: you're testing most likely the wrong things. While that's quite normal with benchmarking it's still a bit stupid:

 

Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.

 

Good example regarding bonnie++: http://www.brendangregg.com/ActiveBenchmarking/bonnie++.html(you think you test disks but in reality you test the C code of benchmark programs and buffer size defaults of operating systems)

 

If you want to do it right, use iperf/netperf between local machines to see whether you have a network bottleneck (should be 95 Mbits/sec), then check the disk access pattern of the application in question. How large are the chunks transmission writes. Then test random I/O with iozone (preinstalled in Armbian for a reason!) with exactly this block size (-O option). Get flashbench when you still use a thumbdrive and think about using ext4 there and adjusting stripe/stride sizes. Adjust the block size of the application to the most performant block size of your storage implementation. Do active benchmarking.

 

You see 16% iowait constantly which is a hint that your storage is some sort of a limitation. And you might run into the 100% kswap issue (not able to see that due to wrong sorting order in htop). Please compare with: https://github.com/igorpecovnik/lib/issues/219

 

BTW: I would adjust maximum cpufreq to 816 or even lower, for your use case now it's moronic to let the SoC clock at 1296 all the time (consumption is then higher due to higher VDD_CPUX voltage). I would suspect you won't see performance drops even when downclocked to 600 MHz. But first rule out the bottlenecks in an 'active benchmarking' approach and then optimise consumption further.

Share this post


Link to post
Share on other sites
Wget at work got 7,03 MB/s from the same site. Pretty sure network is not the issue :)

The usb-drive is formatted in ext4.

I am not sure how to check the disk access pattern of transmission? 

How should htop be sorted to show the relevant information?

 

I have a Kingston DataTraveler Workspace (licensed WinToGo stick, 150 euro or something like that for 64GB). Waiting for some more instructions, I'll give that a go. At least I'll be sure it's not the stick then.

 

I also tried setting vm.swappiness=0 and vm.min_free_kbytes=0 in /ect/sysctl.conf (someone mentioned it fixed the kswapped issue for him), rebooted and tried again, but the problem was the same. 

 

I am not that familiar with Linux and all the command line tools, as you might have noticed :)

Share this post


Link to post
Share on other sites

Which image / kernel do you have installed
uname -a
 
Have you stopped transmission and set the chache to 12MB and restarted?

Share this post


Link to post
Share on other sites

Which image / kernel do you have installed

uname -a

 

Have you stopped transmission and set the chache to 12MB and restarted?

Linux orangepipc 3.4.110-sun8i #18 SMP PREEMPT Tue Mar 8 20:03:32 CET 2016 armv7l GNU/Linux

I stopped transmission and set the cache to 64MB (plenty of ram,250 only 100-150 MB was used) and then started again. The writing to usb is the problem.

If I set the cache to 800MB, it goes fast until the ram is full and then hangs (average speed about 4MB/s or so). 1 core is on 100%, one on 46, and 2 on 10-15%.

It's the whole device that hangs. Starting a new ssh session hangs, logging on on the local console hangs, htop doesn't do anything anymore. It's freezed for 5 minutes now or so.

Pretty much the same problem as on the raspberry. I'm gonna try with an SSD in a docking station now :)

 

EDIT: It does seem to be the USB drive. With the SSD in a dock, I get nearly 5MB/s measured over 10 minutes. If someone could help me figure out why there's such a big difference, so I know what to check for when buying a USB drive, that would be great!

Share this post


Link to post
Share on other sites

I just googled, may be this helps you.

 

scroll down to this answer:

http://askubuntu.com/questions/122113/copy-to-usb-memory-stick-really-slow

 

Found the fix all i did was unmount, remove drive, and run sudo modprobe ehci_hcd in the Terminal. Insert drive and agian sudo modprobe ehci_hcd when I put the drive in and wow 20/mbs thought i would share. Hope I dont have to do it every time... but it's not to hard...

Share this post


Link to post
Share on other sites

I just googled, may be this helps you.

 

Yeah, why analysing when you can google and recommend nonsense? BTW: lsmod exists so why trying out to load a module that's already loaded?!

 

His problem is crappy hardware being way too slow. The steps to identify bottlenecks have been outlined multiple times (the Brendan Gregg stuff is especially interesting to get an idea what happens at low levels). If you lack the skills or times to do an in-depth analysis then buying stuff that is known to work is also a great idea.

 

He needs an USB thumb drive with low latency and high IOPS. Or a better SD card. Let's have a look at these so called 'benchmarks' here, especially the so called 'SQLite bench': http://openbenchmarking.org/result/1603051-GA-ODROIDPI362

 

It's called a database test comparing two different boards but the tester is benchmarking random I/O of two different SD cards in reality (and doesn't take notice as usual, the whole openbenchmarking.org site is a cemetery of meaningsless numbers :) )

 

The used card is this one so choosing one with higher capacity should already solve the problem. On Orange Pis sequential transfer speeds won't exceed ~22/23 MB/s but that's not important since these cards show superiour random I/O performance (can not recommend any USB thumb drive since I don't like them)

Share this post


Link to post
Share on other sites

I tried the SSD on a raspberry pi (2) too, and it seems that it was also the USB drive that was bottlenecking everything. I also averaged 4.5MB/s on the raspberry.

I am having a real hard time comprehending why the USB stick is such a bottleneck. 

I tried writing a 15.5GB file (8gb ram in the system) to it in Windows (formatted as NTFS), which took 9min 29s. Or nearly 30 MB/s. The stick was directly unplugged after the copy was done, 

To verify the copy was indeed successful, I calculated a hash from the source file and the file on the stick.

 

So why, even with a big cache, is the performance so bad with transmission? 15 seconds to download 60MB, 2-3 seconds to write it to the stick. That is if it's sequential. Must be missing something :/

It's a Kingston DT Rubber 64GB by the way, first generation.

Share this post


Link to post
Share on other sites

I am having a real hard time comprehending why the USB stick is such a bottleneck. 

 

Since you do what nearly everyone does:

 

Casual benchmarking: you benchmark A, but actually measure B, and conclude you've measured C.

 

Your application does random writes in small chunks and you try to test/understand the behaviour by testing something completely different: writing large sequential (non random!) chunks of data. That can't work.

 

And of course you can improve the performance on any RPi with the same methods. There it even helps more since the one USB2.0 connection is another important bottleneck.

 

BTW: I stumbled accross this comparison a few minutes ago by accident: http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card(forget about the sequential stuff, the last two table rows are what matters for your application!).

 

If you would've followed the advise to use 'iozone' to test small random access patterns you could already read the explanation in form of numbers. I think we don't ship with iozone so you'll have to do an 'apt-get install iozone3' before (and do you a favour and add f3 also to the list since an alarming number of flash based media is crap/faulty/fraud -- checking every new thumb drive or SD/TF card at least once with f3write/f3read can save so much trouble!)

Share this post


Link to post
Share on other sites

 

Your application does random writes in small chunks and you try to test/understand the behaviour by testing something completely different: writing large sequential (non random!) chunks of data. That can't work.

Is it? 

 

 

  • cache-size-mb: Size (default = 4), in megabytes, to allocate for Transmission's memory cache. The cache is used to help batch disk IO together, so increasing the cache size can be used to reduce the number of disk reads and writes. Default is 2 if configured with --enable-lightweight.

     

Or does this not matter and just means it collects x MB of random writes and starts writing them at that point?

 

I tried rTorrent, and on first sight, it seemed to perform better. I'll install a webgui tonight so it's easier to keep track of it.

 

I have read up a bit about your active benchmarking, but it seemed relatively hard to set up and interpret the output. It was easier to just try with an SSD :)

 

Share this post


Link to post
Share on other sites

Or does this not matter and just means it collects x MB of random writes and starts writing them at that point?

 

I've never used transmission but if you're still talking about torrent stuff then please start to think about what's that all about: collecting small pieces of large files from others and then starting to insert these chunks into large files somewhere on disk. If this is not the definition of 'random I/O' I don't know what should it describe better.

 

Since you're not interested in active benchmarking it's not possible to help you. But I hope you understand that your problems are neither related to the board you use nor the OS distro?

Share this post


Link to post
Share on other sites

BTW: I just wanted to recommend using iotop (might require an 'apt-get install iotop' before) just to realize that we ship with a kernel lacking the essential features to be able to monitor this I/O stuff. So here you go: http://kaiser-edv.de/tmp/4U4tkD/Armbian_5.06-kernel-rc1.tar.gz

 

Simply untar it, run 'dpkg -i *5.06_armhf.deb', reboot and let iotop monitor what's happening. Also interesting: Installing the sysstat package and then running 'iostat 5' in a terminal.

Share this post


Link to post
Share on other sites

On a Cubietruck I was able to measure: write: 38 MB/s / read: 145 MB/s (and that was long ago back then when I had no clues what's special on these SBCs and before I met Armbian and contributed to). With any A20 device it's possible to get SATA speeds in the following range: 40-45 MB/s write and +180MB/s read (that's the SoC's limitation or drivers or whatever). If you get less then you've a good chance to increase the speeds by starting to investigate what's going wrong: http://linux-sunxi.org/Sunxi_devices_as_NAS#Benchmarking_.2F_Identifying_bottlenecks

 

i did the speed test long time ago (i have redone them on armbian too) and i get close speeds to what you got, but so far i haven't been able to use any other program beside dd to write that fast and i am mainly talking about transmission/deluge, i haven't tried rtorrent yet maybe i could get better speeds, so that is why i wrote only ~10MB/s.

 

i have even tried the suggestions from here http://linux-sunxi.org/SATA, the IO scheduler, IRQ  with little to no difference in write speed - i will have to try the suggestions for CPU also to see if something changes 

 

i agree that an x86 will consume more, but thinking about the boost in performance and that it just works no fussing with IO schedulers or IRQ or custom kernels i think it is to be considered if the goal is to have a nas/media center device

Share this post


Link to post
Share on other sites

i am mainly talking about transmission/deluge, i haven't tried rtorrent yet maybe i could get better speeds, so that is why i wrote only ~10MB/s.

 

But that's a totally different story since the reported 'transfer speeds' of these torrent thingies are influenced by many factors and here it's not about sequential write speeds at all (I still believe we're talking about random I/O mostly). And all this tweaking (IO scheduler, IRQ settings) isn't necessary if you're running already Armbian since we ship with sane defaults.

 

And while I agree that an x86 box as media center might be a good/better choice I still doubt that this applies to a 24/7 'low power torrent downloader' (that's how the thread starter calls it). Combining an Orange Pi One with Armbian, a 64 GB TF card that shows superiour random I/O performance and adjusting maximum CPU clockspeed to 648 MHz you get something for less than 35 bucks that consumes between 1.5W and 2.5W under full load and does exactly what he wants.

 

BTW: "Full load" includes playing a HEVC 1080p movie since to my surprise consumption does only increase a little but if one wants to use this video stuff the Orange Pi PC is clearly the better choice due to more RAM.

 

And ok, it's not exactly 35 bucks but a bit more since responsible users contribute also by considering a Paypal donation to the project ;)

Share this post


Link to post
Share on other sites

And all this tweaking (IO scheduler, IRQ settings) isn't necessary if you're running already Armbian since we ship with sane defaults.

i am not sure to what version you are referring but the teaks for SATA are no present (the deadline IO scheduler or moving the IRQ fro sata to the second core) in the latest version of armbian with vanilla kernel

 

what does low power even mean ? how much performance are you willing to sacrifice to have a low power device ? sure if you mean under 10W yes the the orange pi or any other decent SBC is the way to go but there are plenty of low power x86 which for the power they use offer great performance. 

 

take this for example http://www.htpcbeginner.com/htpc-nas-combo-build-2016/(i have no affiliation with that site) - sure its not exactly cheap (but i don't think you need an ssd or 8gig of ram so price will go down) but try putting a 4TB in an SBC, any SBC for that matter, add 2-3 clients to it and see how it performs compared to the build mentioned above 

 

as I said in my first reply it really depends what exactly is low power, how much money you want to invest and  how much time you want to invest in it :)

Share this post


Link to post
Share on other sites

I still think we're talking about two completely different use cases (I'm talking at least about that 24/7 torrent thing) but anyway. If IRQ distribution and setting the I/O scheduler isn't working for you then something's wrong since this should happen at startup (/etc/init.d/armhwinfo).

 

BTW: I implemented disk checking in armbianmonitor in the meantime: http://forum.armbian.com/index.php/topic/847-solved-after-reboot-installations-is-gone/?view=getlastpost

 

You can simply exchange the contents of /usr/local/bin/armbianmonitor with the version from the link above and then it looks like:

 

tk@orangepipc:~$ armbianmonitor 

Usage: armbianmonitor [-h] [-b] [-c $path] [-d] [-m] [-r] [-u]

 

############################################################################

 

 Use armbianmonitor for the following tasks:

 

 armbianmonitor -b switches between verbose and normal boot

 armbianmonitor -c /path/to/test performs disk health/performance tests

 armbianmonitor -d tries to upload debug disk info to improve armbianmonitor

 armbianmonitor -m provides simple CLI monitoring

 armbianmonitor -r tries to install RPi-Monitor

 armbianmonitor -u tries to upload armhwinfo.log for support purposes

 

############################################################################

Share this post


Link to post
Share on other sites

@Guest_TFR_* the short answer is no save money and go for an x86 desktop and even though youll spend more money to begin with it will save you a looooot of time and give you more than decent performance, i will recommand you the AM1 platform from AMD its has a more than decent GPU, so it could easily download content and play it using kodi (which in my opinion is the best media center software ever) - itx motherboards for the AM1 socket are cheap so with lets say 100E you could have a pretty decent box (even less if you have some parts around)

 

the long answer 

i have a cubietruck (or i think i still have one - bad incident with a power supply last night - be aware when buying cheap stuff from china - save yourself the trouble and always buy power supply or other important stuff form reliable sources)

 

the cubietruck has at first great specs dual core soc, 2 gigs of ram, sata port, 1gig ethernet - unfortunately the specs are great only on paper (not talking about the soc or ram) but the performance of the sata port and the gigabit ethernet is at half at best. (but i could get continuous  write speeds arount 10MB/s  on a mechanical HDD @7200RPM) 

 

Software support (at least for this board) is great thanks to the great community here and thanks to Igor, i have been using his images for a long time, but as i said hardware is not up to the task.

 

So as suggested go for x86 if you value your time and money - at the moment the SBC world, in my opinion, is experimental others may have other options.

I am getting significantly better speeds on cubietruck.  using a samsung I found inside a seagate backup plus 2t drive.  It's a 5400rpm laptop drive.  Using vsftpd on the armbian vs nautilus ftp(no ssl) on my home computer I'm getting write 30MB/s(upload).  read 70MB/s(download).  Armbian out of the box without any special tweaking.  I had some trouble with the 3.5 inch harddrive addon package, this is without. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
0