Defrag gain? - Microsoft Windows

This is a discussion on Defrag gain? - Microsoft Windows ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Defrag gain?

  1. Defrag gain?

    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?


    thanks, NT


  2. Re: Defrag gain?

    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."


  3. Re: Defrag gain?

    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


  4. Re: Defrag gain?

    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?



  5. Re: Defrag gain?

    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


  6. Re: Defrag gain?

    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.



+ Reply to Thread