src@scuzzy.in-berlin.de (Heiko Blume) (11/05/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Note that the gap should be dependent on the *CPU* and ther kernel >speed, not on the drive (for a given rotational speed). The filesystem >gap is there to compensate for interrupt and processing time. sure, but how do i determine a optimal gap for a given system. since i have three different disk drives varying from real-slow to fast this should be very interesting! that is, there are between 32 and 51 sectors/track on those and the drives using zone bit recording have more on the outer tracks. the mkfs man page and the admin guide tell near to nothing about it. -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,f 38400 6919520 ogin:--ogin: nuucp ssword: nuucp [HST,V.42bis]
pcg@cs.aber.ac.uk (Piercarlo Grandi) (11/08/90)
On 5 Nov 90 03:15:47 GMT, src@scuzzy.in-berlin.de (Heiko Blume) said:
src> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> Note that the gap should be dependent on the *CPU* and ther kernel
pcg> speed, not on the drive (for a given rotational speed). The
pcg> filesystem gap is there to compensate for interrupt and processing
pcg> time.
src> sure, but how do i determine a optimal gap for a given system.
src> since i have three different disk drives varying from real-slow to fast
src> this should be very interesting! that is, there are between 32 and 51
src> sectors/track on those and the drives using zone bit recording have
src> more on the outer tracks. the mkfs man page and the admin guide
src> tell near to nothing about it.
This is a real black art... :-(. The number of sectors per track is
irrelevant (excep that you want a gap that is relatively prime). Zone
recording can be ignored by taking the values for the worst case.
What remains is the time taken by the kernel, CPU, controller chain to
field back-to-back sector requests. Not easy to do without powerful
technology.
In practice this will work, even if it is a slow method and requires
dedicating the machine to the tests:
1) While in single user state choose any expendable partition.
2) mkfs it for some value of the gap -- to speed up things don't bother
to create a filesystem as large as the partition. Say that five MB is ok.
3) mount that partition.
4) record the *elapsed* time it takes to write a large file to that
partition. Say two to four MB (larger does not matter -- smaller is too
quick).
5) umount the partition (this is *essential*).
6) remount the partition.
7) record the *elapsed* time it takes to reread that large file.
8) umount the partition
9) choose a different value for the gap and restart at 2).
Look at the graph of times taken to read and write vs. the gap size.
Choose the gap that gives the best times -- it is usually fairly obvious
which one to choose (give read performance priority over write
performance, unless you have specfial reasons).
A bit larger will usually be safer and more portable and will not worsen
performance significantly. A bit smaller will worsen performance
drastically. It usually pays to tune the gap.
--
Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk