https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244356
--- Comment #88 from Olivier Certner <olivier.free...@free.fr> --- (In reply to Gary Jennejohn from comment #87) Thanks for the tests. I expected that a pre-fill with 0xFF would not change the result, and you seem to confirm that. Also, you're seeing better performance under Linux, which may be due to the transaction size used (1MiB there), but it could be that USB 2 is saturating on FreeBSD and that could be in fact the dominant effect. Did not have any XHCI problem on my side with any of the USB 3 sticks. I don't think I made a thorough raw `dd` test under Linux, only a `dd` to exFAT, and I didn't see much difference (was mentioned in comment #51; FS influence would be low, since all writes were clustered, with only 128KiB transactions really issued to the stick), at least I don't remember noticing the ~20% difference you are reporting. I will be doing some raw `dd` testing under Linux (and maybe MacOS) in order to confirm this with my sticks (SD_128G at least). There are several systems involved in the overall stick performance. By not testing the FS, you indeed focus on the hardware part, but I would argue that there is a possibility that it is not all of it. By putting the FS into the equation, I'm not only trying to analyze what happens in real world usage, which Sébastien's initial report was implicitly about I think, and which matches my use case as well, but also the influence of controller's performance at issuing read/write (or read/erasure) sequences and how it caches these and full flash block accesses. UFS indeed uses fragments, and thus issues smaller transactions than a full FS block, although the effect is mitigated somehow by clustering: This is what I think you call FS overhead. I'm just trying to see if I can obtain better performance by arranging to have this read-write process to happen in software (through GEOM_CACHE), which will indeed tell me if there is some controller inefficiency or caching problem in the real-world equation, and if it's the case I'll get better performance with this setup (while somehow conserving space, but this is not really important to me at this point). I've been contemplating for a while to go down another, maybe simpler, route to raise the minimum transaction size: Getting rid of fragments in UFS. It seems it is possible to do it by setting the fragment size to the block size at FS creation. So this is the test I'm performing right now: See if performance is much improved with only 32k blocks (and whether the minimum transaction size actually jumps to 32k). -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
