Unzipping Performance

[MindFreak]

Hello,

i am wondering how well this little guy can unzip .rar or .zip files. I would like to use this board as a download server (which are zipped as .rar or .zip archives) and i would like to know how well it works. Since this is the only task for this i dont know if i should take this one or somethink like the odroid c1+.

Thanks

[deleted]

How well it works: For me the board seems to be quite stable, even though I’m using an old almost worn-out harddisk while testing. The board has been running continously (and without crashing) for a few weeks now.

The odroid c1+ is a nice board, it has a fast quad-core CPU, but that does not mean it will perform well.
EspressoBIN is the only affordable board with a high-speed SATA interface.
All other affordable boards use USB-to-SATA bridges, which means you won’t get much more than 50/sec-60MB/sec. transfer speed. The EspressoBIN has a REAL 6G SATA, which means you’d be able to get more than 500MB/sec – and you could also add a extra SATA interfaces if you decide that later.

For extracting zip and rar, you’ll likely want unzip and unrar – perhaps also unar and lsar.

Try this first:
sudo apt-get install unrar

-If you get an error, add the ‘multiverse’ repository, then try again:
sudo add-apt-repository multiverse

-If ‘add-apt-repository’ is not found, then install it by issuing…
sudo apt-get install software-properties-common
… and proceed with installing unrar …
sudo apt-get update
sudo apt-get install unrar

When you’ve gotten unrar installed, you can proceed to unzip and unar:
sudo apt-get install unzip

-If that fails, try adding the ‘universe’ repository, then try again:
sudo add-apt-repository universe
sudo apt-get update
sudo apt-get install unzip

If you succeeded in installing unzip, unar should install without problems.
sudo apt-get install unar

Note: If you at some point get a message about a package not being available, then try adding repositories (like ‘universe’ and ‘multiverse’) – search the internet to find out which repository is necessary in order to install the package.
-Most packages will likely install if you have the two mentioned repos, though.

[unknown]

“All other affordable boards use USB-to-SATA bridges, which means you won’t get much more than 50/sec-60MB/sec. transfer speed. The EspressoBIN has a REAL 6G SATA, which means you’d be able to get more than 500MB/sec – and you could also add a extra SATA interfaces if you decide that later.”

Not true at all. ODROID XU4 delivers 380 MB/s through USB 3.0. The ESPRESSObin’s CPU is way too slow for 500 MB/s

[deleted]

"Not true at all. ODROID XU4 delivers 380 MB/s through USB 3.0."

Sorry, I should have written: “All other boards with on-board SATA connector”, which was what I actually meant.
And since Odroid XU4 does not have an on-board SATA connector, I did not think of adding an extra SATA-via-USB3.0 adapter.

"The ESPRESSObin’s CPU is way too slow for 500 MB/s"

I for one can not proove that Marvell 3720 is too slow for 6G SATA.
Do you have any cool facts to share ?

[unknown]

USB is USB. Here are some benchmark with a > 500 MB/s capable SSD.

##### SATA #####

## READ ##

[CODE][root@espressobin ~]# dd if=/dev/sda of=/dev/null bs=1024K count=10000 iflag=direct
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 33.5648 s, 312 MB/s

## WRITE ##

[root@espressobin mnt]# dd if=/dev/zero of=test bs=1024K count=5000 oflag=direct
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 18.6003 s, 282 MB/s

##### USB #####

## READ ##

[root@espressobin ~]# dd if=/dev/sdb of=/dev/null bs=1024K count=10000 iflag=direct
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB, 9.8 GiB) copied, 36.5435 s, 287 MB/s

## WRITE  ##

[root@espressobin mnt]# dd if=/dev/zero of=test bs=1024K count=5000 oflag=direct
5000+0 records in
5000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 21.2763 s, 246 MB/s

I am sorry but this board isn’t as great as it sounds.

* 5V USB powering doesn’t work even though announced differently.
* The CPU isn’t capable of the announced 1.2 GHz – not even with the correct u-boot version.
* USB 3.0 is broken and not thoroughly implemented. UAS doesn’t work and the controller tops out at max 4 devices (root + USB hub = 2 real devices). Also booting won’t work with certain USB hubs due to XHCI brokenness.
* The CPU is VERY slow compared to the XU4 (and where is 32-bit support?!)
* F*ing bright and very annoying LEDs
* Rebooting sometimes freezes the board (after OS exit). Especially amazing when you do not have physical access to the board.
* mPCIE does not work unless the kernel gets patched with a spurious patch. => http://espressobin.net/forums/topic/mini-pcie-slot-not-working/

I was actually planing to replace my XU4 with this board… but no. All I am doing with this board at the moment is using it as a network switch.

[deleted]

You’re saying that the CPU is not capable of 6G SATA, but you’re testing using a Linux command-line utility, not a test written for the CPU. If you’re saying that hardware is buggy, then please make a hardware test, not a software test.

You mention that the CPU is not able to run at 1.2GHz. Is this a problem with the CPU or is it actually a software problem ? -Eg. is it a problem with u-boot not being written correctly ?
-Anyway, CPU-speed does *not* matter at all. The CPU should *not* do any SATA transactions using CPU-instructions, the DMA should be used for that and that is independent of the instruction execution. If the software (eg. the driver) does not use the right hardware, that’s a software problem, not a hardware problem.

If you find that there is really a problem with the CPU, then you should notify Marvell that it can not satisfy the advertised capabilities. Marvell are experts when it comes to making high-speed SATA and network interfaces (the EspressoBIN does not wire the network interfaces optimally, though, it’s a hardware problem – yes – a board layout hardware problem, but that’s not Marvell’s fault, it’s due to USB3 was chosen over fast network).

My EspressoBIN reports 952 MB/sec on SATA when reading using ‘dd’.
-I know that this is not possible due to that the hard limit of SATA3 is 572.2 MB/sec – without counting the SATA protocol’s command overhead, so it must be Linux playing tricks on me (cache, asynchronous writing, etc).

If USB is USB, then you’d just need to go purchase a Lamobo-R1 (like I did), it has SATA via USB2. Needless to say, I do not use that board at all; some day I may set it up for doing some compile-tests, but that’s all I’ll ever use it for.
I’d still say that USB is not USB. There are several versions and speeds (too many if you ask me, plus USB speed is not what’s advertised; many people still believe in the that religion, though).

As for 32-bit access, I have been running 32-bit applications since I opened my EspressoBIN box.

Here’s the full recipe:

sudo bash
apt-get install software-properties-common
add-apt-repository universe
add-apt-repository multiverse
apt-get update
dpkg --add-architecture armhf
dpkg --print-foreign-architectures
apt-get autoclean
apt-get update
apt-get upgrade
apt-get -u dist-upgrade
apt-get install libc6:armhf
dpkg --configure -a
apt-get -f install
exit

-I’ve encountered no problems at all; you can even run chrome as a 32-bit application if you wish to do something crazy. 😉

As for the too bright LEDs, I agree, which is why I’ve desoldered R48 on both of my boards. I have no issues with heat after that.

If 5V USB powering doesn’t work for you, try getting a power supply of better quality.
Switch-mode power supplies tend to deliver way below the advertised current.
I have a fairly solid 12V/3.8A PSU on my board, which has no problem powering my USB3 devices.

mPCIe spurious problem: Again, that’s a software problem.
Have you tried Armbian ? -It should work with a few Mini-PCIe cards (eg. those that are supported by drivers for them, including an extra SATA card and some WiFi cards).

USB3 “brokenness” – again, is this a problem with the hardware, or is it a driver problem ? If it’s a driver problem, then it’s the software that is to blame. Nobody can expect drivers to work out-of-the-box on a new system that the driver was never written for.
-Imagine that someone made a new USB device for EspressoBIN only. It works perfectly on this platform. Now you want to use that USB-device on a PC with an Intel-based CPU. Do you think you can just build the driver and go ? -You might expect that, but I can tell you, you’d be in for a surprise; build problems, missing hardware definitions, missing symbols, missing libraries, timing problems, race conditions, etc. – the list is very discouraging and the work can be *very* hard.

You can’t expect that all software written for Intel will just work on ARM/PowerPC/M68xxx/Z80/6502/whatever. Hardware differs. You have to accept that.
You’ll also have to learn that the tests you’re doing personally might be indicating something, but they can be wrong; they can be far off, because you did not think of all possible scenarios.

I get it, things can be frustrating if they don’t just work the way you expect them to.
If someone answers “impossible” to one of your questions, do not believe them.
“Impossible” is such an abused word, and way too many people use this (for them) way-too-big-word way too much.
If you can imagine something in your mind, it’s usually possible to realize it in reality.

Most of the time things are not impossible; it’s just necessary to find the path to get them working. -Otherwise I would not be running nginx, I wouldn’t have my own server, I wouldn’t have been able to compile a cross-GCC for a PowerPC host with ARMv7-M based target (this is way more complicated than you may think, it took me more than 3 years to get everything right – and no, none of the available resources on the internet could be used). You may need to get your hands dirty and contribute to drivers, especially for devices that are a little rare.

[Author]

Posts