This is a discussion on Re: Kernel panic when copying data to umass device (USB4BSD) -problem found - FreeBSD ; On Fri, Nov 07, 2008 at 06:11:26PM +0100, Hans Petter Selasky wrote: > On Friday 07 November 2008, Jeremy Chadwick wrote: > > Not sure if this is caused by problems with USB4BSD or not, as I can > > ...
On Fri, Nov 07, 2008 at 06:11:26PM +0100, Hans Petter Selasky wrote:
> On Friday 07 November 2008, Jeremy Chadwick wrote:
> > Not sure if this is caused by problems with USB4BSD or not, as I can
> > reproduce it on RELENG_7 (but there, the kernel does not panic; it just
> > "wedges" in a loop/thread somewhere; SSH sessions remain up, but
> > commands running stop; hitting Ctrl-T shows them in all sorts of
> > different states, but the states never change; hitting Ctrl-Alt-Esc does
> > in fact drop me to db>).
> Hi Jeremy,
> I've reproduced the issue with some mods to the usb2_busdma.c on 32-bit
> arcitecture and have made a fix for this problem.
> Try the following patch and re-test! Some mem-stick benchmarks would be
> nice ...
> My private SVN also has this patch in addition to P4.
To answer your question in your other mail: yes, this is on an amd64
machine with 4GB of RAM installed.
With the patch to usb2_busdma applied, the problem is fixed! Thank you
very, very much.
As far as benchmarks: I'll keep it simple and try different block sizes.
Numbers are compared against a Windows XP machine using the ATTO
Benchmarking tool (which uses direct I/O read/writes, not filesystem
- Testing done against SanDisk Cruzer Micro 8GB (SDCZ6-8192RB)
- USB 2.0 bus used exclusively on both FreeBSD and Windows
- Write caching disabled for USB drives on Windows XP
- MD5 tests done against 7.1-BETA2-amd64-disc1.iso (573087744 bytes)
- MD5 checksums matched source -- no corruption found on Windows or
- ATTO Disk Benchmark v2.34
- ATTO configuration: Direct I/O, "Neither" type selected (vs.
queued/overlapped I/O); data length size = 512MB
- All FreeBSD tests done with HPS's busdma patches applied
- dd read command: dd if=/dev/zero of=/dev/da0 bs=
- dd write command: dd if=/dev/da0 of=/dev/null bs=
- md5 command: time md5 7.1-BETA2-amd64-disc1.iso
- FreeBSD filesystem: UFS1 (16KB blocks), using da0s1 directly
- Windows filesystem: FAT32 (4KB blocks)
Windows ATTO (4KB) 6.87MB/s 1.25MB/s
Windows ATTO (8KB) 11.32MB/s 2.38MB/s
Windows ATTO (16KB) 17.65MB/s 3.61MB/s
Windows ATTO (32KB) 24.24MB/s 4.06MB/s
Windows ATTO (64KB) 29.30MB/s 8.17MB/s
Windows ATTO (128KB) 29.49MB/s 7.74MB/s
Windows md5 2.38 sec n/a
USB4BSD dd (4KB) 6.72MB/s 1.55MB/s **
USB4BSD dd (8KB) 12.32MB/s 2.44MB/s
USB4BSD dd (16KB) 18.45MB/s 3.59MB/s
USB4BSD dd (32KB) 23.88MB/s 4.24MB/s
USB4BSD dd (64KB) 29.32MB/s 8.90MB/s **
USB4BSD dd (128KB) 29.58MB/s 9.00MB/s **
FreeBSD md5 2.51 sec n/a
** Write speed gradually increased as transfer took place, topping
out at the value shown; there was occasionally some variance
in the transfer speed, so it wasn't a pure linear ramp-up.
Points of interest:
- FreeBSD and Windows have about equal read performance, but FreeBSD
has slightly higher write performance
- Mysterious "gradually increasing speed" with some block sizes
- Jump in write performance with 64KB blocks (firmware optimisation?)
- Slower write performance on Windows with 128KB blocks (I thought I
was going crazy, but I tested this numerous times)
To be brutally honest, I was expecting FreeBSD to perform badly during
both read and write operations -- I was delightfully surprised to see
the above. :-)
I have a newer USB flash disk (SanDisk Cruzer Titanium 8GB) arriving
early next week, so I can try that one out for comparison. SanDisk is
known for tinkering with r/w optimisations in their firmwares.
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"