How am I exceeding USB 2.0 speeds on a USB 2.0 port?

3

I am writing files to a USB 2.0 drive from a RAM disk, that has a 256MB random filled file on it (created from /dev/urandom to stop the file being compressed too much). When I look at the speeds of the file writes which is output from dd, they are averaging around 75MB/s. This is particularly interesting, because the theoretical maximum speed of USB 2.0 is 60MB/s.

The command that I'm running is:

dd if=/var/mnt/temp_data/urandom of=/mnt/usb/$FILE_NAME bs=10M count=1

Note that I'm running this multiple times, and I fill the drive to 95% full. The reason for the 10MB files is to make sure that the drive is pretty close to 95% full, and I wouldn't get that sort of fill with larger files, as I don't know what size memory stick will be plugged in, and having multiple files is part of the test.

If motives affect write speed, what I'm doing is testing the write speed of the USB ports on a system to see if they conform to USB standards. Hence this being relatively distressing, and the filling from /dev/urandom (indirectly).

So why is this happening and how do I fix it? I'm assuming that the measurements that dd is outputting is inaccurate, otherwise I'll start selling USB driver writers my secrets.

(Apologies if this should be on unix.se, I wasn't sure)

Yann

Posted 2014-12-10T10:20:13.503

Reputation: 239

First of all bs=10M count=1 will not give you a good approximation of write speed, because you are only writing 10Mb. Data may be getting cached somewhere. I would recommend to write at least 1Gb of data. Try bs=1M count=1000, and see if result is different – Art Gertner – 2014-12-10T10:24:06.400

@smc I'm not just running that once, I'm filling the drive with 10MB files, and the ~75MB is averaged over the full test – Yann – 2014-12-10T10:25:24.543

the command you have provided does not fill the drive with 10MB files, it only writes one. Ther performance reported by dd during the execution of this command may be affected by write-caching. Try the command parameters that I have suggested above, or modify it so that dd fills the whole drive – Art Gertner – 2014-12-10T10:28:30.353

@smc It does when you run it lots of times. It's in a for loop. – Yann – 2014-12-10T10:29:42.547

are you ignoring what I just said? You cannot rely on the speed reported in that command when you run it multiple times. This is what 'count=x' is for – Art Gertner – 2014-12-10T10:31:24.413

@smc I'm running sync after each dd, if that'd eliminate what you're getting me to check for. (I'm doing it now anyway, it'll just take a little while) – Yann – 2014-12-10T10:35:46.687

Let us continue this discussion in chat.

– Art Gertner – 2014-12-10T10:36:32.397

Answers

2

Ok, so following all the comments and our lengthy discussion in chat here is the answer to the question:

When you are testing the write speed on the system, whether it is writing to USB or HDD, writing to FilesSystem or directly to disk in RAW mode, always make sure to write enough data to fill the cache. If not enough data is written, you are measuring the speed of writing to cache (which is in RAM)

OP, has attempted to write 10MB files in a loop executing sync command between write sessions.

What effectively happened, was that dd command that did the writing would write data to cache very quickly. Reported speed was around 75MB/s. After that sync command would take several seconds to execute, but OP did not take this into account.

After changing the test to write larger files, it was revealed that actual write speed is around 2.2MB/s which is well withing USB 2.0 standards

Art Gertner

Posted 2014-12-10T10:20:13.503

Reputation: 6 417

Asked: 2014-12-10T10:20:13.503

Viewed: 208 times

Active: 2014-12-10T13:18:50.177