Date: Fri, 26 Jan 2007 11:25:27 -0500 From: Robert Huff <roberthuff@rcn.com> To: current@freebsd.org Subject: Interesting speed benchmarks Message-ID: <17850.11127.944124.276290@jerusalem.litteratus.org> In-Reply-To: <20070125.192448.-432840241.imp@bsdimp.com> References: <20070125.192448.-432840241.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh writes:
> On a lark, I just got a combo USB/Firewire external disk drive.
> I ran some crude benchmarks, and I was surprised by what I found.
> This is on a fairly stock -current kernel.
>
> Firewire does around 40MB/s, while USB 2.0 maxes out at about 12MB/s.
As long as we're on the subject:
I'm testing a USB-connected external hard drive (PATA-133) as a
replacement for SCSI-I/DLT in a dump-driven backup arrangement for a
P4/2.25 ghz+80 mbyte/sec SCSI box.
Hardware specs as reported by the boot probe are appended.
"diskinfo -tc" returns:
512 # sectorsize
100256284672 # mediasize in bytes (93G)
195813056 # mediasize in sectors
12188 # Cylinders according to firmware.
255 # Heads according to firmware.
63 # Sectors according to firmware.
I/O command overhead:
time to read 10MB block 0.590932 sec = 0.029 msec/sector
time to read 20480 sectors 16.156980 sec = 0.789 msec/sector
calculated command overhead = 0.760 msec/sector
Seek times:
Full stroke: 250 iter in 5.276618 sec = 21.106 msec
Half stroke: 250 iter in 4.144696 sec = 16.579 msec
Quarter stroke: 500 iter in 6.929293 sec = 13.859 msec
Short forward: 400 iter in 2.341049 sec = 5.853 msec
Short backward: 400 iter in 3.632142 sec = 9.080 msec
Seq outer: 2048 iter in 1.645352 sec = 0.803 msec
Seq inner: 2048 iter in 1.598203 sec = 0.780 msec
Transfer rates:
outside: 102400 kbytes in 5.938111 sec = 17245 kbytes/sec
middle: 102400 kbytes in 6.076508 sec = 16852 kbytes/sec
inside: 102400 kbytes in 5.807954 sec = 17631 kbytes/sec
Performance, so far, has been better than the old set-up but far
less than thrilling and I'd like to understand why. Dump, using
these options:
$DUMP_LEVEL -D $DUMPDATES_FILE -Lau -f
gets me 2 +/- 0.2 mbytes/sec.
Is this a reasonable value? (I.e. is dump the limiting
factor?) Do I need to reconfigure something, or is my hardware just
lame?
I'm not expecting to get the full 40 mbyte/sec of USB 2.0 spec;
20 or even 10 would be fine. But 2? Ouch.
Respectfully,
Robert Huff
jerusalem kernel: ehci0: <ALi M5239 USB 2.0 controller> mem
0xf0000000-0xf0000 0ff irq 15 at device 10.3 on pci0
jerusalem kernel: ehci0: [GIANT-LOCKED]
jerusalem kernel: usb3: <ALi M5239 USB 2.0 controller> on ehci0
huff@jerusalem>>
jerusalem kernel: usb3: EHCI version 1.0
jerusalem kernel: usb3: companion controller, 2 ports each: usb2
jerusalem kernel: usb3: <ALi M5239 USB 2.0 controller> on ehci0
jerusalem kernel: usb3: USB revision 2.0
jerusalem kernel: uhub3: <AcerLabs EHCI root hub, class 9/0, rev
2.00/1.00, addr 1> on usb3
jerusalem kernel: uhub3: 6 ports with 6 removable, self powered
jerusalem kernel: umass0: <Addonics Addonics USB Drive, class 0/0, rev 2.00/0.15, addr 2> on uhub3
jerusalem kernel: (probe15:umass-sim0:0:0:0): Uninitialized Transport 5:0?
jerusalem kernel: da2 at umass-sim0 bus 0 target 0 lun 0
jerusalem kernel: da2: <Maxtor 6 L100P0 0000> Fixed Direct Acces
s SCSI-0 device
jerusalem kernel: da2: 40.000MB/s transfers
jerusalem kernel: da2: 95611MB (195813072 512 byte sectors: 255H
63S/T 12188C)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17850.11127.944124.276290>