> This is the debug output of > #dd if=/dev/da0s1c of=/tmp/data bs=65536 count=3 > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense
The 3 64k blocks you asked for are below. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense So, the blocks are fetched in 64k blocks. Two options: Either the USB stack does not chain the transfers in such a way that the device can run at full performance or otherwise the device chokes on the transfers and forces the chain of transfers to be delayed till the next frame. There is a 'bandwidth reclamation' feature in the NetBSD stack in the UHCI driver of which I do not know whether they made it into the USB stack. An option would be to fetch a timestamp from somewhere (is there a tick counter that counts in HZ?) to see which transfer takes a long time. If there is no other activity transferring 64k should take no more than 64 frames roughly, which 64 msecs. Nick -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED] http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
