Skip site navigation (1)Skip section navigation (2)
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>