10 napja vettem egy Banana Pi-t NAS céljából, viszont azóta sem sikerül úgy beállítanom, hogy hálózaton keresztül a rákötött HDD-ről elfogadható sebességgel tudjam olvasni az adatokat róla. Jellemzően a sebesség szélsőségesen ugrál, átlag 3-8MBps-ra sikerül kihajtani upload irányba. Mivel nem linux az elsődleges rendszerem, ezért simán előfordulhat, hogy én hibázok valamit, vagy hanyagul teszteltem, minden esetre kifogytam az ötletekből. Hivatalos fórumokon, guglival nem jutottam előrébb. Szeretném kérni a tisztelt közösség segítségét/véleményét, jól gyanítom-e, hogy hardver hiba?(előre is bocsánat, ha kicsit hosszú a post, de részletesen szeretném mutatni a problémát)
LAN: 10.5.1.0/24, topológia
csupe1 --- switch --- router ---> internet
pi ------------|
csupe-ubuntu---|
(minden eszköz gigabites, közöttük jó minőségű CAT6 kábelek)
csupe1: 10.5.1.102 (Win7 x64)
csupe-ubuntu: 10.5.1.115 (VMware kliens csupe1 hoston, Ubuntu 14.04 LTS)
pi: 10.5.1.10
router: 10.5.1.1 (TL-WR1043ND, OpenWRT Bleeding Edge, r35342)
A Bananapi táplálása egy Sunny 1460-1105 2100mA adapterrel történik. A tesztekhez két különféle külső táplálású dokkolót is próbáltam SATA és USB csatolóval (két külön USB kábellel). A dokkoló+HDD párosítás csupe1 hoston hibamentes működést mutat. A SATA csatolás SATA-eSATA kábellel történt. 3 féle CAT6, valamint egy CAT5e kábellel teszteltem a hálózati csatlakozást, switchre kötve és annak kiiktatásával is. A dokkolóba kétféle HDD-t próbáltam, egy SATA1-es régi Seagate Barracuda 7200.7, valamint egy új WD Red WD20EFRX-szel (fej parkolás gyárilag 300-on).
Szoftver oldalról a legújabb Raspbian, Bananian, Lubuntu képfájlokat próbáltam http://bananapi.com/ oldalról beszerezve, valamint egy BanaNAS-t is néztem (http://bananas.gda.pl/).
Gyakorlatilag minden teszt ugyanazt a végeredményt hozta, ezért csak a legutolsót mutatom: WD Red, új dokkoló, új kábelekkel, CAT6-on, switchre kötött Pi-vel.
Friss Bananian telepítés utáni előkészületek
apt-get update && apt-get upgrade
apt-get install netcat iperf ethtool hdparm sysstat pv
mkdir /media/red2tb
mount -t ext4 /dev/sda1 /media/red2tb
Háttér adatok
root@bananapi / # uname -a
Linux bananapi 3.4.104+ #1 SMP PREEMPT Thu Jan 8 15:40:40 CET 2015 armv7l GNU/Linux
root@bananapi / # fdisk -l
Disk /dev/mmcblk0: 7901 MB, 7901020160 bytes
4 heads, 16 sectors/track, 241120 cylinders, total 15431680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x6c70c806
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 2048 43007 20480 83 Linux
/dev/mmcblk0p2 43008 3970047 1963520 83 Linux
Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
81 heads, 63 sectors/track, 765633 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0xc34090f5
Device Boot Start End Blocks Id System
/dev/sda1 2048 3907029167 1953513560 83 Linux
root@bananapi / # df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 1.9G 921M 871M 52% /
/dev/root 1.9G 921M 871M 52% /
devtmpfs 486M 0 486M 0% /dev
tmpfs 98M 212K 97M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 195M 0 195M 0% /run/shm
/dev/sda1 1.8T 65G 1.7T 4% /media/red2tb
root@bananapi / # mount -l
/dev/root on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=496784k,nr_inodes=124196,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=99380k,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=198760k)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
/dev/sda1 on /media/red2tb type ext4 (rw,relatime,data=ordered) [red2tb]
HDD r/w tesztek SATA csatolón
root@bananapi / # dd if=/dev/zero of=/media/red2tb/test1024.tmp bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 26.2495 s, 40.9 MB/s
dd if=/dev/zero of=/media/red2tb/test1024.tmp bs=1M count=1024 0.02s user 10.46s system 38% cpu 27.424 total
root@bananapi / # dd if=/media/red2tb/test1024.tmp of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.01715 s, 153 MB/s
dd if=/media/red2tb/test1024.tmp of=/dev/null bs=1M count=1024 0.00s user 6.23s system 88% cpu 7.032 total
root@bananapi / # dd if=/dev/zero of=/media/red2tb/test4096.tmp bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 108.239 s, 39.7 MB/s
dd if=/dev/zero of=/media/red2tb/test4096.tmp bs=1M count=4096 0.04s user 37.23s system 34% cpu 1:48.89 total
root@bananapi / # dd if=/media/red2tb/test4096.tmp of=/dev/null bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 28.8452 s, 149 MB/s
dd if=/media/red2tb/test4096.tmp of=/dev/null bs=1M count=4096 0.08s user 26.89s system 93% cpu 28.862 total
root@bananapi / # hdparm -V
hdparm v9.39
root@bananapi / # hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 782 MB in 2.00 seconds = 390.26 MB/sec
Timing buffered disk reads: 378 MB in 3.01 seconds = 125.57 MB/sec
hdparm -tT /dev/sda 0.49s user 4.96s system 40% cpu 13.587 total
A várakozásoknak megfelelően teljesen jó írási és olvasási értékeket mérek.
Hálózati tesztek
root@bananapi / # ethtool --version
ethtool version 3.4.2
root@bananapi / # ethtool eth0
Settings for eth0:
Supported ports: [ TP AUI BNC MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
Gigabiten, full duplexen összeáll a kapcsolat, eddig rendben.
root@bananapi / # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:42:09:xx:xx:xx
inet addr:10.5.1.10 Bcast:10.5.1.255 Mask:255.255.255.0
inet6 addr: fe80::42:9ff:fec1:ed35/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:375146 errors:0 dropped:0 overruns:0 frame:0
TX packets:2932569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24926078 (23.7 MiB) TX bytes:138459585 (132.0 MiB)
Interrupt:117 Base address:0xc000
Hálózati beállítás jó, az interfész nem hibázik. Ubuntu-n figyelésre rakom iperf-et, majd rákiabálok a Pi-vel:
root@bananapi / # iperf --version
iperf version 2.0.5 (08 Jul 2010) pthreads
root@bananapi / # iperf -c 10.5.1.115
------------------------------------------------------------
Client connecting to 10.5.1.115, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.5.1.10 port 48978 connected with 10.5.1.115 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 579 MBytes 485 Mbits/sec
iperf -c 10.5.1.115 0.03s user 8.39s system 83% cpu 10.056 total
Pi-t rakom figyelésre, Ubuntu kiabál rá:
root@bananapi / # iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.5.1.10 port 5001 connected with 10.5.1.115 port 56587
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 761 MBytes 637 Mbits/sec
[ 5] local 10.5.1.10 port 5001 connected with 10.5.1.115 port 56588
[ 5] 0.0-10.0 sec 754 MBytes 630 Mbits/sec
[ 4] local 10.5.1.10 port 5001 connected with 10.5.1.115 port 56589
[ 4] 0.0-10.0 sec 775 MBytes 649 Mbits/sec
^Ciperf -s 0.11s user 23.21s system 46% cpu 50.201 total
Iperf mérés eddig az előzetes várakozásoknak megfelelő sebességet mutat. Pi oldalon 2222 porton figyelésre állítom netcat-ot, hogy az Ubuntu kliensről egy bananian image-et megetessek vele.
root@bananapi / # nc -v -v -l -n -p 2222 >/media/red2tb/bananian-1501.img
listening on [any] 2222 ...
connect to [10.5.1.10] from (UNKNOWN) [10.5.1.115] 54769
sent 0, rcvd 2032664576
nc -v -v -l -n -p 2222 > /media/red2tb/bananian-1501.img 0.77s user 54.10s system 47% cpu 1:55.75 total
# 2032664576/54.1 =37572358 Bps =35,83 MBps
A letöltési sebesség teljesen elfogadható. Megnézem visszirányba is, első körben a korábbiakban /dev/null-ból dd-zett, 1GB méretű teszt állománnyal.
Ubuntu hallgatózik: $ nc -v -v -l -n -p 2222 >/dev/null
Pi rákiabál:
root@bananapi / # pv -t -r -a -b -s 1024m /media/red2tb/test1024.tmp | nc -v -v -n 10.5.1.115 2222 >/dev/null
(UNKNOWN) [10.5.1.115] 2222 (?) open
1GB 0:00:35 [29.2MB/s] [29.2MB/s]B/s]
sent 1073741824, rcvd 0
pv -t -r -a -b -s 1024m /media/red2tb/test1024.tmp 0.19s user 15.20s system 43% cpu 35.087 total
nc -v -v -n 10.5.1.115 2222 > /dev/null 0.39s user 27.00s system 53% cpu 50.827 total
A várt eredményt kapom, teljesen korrekt a sebesség. Ugyanez a teszt, ezúttal bananian image-dzsel, most jön a fekete leves:
root@bananapi / # pv -t -r -a -b -s 2032664576 /media/red2tb/bananian-1501.img | nc -v -v -n 10.5.1.115 2222 >/dev/null
(UNKNOWN) [10.5.1.115] 2222 (?) open
455MB 0:01:01 [ 177kB/s] [7.45MB/s]
457MB 0:01:03 [ 825kB/s] [7.18MB/s]
463MB 0:01:21 [4.88MB/s] [ 5.7MB/s]
488MB 0:01:36 [19.5MB/s] [5.05MB/s]B/s]
508MB 0:01:40 [1.21MB/s] [5.04MB/s]
508MB 0:01:41 [ 766kB/s] [ 5MB/s]
670MB 0:01:55 [2.88MB/s] [ 5.8MB/s]
686MB 0:01:58 [14.7MB/s] [5.79MB/s]
730MB 0:02:00 [ 27MB/s] [6.07MB/s]
1.19GB 0:02:21 [8.28MB/s] [8.59MB/s]B/s]
1.19GB 0:02:24 [92.3kB/s] [8.43MB/s]
1.19GB 0:02:26 [ 128kB/s] [8.32MB/s]
1.21GB 0:02:33 [1.01MB/s] [8.04MB/s]B/s]
1.21GB 0:02:35 [60.4kB/s] [7.94MB/s]
1.26GB 0:02:37 [27.4MB/s] [8.18MB/s]
1.28GB 0:02:42 [ 849kB/s] [8.03MB/s]
1.28GB 0:02:44 [ 2.5MB/s] [7.95MB/s]
1.3GB 0:02:52 [ 121kB/s] [7.72MB/s]
1.44GB 0:03:09 [ 241kB/s] [7.78MB/s]
1.46GB 0:03:10 [22.7MB/s] [7.86MB/s]
1.72GB 0:03:20 [ 28MB/s] [8.79MB/s]
1.84GB 0:03:25 [26.8MB/s] [9.18MB/s]
1.89GB 0:03:27 [9.35MB/s] [9.35MB/s]
sent 2032664576, rcvd 0
pv -t -r -a -b -s 2032664576 /media/red2tb/bananian-1501.img 0.56s user 29.86s system 14% cpu 3:27.24 total
nc -v -v -n 10.5.1.115 2222 > /dev/null 0.88s user 48.94s system 14% cpu 5:51.00 total
Hupsz. A különféle időpontokban megjelölt értékeken látszik, hogy a sebesség ugrál, időnként el is dobja a kapcsolatot, majd újraépítés után jó esetben folytatja a letöltést. Jelen átlagsebesség még viszonylag jónak mondható, a tapasztalat az átlag 3-8MBps. Próbáltam még avi-val, 7z-pel, szignifikáns eltérés nem volt. Adatátvitel közben másik shellben mpstat-on figyeltem mi történik:
root@bananapi / # mpstat 2 10
Linux 3.4.104+ (bananapi) 01/17/2015 _armv7l_ (2 CPU)
10:51:31 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
10:51:33 AM all 0.00 0.00 1.05 0.26 0.00 0.79 0.00 0.00 97.90
10:51:35 AM all 0.27 0.00 2.16 0.00 0.00 0.54 0.00 0.00 97.03
10:51:37 AM all 0.00 0.00 2.54 0.00 0.00 4.24 0.00 0.00 93.22
10:51:39 AM all 0.27 0.00 2.73 0.00 0.00 0.00 0.00 0.00 96.99
10:51:41 AM all 0.00 0.00 2.70 0.00 0.00 1.08 0.00 0.00 96.22
10:51:43 AM all 0.00 0.00 1.86 0.00 0.00 0.80 0.00 0.00 97.34
10:51:45 AM all 0.00 0.00 3.29 0.00 0.00 2.19 0.00 0.00 94.52
10:51:47 AM all 0.00 0.00 2.17 0.00 0.00 2.17 0.00 0.00 95.66
10:51:49 AM all 0.00 0.00 2.78 0.00 0.00 2.78 0.00 0.00 94.44
10:51:51 AM all 0.00 0.00 1.87 0.00 0.00 1.07 0.00 0.00 97.06
Average: all 0.05 0.00 2.31 0.03 0.00 1.55 0.00 0.00 96.07
Semmi figyelemre méltó, ami magyarázná a jelenséget. Tesztek után az interfészen hibák továbbra sem látszanak:
root@bananapi / # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:42:09:xx:xx:xx
inet addr:10.5.1.10 Bcast:10.5.1.255 Mask:255.255.255.0
inet6 addr: fe80::42:9ff:fec1:ed35/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2455970 errors:0 dropped:0 overruns:0 frame:0
TX packets:6835182 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2197880151 (2.0 GiB) TX bytes:1332678124 (1.2 GiB)
Interrupt:117 Base address:0xc000
További jelenség, hogy a logok szerint az interfész időnként előszeretettel fel-le járkál, bár ez független az interfész leterheltségétől. Időnként az autonegotiate sem sikerül neki ahogy kéne:
root@bananapi / # dmesg | grep Link
[ 30.661919] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 196.672109] PHY: sunxi_gmac-0:00 - Link is Down
[ 198.671940] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 310.682101] PHY: sunxi_gmac-0:00 - Link is Down
[ 311.681934] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 313.692108] PHY: sunxi_gmac-0:00 - Link is Down
[ 324.691928] PHY: sunxi_gmac-0:00 - Link is Up - 100/Full
[ 1337.454180] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1435.472654] PHY: sunxi_gmac-0:00 - Link is Down
[ 1438.472743] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1444.483418] PHY: sunxi_gmac-0:00 - Link is Down
[ 1447.483497] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1459.494686] PHY: sunxi_gmac-0:00 - Link is Down
[ 1461.494696] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1491.507398] PHY: sunxi_gmac-0:00 - Link is Down
[ 1493.507410] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1529.520632] PHY: sunxi_gmac-0:00 - Link is Down
[ 1542.521588] PHY: sunxi_gmac-0:00 - Link is Up - 1000/Full
[ 1584.535316] PHY: sunxi_gmac-0:00 - Link is Down
[ 1597.536252] PHY: sunxi_gmac-0:00 - Link is Up - 100/Full
ethtool -s eth0 speed 1000 duplex full autoneg off nem változtat a korábbi teszt eredményeken.
Én valamilyen hardver hibára következtetek. Tudok-e esetleg még más tesztet elvégezni, vagy megalapozott a gyanúm? Bármilyen segítséget, ötletet, javaslatot, kritikát megköszönök.
Hozzászólások
1, nem lehet, hogy siman csak az ext4 lazyinit fut meg mindig? iostat -x 1, aztan ha van folyamatos iras a diszken, akkor bizony meg az inicializal
2, ki lehet probalni ujabb kernellel, en 3.19-rc4-et hajtok a bananainkon (van 8 db most), lehet ez megoldana a nic problemakat is
Köszi, este megnézem.
1, Nem, nulla írási művelet.
2, Nagyjából változatlan a helyzet. Annyi változás azért történt, hogy a ~28 MBps helyett valahol ~38-40 MBps környékén van az upload plafon a netcat-os tesztnél. Ettől függetlenül továbbra is szélsőségesen ugrál változatosan 0-40 MBps között. Amikor nullára esik, iostaton sem látszik, hogy bármi hasznosat csinálna:
avg-cpu: %user %nice %system %iowait %steal %idle
0,00 0,00 0,00 0,00 0,00 100,00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
mmcblk0 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
sda 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00
>kritikát megköszönök
legközelebb ne dőlj be a hupon megjelenő marhaságoknak
sub
A helyedben teszteléshez nem virtuális gépet használnék. Helyette egy pendrive-ra érdemes feldobni ubuntu telepítőt, aztán live módban elindítani vele a fizikai vasat.
Ha jól értettem, akkor külön-külön jól működnek a dolgok, csak amikor a bpi és a virtuális gép közt tolsz át adatot, akkor szórakozik a sebesség.
Köszi, ezt még reggel megnézem, ha hazaérek, de igazság szerint sok reményt nem fűzök hozzá.
A probléma ott kezdődött ugyanis, hogy a vmware hostról (csupe1 vas) nem tudtam tisztességes sebességen lehúzni az adatokat (samba, ftp, http, scp próbák voltak). Az Ubuntu-s tesztek a szűk keresztmetszet behatárolására történtek.
Update @08:38:
Sajnos jól sejtettem, nem befolyásolta az eredményeket:
root@bpi / # pv -t -r -a -b -s 2032664576 /media/red2tb/bananian-1501.img | nc -v -v -n 10.5.1.102 2222 >/dev/null
(UNKNOWN) [10.5.1.102] 2222 (?) open
192MiB 0:00:10 [ 34MiB/s] [19,2MiB/s]
366MiB 0:00:15 [ 36MiB/s] [24,5MiB/s]
384MiB 0:00:17 [ 249KiB/s] [21,9MiB/s]
431MiB 0:00:20 [6,95MiB/s] [21,6MiB/s]
451MiB 0:00:22 [3,36MiB/s] [20,5MiB/s]
452MiB 0:00:23 [ 749KiB/s] [19,5MiB/s]
456MiB 0:00:27 [ 577KiB/s] [16,8MiB/s]
^C sent 483532800, rcvd 0s] [16,2MiB/s]
Megoldódott ez a probléma? :) Mostanában készülök venni valamilyen Pi-t, szintén NAS, FTP, torrent (és esetleg VPN szerver) céljából. Célom, hogy Gigabites sebességet vigye a hálókártyája és az USB porton se fogja semmi vissz a sebességet, mert egy külső WD HDD-t kötnék rá. Nézegettem pár napja a Raspberry Pi-k leírását, de nem találtam olyat, aminek gigabites hálókártyája lenne (ha pedig mégis van ilyen, akkor az elkerülte a figyelmemet :D), meg olyat is olvastam, hogy a hálózati adaptere az USB-buszon ül, aminek nem örülnék, mert szerintem akkor az USB-s HDD és a hálókártya kölcsönösen lassítanák egymást. Aztán ráakattam a neten a Banana Pi-re, amit már viszont konkrétan gigaties hálózati kártyákkal hirdettek, viszont arra nem találtam utalást, hogy az is az USB-kontroller buszán van vagy sem. Erről tudnátok felhomályosítást adni? :) A lényeg annyi lenne, hogy a lehető legkisebb fogyasztása legyen a kütyünek, az adaptere ne forrjon fel olvadáspontig és este nyugodtan tudjak mellette aludni, legfejlebb csak a HDD-nek legyen zaja :) (Tudom, a Pi-knek nincsen ventillátoruk, csak arra az esetre gondolok, ha esetleg ezekre a célokra mégsem valamilyen Pi-t ajánlotok :) )
Köszi :)
MysteryKe.
http://hup.hu/node/135395#comment-1783669
A Raspberry Pi kevés lesz ennyi mindenhez, de talán még a Banana Pi is.
Ja, azt elfelejtettem mondani, hogy 3.5"-os USB WD HDD-t kötök rá, úgyhogy a winyó tábellátásával nem lenne gond :)
szerk.: Ja és csak parancssori üzemmódban futni, úgyhogy az asztalkezelő sem terhelné a procit :)