Why not find out empirically? Boot the machine and time how long it
takes to read some large file into memory (one that isn't touched during
startup; it shouldn't be hard to bang up a quickie C program to do this)
and then defrag, reboot, and time it again. Compare the two times.

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."

Twisted One wrote:
> Why not find out empirically? Boot the machine and time how

A boot up involves too many vairables, and doesnt tell me the max, min
or typical expected gain. One case with other variables mixed in doesnt
tell me any of those figures.

NT

bigcat@meeow.co.uk wrote:
> Hi
>
>
> We all know defrag makes faster, but I could do with working out how
> much faster it can make NTFS file reads. I need to calculate it rather
> than guesstimate, but dont really know how to do it, as I dont know
> quite how the various bits are laid out on the platter, nor what the
> head accesses when.
>
> I've googled and googled, and none of the hits would even venture a
> guess as to how much improvement.
>
> Anyone know where I should get started on this?

Well I would say that first you need a programme that tells you exactly
what things are where on the disk. However, even knowing that I'm not
sure such a calculation would be possible. Say you have a programme at
the beginning of the disk, so you calcualte access and read time and say
to yourself 'it will therefore take x seconds'. But what happens if this
programme calls on various DLL's stuck anywhere else on the disk, you'd
have to know what they are and where they are too. And before your
defrag, how are you going measure the time taken and so the possible
gain, other than testing all of the programmes one by one?

John of Aix wrote:
> bigcat@meeow.co.uk wrote:
> > Hi
> >
> >
> > We all know defrag makes faster, but I could do with working out
how
> > much faster it can make NTFS file reads. I need to calculate it
rather
> > than guesstimate, but dont really know how to do it, as I dont know
> > quite how the various bits are laid out on the platter, nor what
the
> > head accesses when.
> >
> > I've googled and googled, and none of the hits would even venture a
> > guess as to how much improvement.
> >
> > Anyone know where I should get started on this?
>
> Well I would say that first you need a programme that tells you
exactly
> what things are where on the disk.

I could take a hypothetical baddish but realistic case, with maybe 20
pieces of file spread over 10 locations.


> However, even knowing that I'm not
> sure such a calculation would be possible. Say you have a programme
at
> the beginning of the disk, so you calcualte access and read time and
say
> to yourself 'it will therefore take x seconds'.

If I knew read, access and settle times, and revolution latency, and
knew where the head went in what order, since it has to read the FAT as
well, then I could. Oh, and how the buffering affects it. But I dont
know all those, hence the problem.


> But what happens if this
> programme calls on various DLL's stuck anywhere else on the disk,
you'd
> have to know what they are and where they are too.

Ideally, but I can simply calculate the gain in reading one file, that
would be adequate for now.


> And before your
> defrag, how are you going measure the time taken and so the possible
> gain, other than testing all of the programmes one by one?

A clearly explained scenario would do, so everyone knows under what
conditions the stated gains would be achieved.

The prime blockage is I dont know the movement pattern of the head, as
its not only reading the file pieces but also the FAT.


thanks, NT

bigcat@meeow.co.uk wrote:

> The prime blockage is I dont know the movement pattern of the head, as
> its not only reading the file pieces but also the FAT.

Does it read both at the same time (go backwards and forwards I mean)?
The FAT is at the beginning of the disk and I would have thought, though
I don't know, that it would read the addresses of the various bits of
file in one go and then go and get them.

As for the various technical specs, some can be found, access time,
latency etc, they are the sort of things one sees in good reviews of
hardware. However 'access time means what' 8ms to start looking, 8ms to
get to the first piece of data, whiochever end of the disk it is?

You'll be dealing in nano seconds I expect rather than milliseconds.
It's an interesting problem but a complex one as you show. I'm afraid I
can't help you on the deep technical stuff but as a fellow curious
person, I wish you luck.