On Donnerstag, 24. März 2011 Arnd Bergmann wrote:
On Thursday 24 March 2011, Michael Monnerie wrote:
We could speak german, I guess?
Yes, but I'd prefer to keep the discussion on the mailing list if interesting results come up.
OK, so I guess I'll anwer to the list too.
and for some reason you cannot use real-time scheduling, which makes the results less accurate.
This is openSUSE 11.4 with kernel 2.6.37.1-1.2-desktop I could retry with a standard 2.6.37.4 if that would help.
Be careful here. The original FAT layout is typically made specifically for this stick, so it's probably a good idea to make a backup of the first few blocks.
Too late. It's NTFS since a long time, I converted it as FAT32 only stores files of 2GB, which is too small for my files. I use this stick to copy DVDs on it, then stick it in the TV and look from there. No DVD player available.
Right, nothing to see here yet. It only shows the first 8 MB, so if the spike is every 8 MB, it won't show up here. Use --scatter-order=12 to show more. Also, the jitter from the USB protocol may hide some details, which might get better with a larger --count= value, but that would make the test run much longer.
It's probably good enough to assume that the size is actually 8 MB or 4 MB, and keep going from there.
OK
I've committed some updates now that might help make the --open-au results a bit clearer, and faster.
What I would recommend now is to update to the latest git version (just uploaded), and then try increasing numbers of --open-au-nr= with 4 MB erasesize, until you hit the cutoff. Try the same with --random, for the last fast one and the first slow one:
OK I did, but with your new version I get seriously different results than before: # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=5 sched_setscheduler: Operation not permitted 4MiB 7.66M/s 2MiB 3.42M/s 1MiB 8.15M/s 512KiB 7.99M/s 256KiB 381K/s 128KiB 189K/s 64KiB 7.6M/s 32KiB 6.75M/s 16KiB 46.8K/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=4 sched_setscheduler: Operation not permitted 4MiB 7.6M/s 2MiB 6.75M/s 1MiB 6.32M/s 512KiB 8.42M/s 256KiB 5.97M/s 128KiB 4.17M/s 64KiB 6.07M/s 32KiB 7.13M/s 16KiB 4.67M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=3 sched_setscheduler: Operation not permitted 4MiB 8.94M/s 2MiB 6.95M/s 1MiB 7.02M/s 512KiB 6.91M/s 256KiB 6.82M/s 128KiB 5.37M/s 64KiB 6.96M/s 32KiB 5.92M/s 16KiB 4.4M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=2 sched_setscheduler: Operation not permitted 4MiB 10.5M/s 2MiB 6.91M/s 1MiB 7.03M/s 512KiB 6.92M/s 256KiB 6.75M/s 128KiB 5.02M/s 64KiB 6.91M/s 32KiB 6.01M/s 16KiB 4.68M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=1 sched_setscheduler: Operation not permitted 4MiB 23.5M/s 2MiB 6.73M/s 1MiB 7.05M/s 512KiB 6.93M/s 256KiB 6.73M/s 128KiB 4.19M/s 64KiB 6.71M/s 32KiB 6.08M/s 16KiB 4.6M/s
=> N is the number of 4 MB blocks that can not be handled
So I guess 5 would be my number now?
./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au -nr=N --random => Verify that the (N-1) --random case is still fast
OK, looks good: # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=4 --random sched_setscheduler: Operation not permitted 4MiB 8.28M/s 2MiB 6.98M/s 1MiB 7.04M/s 512KiB 6.99M/s 256KiB 6.82M/s 128KiB 5.59M/s 64KiB 7.01M/s 32KiB 4.42M/s 16KiB 4.69M/s # ./flashbench -O --erasesize=$[4 * 1024 * 1024] /dev/sde --open-au- nr=5 --random sched_setscheduler: Operation not permitted 4MiB 7.17M/s 2MiB 5.17M/s 1MiB 6.77M/s 512KiB 3.66M/s 256KiB 746K/s 128KiB 373K/s 64KiB 647K/s 32KiB 328K/s 16KiB 93.3K/s
./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=((N-1)/2) --random ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=(N-1) --random
I guess the last should have been open-au-nr=(N)? Anyway, I didn't run the last test, as already the second shows drastic reduction:
# ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=2 --random sched_setscheduler: Operation not permitted 8MiB 14.4M/s 4MiB 7.56M/s 2MiB 6.7M/s 1MiB 6.97M/s 512KiB 6.86M/s 256KiB 6.67M/s 128KiB 4.53M/s 64KiB 6.61M/s 32KiB 5.8M/s 16KiB 4.62M/s # ./flashbench -O --erasesize=$[8 * 1024 * 1024] /dev/sde --open-au- nr=4 --random sched_setscheduler: Operation not permitted 8MiB 11.2M/s 4MiB 9.27M/s 2MiB 3.42M/s 1MiB 5.18M/s 512KiB 2.76M/s 256KiB 747K/s 128KiB 373K/s 64KiB 344K/s (cancelled here, confirmed it's slow)
So would it be right to guess it's an 8M erasesize with 2 au? If so, what should an ideal partition table look like? Is NTFS tuneable for this stick? I've used a block size of 64k to keep performance up. Too bad my TV doesn't understand XFS or similar FS.