[ale] Microcenter Free USB sticks

[Greg Freemyer]

On Mon, Feb 21, 2011 at 2:53 PM, David Tomaschik
<david at systemoverlord.com> wrote:
> On Mon, Feb 21, 2011 at 2:24 PM, Ron Frazier
> <atllinuxenthinfo at c3energy.com> wrote:
>> This inspired me to do a bit of spur of the moment testing. I have a PNY
>> Attache 4GB memory stick, which is supposed to be pretty good. I think
>> it said high speed on the package, but don't remember for sure. I did
>> some testing writing 5 Ubuntu ISO's to the memory stick and reading from
>> the stick.
>>
>> For Linux, I just dragged files in the file manager.
>>
>> Linux - copy TO stick FROM internal HDD - 9.6 MBps
>> Linux - copy FROM stick TO internal HDD - 18.3 MBps
>
> Not surprising.  Flash media typically has better read than write performance.
>
>>
>> For comparison.
>>
>> Linux - copy FROM internal sata 5400 RPM HDD TO same HDD different
>> folder - ext4 -> ext4 - 29.4 MBps (It seems to me this should be much
>> faster.)
>> Linux - copy FROM internal sata 5400 RPM HDD TO same HDD different
>> folder - ext4 -> NTFS - 12.1 MBps (I found this interesting.)
>
> Also not surprising.  The NTFS support is most likely the ntfs-3g
> driver, which is implemented in userspace, and is probably sub-optimal
> due to reverse engineering of the NTFS.

Very much agreed ntfs-3g is not a fast driver at all.  I bet you CPU
for this test was actually breathing hard.  Or could be poor
optimization of the disk's head instead of poor optimization of the
cpu.

Either way, my experience with ntfs-3g is not good from a performance
standpoint.  (I have not had any functional issues.)


>> I think about 30 MBps is as fast as I ever get on USB, even to / from a HDD.
>>
>> Now, here's how Windows did. I used the Teracopy application to copy.
>>
>> Windows - copy TO stick FROM internal HDD - 10 MBps (Slightly faster
>> than Linux.)
>> Windows - copy FROM stick TO internal HDD - 15 MBps (Slightly slower
>> than Linux.)
>>
>> For comparison.
>>
>> Windows - copy FROM internal sata 5400 RPM HDD TO same HDD different
>> folder - NTFS -> NTFS - 18 - 23 MBps (Slightly slower than Linux ext4 ->
>> ext4.)
>>
>> Here's another interesting point. One other time, on another computer, I
>> did some testing from ONE internal SATA 7200 RPM drive to ANOTHER
>> internal identical drive on a different sata port.
>>
>> Linux ~ 30 MBps
>> Windows ~ 60 MBps
>
> This surprises me somewhat, but I suspect filesystems play a big role in this.
>

Sounds like a very uncontrolled test.  It could be filesize, disk
fragmentation, cache size, cache utilization, etc.

I do a lot of i/o with large files.  (2GB each).  linux (ext3),
linux(ntfs-3g) and windows (ext4) can all hit good speeds with large
files and fast drives.  On the order of 5GB/min.  I think I've seen
6GB/min a few times.

Obviously 6GB/min is 100 MB/sec, so it also makes sense from a spec.
perspective.

>> Windows was twice as fast. Something other than the interface is slowing
>> Linux down. However, I was thinking I should be over 200 MBps on both,
>> considering the 3 Gbps interfaces. Also, none of these experiments even
>> make the CPU breathe hard.
>
> The speed of the interface far exceeds the speed of reading from
> spinning platters, especially if seeking is involved.  (This is why
> fragmentation is terrible.)  According to Seagate, the internal
> transfer rate of SATA drives is about 1/3 of the interface speed.  So
> a purely-linear read task should yield about 100 MBps.  Of course, it
> takes LARGE files to make read/write tests useful unless you purposely
> disable various caching mechanisms.  (And then you still have to deal
> with filesystem overhead.)
>

Agreed.  the real advantage of 3 Gb/sec (or better yet 6 Gb/sec) is
with external disk enclosures that multiplex.  If you have a single
SATA data cable talking to half a dozen disks and each disk is
providing 1 Gb/sec of data, you need a 6 Gb/sec data path on the sata
cable to keep up.

They call them a Sata Port Multiplier (or PMP).  You can google around
for those. I haven't had the pleasure of working with one yet, but
Linux has supported them for at least a couple years.

>> Sincerely,
>>
>> Ron
>>
> --
> David Tomaschik, RHCE, LPIC-1

Greg