sascha wrote: > the test values are not correct. the seeker utility used > the current number of seconds as the seed for rand() and so the > processes used the same random offsets. the number is 10000 > seeks/second on all 16 usb drives when reading from /dev/sd*,
Nice! Is that with 512 byte read between seeks? If not, it's a lot less than 1/10 of high-speed USB performance. If with reads it might improve still if there were more devices. (But each USB can only have 127 including hubs.) The USB interface chips in the memory sticks could be the limiting factor for you. The one transfer per frame limit applies only to interrupt USB transfers, and USB storage devices use either a control/bulk/interrupt protocol, or a bulk-only protocol. I discovered that only floppy drives use the CBI interface. Many bulk transfers can go in one frame if the host controller implements it. One SCSI command transfer and one response transfer is needed per seek. Max 512 bytes data per packet but SCSI protocol overhead means that each data block will always be two data packets (=more overhead). 512 bytes is fairly large data blocks so the overhead could perhaps be an easy tradeoff for the genericness and availability of memory sticks. How many instructions are needed to process each block before the next seek? 10? 100? 1000? Can processing be done in parallel also? > 800 when reading from a 64GB LVM2 logical volume. And then 6000 > when seeking in the files on 3 partially filled LVM2 volumes. The > reason for the last 2 timings is not yet clear to me. Interactions between the different layers combined with scheduling would be my guess. //Peter _______________________________________________ A51 mailing list [email protected] http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
