USB is slow

Can anyone recommend a USB hard drive for the Beagleboard XM that will be at least as fast as the hard disk on the Iyonix please? I am getting the Beagleboard XM because it is nearly twice as fast as the Iyonix and would not like to get the wrong drive for it and find performance issues. Many thanks.

Try a fast SSD…

To be honest, I don’t think that an USB 2.0-connected harddrive will ever outperform an UDMA100-connected harddrive. USB 2.0 carries a certain communication and processing overhead that just cannot be optimized away.

But you also have to consider that there are very few RISC OS applications which need an ultrafast harddisc, so it is unlikely that the performance difference between a BeagleBoard-connected HD and an IYONIX-connected HD will make much difference to the perceived system performance.

It is a shame that the BeagleBoard XM has not added S-ATA to its connectivity options.

I’ve finally got round to playing around with EtherUSB with Moonfish running on a Beagleboard, and Sunfish on an Iyonix using the onboard ethernet. On the Iyonix, I was then copying a 18MB JPEG from RAMFS to MemFS on the beagleboard and then pulling it back again using *copy.

The baseline figures are about: Push 8.20 sec (36.60 sec for USB 1 pegasus device) Pull 172.00 sec

The only exception was the pegasus device which I assume is an old chip as it appears to be USB 1. Its figures are: Push 36.60 sec Pull 172 sec

Of the four devices I have only one worked reliably if I allowed multiple packets in the USB write buffer which was the AX88772. Its figures become: Push 8.20 sec Pull 6.11 sec

This chip adds a header to each packet specifying its length, presumably allowing it to deal correctly with multiple ethernet packets in one USB transfer.

The AX88127 and MCS7830 devices have no such header.

Of the four devices I have only one worked reliably if I allowed multiple packets in the USB write buffer which was the AX88772.

James, what product was this, and where did you get it from?

James, what product was this, and where did you get it from?

Never mind – I have an adaptor with the AX88772 in it…

Does your released EtherUSB drive the AX88772, or did you have to write extra code that’s not (yet?) released?

The released 0.08 should be able to drive it, assuming the product and vendor codes are in the list so that it gets picked up. If not see the README.

The released 0.08 should be able to drive it, assuming the product and vendor codes are in the list so that it gets picked up.

Indeed it does, James, thank you.

The one I have is a Newlink NLUSB2-ETH, which simply presents the AX88772’s VID (0B95) and PID (7720).

I did a similar experiment to yours, using the OMAP TRM (a 22 MiB PDF). However, the pull speed I got was dire. It didn’t show anything like the speed you got. Any ideas?

Did you get something like the rather low ‘baseline’ figures quoted above? If you’re feeling brave, try the EtherUSB at:

http://effarig.co.uk/files/testeusb.zip

Did you get something like the rather low ‘baseline’ figures quoted above?

I did indeed.

If you’re feeling brave, try the EtherUSB at…

Aha, a new version of EtherUSB, I see. Thanks, James, I’ll try that tonight and let you know the results ASAP.

OK, the results are in. Test file is spruf98d (22892843 bytes).

EtherUSB 0.08 (04 Apr 2010): Push: 15 s, Pull: 308 s

EtherUSB 0.08 (03 Oct 2010): Push: 15 s, Pull: 49 s

I’m logged in to the ROOL site via the new version, which is a huge and very welcome speed improvement, so thank you for that. Nothing has gone wrong yet :-)

I’m still not getting your speeds, though.

Where does TimeX come from? Google didn’t help (Timex having manufactured and branded computers in the 1980s, there were far too many spurious hits). I used Time twice instead and subtracted the start time from the end time. That’s why the above results are only to a resolution of 1 second.

TimeX is from the ARMClub website IIRC, part of TimerMod.

I’m still not getting your speeds, though.

I’ve repeated the test numerous times with different builds and always get more or less the same timings. The credit really goes to Jeffrey though. I’d just assumed that putting multiple packets in the tx buffer would fail to work properly as it does with all my other devices, so never thought of trying it. The AX88772 makes it easy to get semi-decent ‘upload’ performance.

For the others, I think I can improve the buffering (see Jeffrey’s posts earlier in this thread), though this is fighting against DeviceFS which is stream based rather than packet based.

In addition notification of the Tx buffer emptying is not working properly, and never has; fixing this alone would probably make a massive improvement. This is the first thing I want to work on.

In addition, I’d be interested in getting hold of a Pegasus II device and a plugin version of the one on the XM, if they aren’t too pricey.

James, I suggest that your newer version of EtherUSB is worthy of a new release (0.09?) in view of the large performance boost to AX88772-based devices.

That is very much a development version and has had very little testing of the other backends. I’ve noticed that access to the network seems to stop after a few hours even though the link is up.

It also looks like there’s a bug in your RX code – usb_start_read doesn’t pass the (undocumented) read size in R3 to RxWakeUp. So at the moment it’s pure luck that it works at all.

In addition to fixing the above, I’ve been updating EtherUSB to use the new APIs in USBDriver, rather than peaking into its private workspace. The changes made the read performance very poor. After hours of going over everything it turned out that passing a sensible value for this R3 was the cause.

It turns out that passing any reasonable size, like the max packet length (USB or ethernet) or the buffer size, caused read performance to plummet. What you appear to need to do is to pass something massive, e.g. 1<<30.

James, any chance you will add the sources to that new version? I would like to try and compile it over here since i have a non-listed device that i can get working with adding the device vendor and product IDs. Also you could just add : Vendor 0×0df6 prod 0×0021 with N_MCS7830 backend. This is a Sitecom USB2.0 network adapter.

I’ll look at doing that sometime this week, so at least people who are interested can look at it. It appears to work, but I don’t know why.

If any one does find they can get devices to work by adding the vendor codes, let me know and I’ll add them. Thanks to those who have already done so.

The following perhaps isn’t USB related, but I don’t want to unnecessarily post a bug report or begin a new thread.

When performing a Count on a USB flash drive (2Gb), the filer action window pauses partway through for 30 secs – everything else freezes, although keys pressed go into the buffer and are reproduced in Zap when things pick up again.

• 133226579
• 133236790
• 133293949
• 133261789

Counting in a TaskWindow doesn’t visually produce the same pause, and the total size arrived at is equal.

Does anyone have any idea how these tables of I/O operations /s compare with what RISC OS can currently achieve via USB? (So far, I’ve understood that the discussion has been around data transfer speeds, rather than I/O operations.)

[Edit: Apologies if this should have been in the Towards BeagleBoard "CMOS RAM" thread.]

I can’t answer your question, Trevor, but thought I’d mention that there’s a similarly interesting page here.

Whilst experimenting with the version of EtherUSB that supports the on-board Ethernet port on the XM I noticed !Netsurf was loading pages much quicker even though my broadband is the bottle neck.

According to the RISCOSmark benchmark my disc speeds have increased by about 50%. This is using a USB hard drive. I was previously using a network port built into a USB hub. It must have been slowing USB down somehow.

Speed with HUB plugged in.

HD Read - Block load 1MB file                               8110     271%
HD Write - Block save 1MB file                             10727     352%
FS Read - Byte stream file in                                 74      35%
FS Write - Byte stream file out                               73      38%

Speed without HUB plugged in.

HD Read - Block load 1MB file                              12047     403%
HD Write - Block save 1MB file                             16062     528%
FS Read - Byte stream file in                                122      58%
FS Write - Byte stream file out                              119      61%