Pogoplug v4 I/O performance issues, how to tweak?

[tilllt]

Hi,

i mainly bought the Pogoplug4 because i want to build a battery operated, in-the-field backup device for SD-Cards to Sata / USB3 etc. Yesterday i installed Arch Linux, since the instructions seemed most clear for this particular device. After i got things up and running, i was doing some tests, copying a large file from a (very fast) Sandisk Exteme Pro 64gb SD card (connected via the SD-Car reader) to a (very fast) OCZ Vortex 3 SSD connected via the USM / sata connector.

The performance was so underwhelming, that i assume i must be doing something wrong. rsync averaged at around 10mb/s copying a huge movie file. I already read the blog post about the pp4 not having the best I/O Performance here
http://fortysomethinggeek.blogspot.de/2 ... eview.html

but the guy is talking about 30-40MB/s, not 10!

I was thinking that ExFat may be the throtteling factor on this, both the SD-Card and the SSD are in Exfat, and have to be in Exfat in the future probably.

Is there some advice on how i could tweak things to get a better performance? Like this, the whole device doesnt make sense for me, i bought it for USB3 and Sata connectors, with that speeds i can use my RPi with USB2 and get it done faster.

cheers,
t.

p.s. this is the dmesg output of a fresh arch linux install boot:
http://pastebin.com/s3yJyiDn

p.p.s. dmesg of connecting the sata SSD drive
[ 1702.032270] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4010000 action 0xe frozen
[ 1702.039682] ata1: edma_err_cause=00000010 pp_flags=00000000, dev connect
[ 1702.046365] ata1: SError: { PHYRdyChg DevExch }
[ 1702.050926] ata1: hard resetting link
[ 1702.959047] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[ 1703.239077] ata1.00: ATA-8: OCZ-VERTEX3, 2.22, max UDMA/133
[ 1703.239095] ata1.00: 937703088 sectors, multi 16: LBA48 NCQ (depth 31/32)
[ 1703.279079] ata1.00: configured for UDMA/133
[ 1703.279108] ata1: EH complete
[ 1704.169392] scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX3 2.22 PQ: 0 ANSI: 5
[ 1704.171927] sd 0:0:0:0: [sdb] 937703088 512-byte logical blocks: (480 GB/447 GiB)
[ 1704.172386] sd 0:0:0:0: [sdb] Write Protect is off
[ 1704.172405] sd 0:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 1704.172550] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1704.176331] sd 0:0:0:0: Attached scsi generic sg1 type 0
[ 1704.179378] sdb: sdb1 sdb2
[ 1704.187090] sd 0:0:0:0: [sdb] Attached SCSI disk

[Veyrdite]

Are you sure it has USB 3.0 ports? Blue plastic is ambiguous, and I can't find specs for this item outside the blogpost you linked. Try a lsusb in a terminal and see if any 3.0 hubs are listed.
EDIT: Looking at your dmesg you only appear to have references to USB 2.0 . Check anyway

If you want to determine whether or not the filesystem is your problem you are going to have to try raw reading and writing just like Fortysomethinggeek did.

Reading is inherently safer than writing over your card with test data, so I can recommend trying it. If your read-speed is capped at about the same speeds as you have seen, then it's not the filesystem's fault. dd with the following options will perform a read-speed test for you.
$this->bbcode_second_pass_code('', 'if=/dev/yourdevice of=/dev/null bs=1M count=500')
Where:

• if = input device. Don't mix this and 'of' up, otherwise you will write onto your card instead of reading from it (destroying data!)
• of = output device. We don't want write speeds to influence the test in this case, so we'll just send it somewhere where it is discarded
• Amount of data read = BS x COUNT, here it's 500MiB. Small values suffer error from caching, larger values take longer.

dd runs silently, only giving you results once it's completely finished.

[tilllt]

i think it has / should have USB3

[root@alarm ~]# lsusb
Bus 001 Device 002: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The first device is the USB memory that i am booting the system of.

...but i am not even using USB3 right now. For the moment i am copying from the internal card reader to the SSD...

[root@alarm mnt]# dd if=/dev/sdb1 of=/dev/null bs=1M count=500
200+0 records in
200+0 records out
209715200 bytes (210 MB) copied, 3.49172 s, 60.1 MB/s
[root@alarm mnt]# dd if=/dev/mmcblk0 of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 46.8146 s, 11.2 MB/s

so SD-Card reader seems to be really slow, but i got the same performance when using an external USB3 Lexar reader, which performs really well when connected to other machines (like my mac).

[Veyrdite]

I definitely agree the SD card reader appears to be slow, assuming it's the mmc device.

When the USB 3.0 card reader is plugged in, try lsusb again with the '-t' option so we can see what speed it's being setup for. USB 3.0 might only work on one of the ports, or might not properly exist (eg SOC feature that wasn't used by the designers).

EDIT: Have you looked inside the USB ports? Do they have the extra five little contacts infront of the four big ones?

[tilllt]

This is with the Lexar USB3 Card Reader:

[root@alarm ~]# lsusb
Bus 001 Device 002: ID 058f:6387 Alcor Micro Corp. Flash Drive
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 05dc:b049 Lexar Media, Inc.
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

[root@alarm ~]# lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M

[root@alarm ~]# dd if=/dev/sdd1 of=/dev/null bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 16.0115 s, 32.7 MB/s

but then again, when copying a large file from the SD card (in the Lexar Reader) to the SSD connected via USM / Sata:
rsync -var --progress /mnt/usb1/ /mnt/sata/test2
sending incremental file list
4,096 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=11/13)
2014-05-28_1318_C0000.mov
156,762,112 1% 9.85MB/s 0:15:17

p.s. and 30MB/s is far away from the performance i had hoped for.

[WarheadsSE]

They are indeed USB 3.0 ports.

Problem: this little SoC wasn't meant for uber-fast throughput.

[tilllt]

i was not expecting to read at 90MB/s from the SDCard or write at 300MB/s to the SSD.
But i really doubt that the PPv4 can only transfer at around 10MB/s even if it is a low end SoC.

[tilllt]

SSD connected to UMS / Sata slot:
[root@alarm usb1]# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 172 MB in 3.00 seconds = 57.25 MB/sec

SD Card in PPv4 interal SD Reader
[root@alarm usb1]# hdparm -t /dev/mmcblk0
/dev/mmcblk0:
Timing buffered disk reads: 34 MB in 3.18 seconds = 10.68 MB/sec

SD Card in Lexar USB3 external SD Reader
[root@alarm usb1]# hdparm -t /dev/sde
/dev/sde:
Timing buffered disk reads: 136 MB in 3.05 seconds = 44.64 MB/sec

But when using rsync from Lexar SD to SSD, peaks around 10MB/s...

also curious

hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 436 MB in 3.00 seconds = 145.32 MB/sec

[root@alarm usb1]# hdparm -t --direct /dev/sde

/dev/sde:
Timing O_DIRECT disk reads: 192 MB in 3.01 seconds = 63.70 MB/sec

reading direct from SSD / SD

[tilllt]

ExFAT seems to be a big part of the Problem. CPU usage is extremely high when using ExFAT, when source & destination are both ExFAT, the CPU is maxed out while copying. Thus the 10MB/s ...

From ExFAT to HFS+ it goes up to around 18MB/s...

HFS+ to HFS+ seems to be around 30MB/s, which is not great but usable.
These numbers came from using pv file1 > file2

dd & dc3dd seem to be around 25MB/s
RSync still at 11MB/s

If anybody knows more anything how to get this even faster, i would really appreciate the help.

[WarheadsSE]

rsync does some checksum'ing, IIRC, which would add to it.