Re: Advice Please Re: Hard Drive Speeds Relative to Partition Size

The message <N5cgagBReviJFw8D@xxxxxxxxxxxxx>
from Mike Tomlinson <mike@xxxxxxxxxxxxx> contains these words:

In article <3130303037373036498ADC6070@xxxxxxxxxxxxxxxx>, Johnny B Good
<jcs.computers***@xxxxxxxxxxxxxxxx> writes

Some very interesting comments in this thread.

You don't, necessarily have to quadruple the arial density

areal

Oops! Silly me, after all, the word root is 'area' (and I do know how
to spell _that_ one ;-) and the word areal is simply area with an L
stuck on the end, Doh!

to achieve a
doubling of sdtr, there are methods of buffering the track reads/writes
on a multiplatter drive to take full advantage of the multiple platter
arrangement.

As areal density increases, the buffer memory on the drive also needs to
increase in order to be able to accommodate a read of an entire
cylinder. And, of course, the outer cylinders store more data than the
inner ones due to zone bit recording.

Yep, I suppose you might need quite a lot of memory to buffer _all_ 6
tracks' worth of the outermost cylinder. How much exactly, I could
barely hazard a guess without extensive googling activity. It just
struck me as being a fairly obvious way to make a multiplicity of
platters "Earn their keep", performance-wise, rather than being merely a
means of raising drive capacity.

I've not looked at any specs but would suspect that it wouldn't be
possible to cache all of, for example, cylinder 0's data in buffer
memory. This would certainly be the case if buffer memory was also
being used to cache data coming from several heads, and/or being used to
cache writes.

Well, this is merely a matter of having a sufficient quantity of cache
ram, how much would be sufficient is another imponderable, best answered
by the drive designer.

Installing the OS to a (relatively) small dedicated partition (say 10
to 15GB for winXP) is a good idea, simply on account it keeps all of
that OS's transient files (not just temporary and log files, but also
those replaced by the interminable windows update process, along with
the uninstall packs each one creates) coralled within the fastest 10 or
15GB partition space on a much larger drive (say 320 to 1000GB) where
they can't mix it with the apps and user data.

Traditionally, it's been good advice to install the OS on a small, fast
drive and to store user data on a second drive (you alluded to this on
another post.) I did this on the PC I'm using now: the OS is on a 74GB
10krpm Raptor and data is on a Hitachi 1TB. Both SATA.

Ideally, a completely seperate drive for the OS/Boot partition (the
same ideal for also giving the pagefile exclusive use of a drive of its
own). Unfortunately, an old (outlived its usefulness) 40GB drive won't
provide any benefit due to its relatively lacklustre performance
compared to today's commodity drives of tenfold and more capacity
typically fitted in a modern build.

It occurred to me recently that the outer cylinders on the 7.2Krpm
Hitachi drive might very well have a higher data transfer rate than the
10Krpm Raptor, and that I might benefit from moving the OS to a
partition of, say, 20GB created at the beginning of the Hitachi drive.

It depends on how much more capacity there is on the Hitachi, compared
to the Raptor, indeed you might be better doing that and placing a fixed
size pagefile at the beginning of a dedicated partition at the start of
the Raptor's drive space.

This would involve a fair bit of shuffling data around and benchmarking,
though, and I can't be arsed. I suspect that the real bottleneck for
both drives may be the interface: they're SATA1.

I doubt whether SATA 1's 1.5Gbps speed would be a limiting factor.

I've heard that winNT can make (intelligent?) use of a pagefile per
physical disk to minimise the issue of head contention. However, I'm not
entirely convinced since, it seems to me that you'd need a "Mystic Meg
Algorithm"(tm)[1] for such a strategy to be truly effective. However, it
won't do any harm to create one in the OS/Boot partition and another on
the second disk (when you have such a second disk ;-).

There's more to it than that. For example, two drives containing
pagefiles on the same IDE (PATA) bus. You then have bus contention to
deal with.

Yes, that was one of the points that came up in the few articles I read
in my googling odyssey ;-)

Also, it's far more efficient to add more memory - it's cheap enough
these days. My advice to anyone whose PC makes frequent use of the
pagefile would be not to create a second pagefile, but to add more
physical memory.

Yet another point well made in those self same articles. I knew this,
but, just the same, even when there _is_ ample memory, you still need
virtual memory in the system to avoid real memory being frittered away
on speculative demands by profligate applications.

[1] Actually, it has just struck me that there is an access algorithm,
which doesn't rely on a "Mystic Meg Algorithm"(tm) that can minimise
head contention when a multi -drive system has equal sized fixed
pagefiles per disk. The operative phrase, here, being "equal sized fixed
pagefiles per disk".

Why do you say the pagefiles would need to be equal-sized to minimise
head contention? Just curious.

I've concluded, from googling, that winNT is nowhere near as clever in
making use of multiple instances of identically sized pagefiles across
different physical disks as mirror copies of each other requiring that
only one of them on an uncontended drive would need to be accessed at
any one time, leaving the mirror copies to be synchronised as and when
contention allowed.

I've seen a few references to winNT being able to make best use of a
set of pagefiles spread across physically seperate disk drives, but no
indication as to how this ideal is realised.

One might be tempted to invest in one of the smaller SSDs, but the
pagefile has no need to be non-volatile and SSDs must have a limited
number of write cycles (even if it's numbered in the millions) which can
surpisingly be used up rather rapidly by pagefile activity.

A better alternative ( for 32 bit OSes) to using disk drives for
virtual memory is to use standard ram to provide virtual memory in the
form of bank switched modules (either in the form of 'virtual memory'
dimm sockets on the MoBo or as PCI or PCIe add in cards).

Intel cpus, starting with the 80386, have had such a virtual memory
addressing mechanism built in to support exactly this method of memory
expansion. Now that gigabyte sized memory modules are so cheap, it's
surprising that we still don't see such memory expansion as standard on
'entry level' MoBos. Memory expansion beyond the 4GB limit seems to be
regarded as being a purely 64 bit feature, but it need not be so
limited.

At the end of the day, virtual memory, provided by disk space as a
'negligable cost' option still provides an essential enhancement to a 32
bit system already maxed out to its ram limit (3 to 4 GB, depending on
the OS and the graphics ram mapping), in that it helps the system better
optimise its ram usage. The basic rule in a multi drive system is to
avoid planting a pagefile on the disk drive containing the OS.

For a general purpose PC, you'd be ill advised to disable virtual
memory, even when the system is well endowed with ram. Although virtual
memory allows you to overload the system to the point of a massive slow
down, the alternative, with no virtual memory, of the system coming to a
grinding halt, is even less desirable.

Most of the 'Bad Press' given to virtual memory, seems to be more down
to user ignorance over what exactly each piece of 'must have' software
is doing with their computer's resources[1] and, as a consequence,
grossly overloading the system (often to the point where system
performance might best be described as "A snail on prosac"). In part,
this is quite often down to them not realising that the system could
benefit considerably from a timely (nay, long overdue) ram upgrade[2].

[1] Microsoft's cockameemee default configuration to "Hide unused icons
in the system tray", effectively wraps the "Clue by Four", that would
otherwise provide a nice strong hint, in cotton wool.

[2] I've had customers bring in E-Machines PCs with a 'Brag ***'
sticker, proudly proclaiming "Windows XP _and_ 128MB ram" (the _and_
emphasised by me), still with the original amount of memory, except it's
made much worse by the on-board graphics claiming 32 MB of what little
there is (leaving the system with only 96MB).

What's worse, is that there's no gain to be made by the on-board
graphics in allowing it any more than is needed for basic 2-D desktop
work and a simple cmos change is all that is needed reduce it to 8MB to
enhance that 96MB by a useful 24MB.

How such customers have managed to put up with a system so slow for the
many years since the SP1 upgrade, let alone the SP2 one, I just can't
imagine. My first thought, on seeing that sticker, was that it was
intended to act as a 'customer filter'. To my mind, it was a coded
message which effectively stated, "Clued up customers need not apply.".

--
Regards, John.

Please remove the "ohggcyht" before replying.
The address has been munged to reject Spam-bots.

.