Guest TFR Posted March 15, 2016 Posted March 15, 2016 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?
Tido Posted March 15, 2016 Posted March 15, 2016 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?
tkaiser Posted March 15, 2016 Posted March 15, 2016 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).
vlad Posted March 15, 2016 Posted March 15, 2016 @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.
Guest TFR Posted March 15, 2016 Posted March 15, 2016 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
Guest TFR Posted March 15, 2016 Posted March 15, 2016 EDIT (might have to go through the trouble to create an account after all ): 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.
tkaiser Posted March 15, 2016 Posted March 15, 2016 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)
tkaiser Posted March 15, 2016 Posted March 15, 2016 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.
Guest TFR Posted March 15, 2016 Posted March 15, 2016 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)
tkaiser Posted March 15, 2016 Posted March 15, 2016 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!
Guest TFR Posted March 15, 2016 Posted March 15, 2016 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!
Tido Posted March 15, 2016 Posted March 15, 2016 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
Guest TFR Posted March 15, 2016 Posted March 15, 2016 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.
TFR Posted March 16, 2016 Posted March 16, 2016 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
tkaiser Posted March 16, 2016 Posted March 16, 2016 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.
TFR Posted March 16, 2016 Posted March 16, 2016 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
Tido Posted March 16, 2016 Posted March 16, 2016 Which image / kernel do you have installeduname -a Have you stopped transmission and set the chache to 12MB and restarted?
TFR Posted March 16, 2016 Posted March 16, 2016 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!
Tido Posted March 16, 2016 Posted March 16, 2016 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...
tkaiser Posted March 16, 2016 Posted March 16, 2016 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)
TFR Posted March 16, 2016 Posted March 16, 2016 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.
tkaiser Posted March 16, 2016 Posted March 16, 2016 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!)
TFR Posted March 16, 2016 Posted March 16, 2016 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
tkaiser Posted March 17, 2016 Posted March 17, 2016 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? 1
tkaiser Posted March 17, 2016 Posted March 17, 2016 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.
vlad Posted March 18, 2016 Posted March 18, 2016 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
tkaiser Posted March 18, 2016 Posted March 18, 2016 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 1
vlad Posted March 18, 2016 Posted March 18, 2016 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
tkaiser Posted March 18, 2016 Posted March 18, 2016 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 ############################################################################
Baos Posted March 18, 2016 Posted March 18, 2016 @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.
Recommended Posts