The way flash drives are handled is quite interesting. You have these layers: Computer-->FAT filesystem driver-->scsi driver-->usb host stack-->usb device stack-->scsi emulation-->buffering-->wear leveling-->NAND flash The computer sees the drive as a scsi drive, a generic block device. So the first block is the boot block, partition, FAT, etc just as with a hard drive. While the intelligent FAT driver would cache the directory and file node information on the flash drive, any changes have to be written as soon as they're made in case the drive is detached unexpectedly, so a lot of unnecessary writes take place while writing a lot of little files, and in some cases one big file. A Fat driver may instead re-read some of the directory nodes each time a new file is placed on the drive, which would considerably slow transfer. All USB drives have some amount of memory on them to buffer the incoming data. It could also be that the better drive has more RAM, or merely a more efficient algorithm to handle the USB transfer to memory buffering. Lastly, due to the flash wear leveling must be used. The cheaper drive may implement a poor leveling scheme. There are lots of ways this could slow things down for long transfers. -Adam On 4/9/07, Dr Skip wrote: > I just finished some informal testing of several jump drives, and it > raised some questions. Perhaps someone here can explain this... > > I tested 2 drives on opposite ends of the advertised speed spectrum - > one said 30MB/s read, 20 MB/s write (assuming the PC can do that) and > was expensive, and the other was a 2 GB unit store brand for $15. No > speed rating and the absolute cheapest I could find. Available by the > handful in a barrel! Both were mounted in the same port on the same PC, > with write caching turned off. > > With a read/seek/write test utility, they both showed 8.5MB/s writes for > 5MB worth of data. This may be a limitation of the speed of the host PC, > but not bad. > > An extended, 2GB write, slowed to 1MB/s on the first drive near the end, > while the cheap one dropped to 200kB/s toward the end. The fast one took > about 15-20 minutes to fill, the second took almost 2 hours. The first > is reasonable to use real time, the second isn't. > > Considering there is no physical seek time, what would cause the speeds > to drop so much over the full transfer? Why can't the speed be maintained? > > BTW, in comparison with a real hard drive, the port itself doesn't seem > to slow down and the real drive maintains transfer rate, so that should > rule out any PC buffering problem, at least to this big of a degree. > > Any ideas? > > -Skip > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Moving in southeast Michigan? Buy my house: http://ubasics.com/house/ Interested in electronics? Check out the projects at http://ubasics.com Building your own house? Check out http://ubasics.com/home/ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist