Re: Interesting speed benchmarks

In message: <45B99A59.6070902_at_freebsd.org>
            Colin Percival <cperciva_at_freebsd.org> writes:
: M. Warner Losh wrote:
: > In message: <45B9895B.9020709_at_freebsd.org>
: >             Colin Percival <cperciva_at_freebsd.org> writes:
: > : M. Warner Losh wrote:
: > : > Firewire does around 40MB/s, while USB 2.0 maxes out at about 12MB/s.
: > : 
: > : I get 25MB/s from my Vantec Nexstar3
: > : USB 2.0 enclosure:
: > : 
: > : http://www.daemonology.net/blog/2006-01-28-vantex-nexstar3.html
: > 
: > Still, 25MB/s is no 40MB/s...
: 
: Sure, but it means that the performance issues aren't simply a global "USB 2.0
: is bad".  What does `diskinfo -c` say about your firewire and USB interfaces?

Actually, I think it does mean exactly that.  At least with our code
base and the hardware I have access to.  I tested another enclosures
on my amd64 laptop running current and my i386 laptop running 6.2R (+
current cardbus) and found similar results.  6.2R on i386 was even
slower, despite the laptop being a 3GHz pentium.  I got similar
results with a cardbus usb2.0 card as I did with the built-in usb 2.0
ports.  diskinfo -c tells me that usb is 3 times slower per block, and
has a 6 times higher command overhead.

Firewire is faster than local ata, but has a 20% higher command
overhead.

usb:
I/O command overhead:
        time to read 10MB block      0.971377 sec       =    0.047 msec/sector
        time to read 20480 sectors  15.577325 sec       =    0.761 msec/sector
        calculated command overhead                     =    0.713 msec/sector

firewire:
I/O command overhead:
        time to read 10MB block      0.299125 sec       =    0.015 msec/sector
        time to read 20480 sectors   2.804367 sec       =    0.137 msec/sector
        calculated command overhead                     =    0.122 msec/sector

ata: (this is a different disk)
ad0
I/O command overhead:
        time to read 10MB block      0.346256 sec       =    0.017 msec/sector
        time to read 20480 sectors   2.249805 sec       =    0.110 msec/sector
        calculated command overhead                     =    0.093 msec/sector

usb 2.0 shouldn't be this slow, and I think it points to our usb code
being poor at something that's introducing a huge overhead into
commands, as well as creating greater overhead on long transfers.  It
has been suggested that the limited scatter gather in the usb code
might be causing some of the problems.

I haven't tested the Hans Petter Selasky usb stack to see if it is any
better.  It appears there's no scatter gather there, so that might
make the numbers even worse.  But if the command queueing is better,
then it might make up for it.

Warner