Harddisks: Seek, Read, Write, Read, Write, Slow ?

Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

Hi,

Take these 3 concepts and then look at the implementation/performance:

( 3 Concepts for reading/writing with harddisks )

Concept 1:

Seek, Read, Read, Read, Read, Read, Etc

Results: FAST

Concept 2:

Seek, Write, Write, Write, Write, Write, Etc

Results: FAST

Concept 3:

Seek, Read, Write, Read, Write, Read, Write,

Results: SLOW ???

The pseudo code is like:

Seek( 0 ); // offset 0

For I:=0 to FileBlocks-1 do // number of 4KB blocks in file.
begin
if Random(2) = 0 then
Read( 4 KB )
Else
Write( 4 KB );
end;

The original concept is:

Do a seek once.

Then read or write a block of data. The head is automatically forwarded to
the next block. So no extra seek is needed.

For concept 1 and concept 2 this works just fine and gives good performance.

However concept 3 has very bad performance.

Is this a software issue ? ( Windows XP )

Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
can't work together like this and an extra seek is needed ? )

Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )

Bye,
Skybuck.
40 answers Last reply
More about harddisks seek read write read write slow
  1. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    On Wed, 14 Jul 2004 17:53:52 +0200, "Skybuck Flying"
    <nospam@hotmail.com> wrote:

    >Hi,
    >
    >Take these 3 concepts and then look at the implementation/performance:
    >
    >( 3 Concepts for reading/writing with harddisks )
    >
    >Concept 1:
    >
    >Seek, Read, Read, Read, Read, Read, Etc
    >
    >Results: FAST
    >
    >Concept 2:
    >
    >Seek, Write, Write, Write, Write, Write, Etc
    >
    >Results: FAST
    >
    >Concept 3:
    >
    >Seek, Read, Write, Read, Write, Read, Write,
    >
    >Results: SLOW ???
    >
    >The pseudo code is like:
    >
    >Seek( 0 ); // offset 0
    >
    >For I:=0 to FileBlocks-1 do // number of 4KB blocks in file.
    >begin
    > if Random(2) = 0 then
    > Read( 4 KB )
    > Else
    > Write( 4 KB );
    >end;
    >
    >The original concept is:
    >
    >Do a seek once.
    >
    >Then read or write a block of data. The head is automatically forwarded to
    >the next block. So no extra seek is needed.
    >
    >For concept 1 and concept 2 this works just fine and gives good performance.
    >
    >However concept 3 has very bad performance.
    >
    >Is this a software issue ? ( Windows XP )
    >
    >Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
    >can't work together like this and an extra seek is needed ? )
    >
    >Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )
    >
    >Bye,
    > Skybuck.
    >


    I may not know the answer but feel an important question might be
    "What is very bad performance?", compared to good performance...
    numbers are our friends.

    Could it simply be that you're switching back and forth with data
    flow so the caching (on the drive) isn't effective?
  2. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Actually, what is happening is that the heads on the platter need to
    reconfigure themselves each time you read or write. It is a hardware
    limitation. By reading, the head can stay in the same location, but
    once it is told to write, the head has to position itself to change the
    magnetism of the sector of the platter it is on. Then once you request
    to read again, the head has to move again. It is the same as seek time
    when you have two files on different partitions it is going to take
    longer to find those files than if they were right next to each other.

    Nathan McNulty

    kony wrote:

    > On Wed, 14 Jul 2004 17:53:52 +0200, "Skybuck Flying"
    > <nospam@hotmail.com> wrote:
    >
    >
    >>Hi,
    >>
    >>Take these 3 concepts and then look at the implementation/performance:
    >>
    >>( 3 Concepts for reading/writing with harddisks )
    >>
    >>Concept 1:
    >>
    >>Seek, Read, Read, Read, Read, Read, Etc
    >>
    >>Results: FAST
    >>
    >>Concept 2:
    >>
    >>Seek, Write, Write, Write, Write, Write, Etc
    >>
    >>Results: FAST
    >>
    >>Concept 3:
    >>
    >>Seek, Read, Write, Read, Write, Read, Write,
    >>
    >>Results: SLOW ???
    >>
    >>The pseudo code is like:
    >>
    >>Seek( 0 ); // offset 0
    >>
    >>For I:=0 to FileBlocks-1 do // number of 4KB blocks in file.
    >>begin
    >> if Random(2) = 0 then
    >> Read( 4 KB )
    >> Else
    >> Write( 4 KB );
    >>end;
    >>
    >>The original concept is:
    >>
    >>Do a seek once.
    >>
    >>Then read or write a block of data. The head is automatically forwarded to
    >>the next block. So no extra seek is needed.
    >>
    >>For concept 1 and concept 2 this works just fine and gives good performance.
    >>
    >>However concept 3 has very bad performance.
    >>
    >>Is this a software issue ? ( Windows XP )
    >>
    >>Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
    >>can't work together like this and an extra seek is needed ? )
    >>
    >>Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )
    >>
    >>Bye,
    >> Skybuck.
    >>
    >
    >
    >
    > I may not know the answer but feel an important question might be
    > "What is very bad performance?", compared to good performance...
    > numbers are our friends.
    >
    > Could it simply be that you're switching back and forth with data
    > flow so the caching (on the drive) isn't effective?
  3. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd3kli$4k5$1@news5.tilbu1.nb.home.nl...

    > Do a seek once.

    Seeks to a particular track and NOT a particular block of data.

    > Then read or write a block of data.

    When the head settles and certain switching times have passed and the
    appropriate data block rotates under the head.

    > The head is automatically forwarded to
    > the next block.

    There no kind of automatic "forwarding". The disk however does tend to keep
    spinning at a constant angular velocity. Often the next data the head
    encounters is the next data in the file if it's a sequential file.

    > So no extra seek is needed.

    Huh?

    > For concept 1 and concept 2 this works just fine and gives good
    performance.
    >
    > However concept 3 has very bad performance.

    Huh, it's just how disks work.

    > Is this a software issue ? ( Windows XP )

    WHAT?

    > Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
    > can't work together like this and an extra seek is needed ? )

    There are NOT two heads but just a single head per disk surface. That head
    both reads an writes but can do only one or the other at a given instant.
    There is a finite switch time between read and write mode. During that
    switch time the disk continues to spin.

    > Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )

    What issue?
  4. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nathan McNulty" <525676@betaweb.com> wrote in message
    news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    > Actually, what is happening is that the heads on the platter need to
    > reconfigure themselves each time you read or write.

    Not really.

    > It is a hardware
    > limitation.

    What limitation is that exactly?

    > By reading, the head can stay in the same location, but
    > once it is told to write, the head has to position itself to change the
    > magnetism of the sector of the platter it is on.

    That's false.

    > Then once you request
    > to read again, the head has to move again.

    Not necessarily.
  5. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    1. Yes really. You cannot read and write at the same time. The command
    has to be either read or write.

    2. Hardware limitation that it cannot read and write at the same time.

    3. From what I have seen on my old harddrives I have taken apart and
    what I have read, there is a tip on the head that prevents the magnetic
    part from affecting nearby sectors. I was under the impression these do
    not always stay in the same position but are required to move each time
    a write process is initiated.

    4. Again, the tips would have to move back to their resting position.
    Maybe this is just old hardware (especially since my books are all very
    old) or maybe I've read it wrong, but that was my understanding of how
    that part worked.

    Nathan McNulty

    Ron Reaugh wrote:

    > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    >
    >>Actually, what is happening is that the heads on the platter need to
    >>reconfigure themselves each time you read or write.
    >
    >
    > Not really.
    >
    >
    >>It is a hardware
    >>limitation.
    >
    >
    > What limitation is that exactly?
    >
    >
    >> By reading, the head can stay in the same location, but
    >>once it is told to write, the head has to position itself to change the
    >>magnetism of the sector of the platter it is on.
    >
    >
    > That's false.
    >
    >
    >> Then once you request
    >>to read again, the head has to move again.
    >
    >
    > Not necessarily.
    >
    >
  6. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nathan McNulty" <525676@betaweb.com> wrote in message
    news:%23G%23AUyeaEHA.3524@TK2MSFTNGP12.phx.gbl...
    > 1. Yes really. You cannot read and write at the same time. The command
    > has to be either read or write.
    >
    > 2. Hardware limitation that it cannot read and write at the same time.

    Not really, a logical/design fact.

    > 3. From what I have seen on my old harddrives I have taken apart and
    > what I have read, there is a tip on the head that prevents the magnetic
    > part from affecting nearby sectors. I was under the impression these do
    > not always stay in the same position but are required to move each time
    > a write process is initiated.

    Not true for anything recent.

    > 4. Again, the tips would have to move back to their resting position.

    No tips.

    > Ron Reaugh wrote:
    >
    > > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > > news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    > >
    > >>Actually, what is happening is that the heads on the platter need to
    > >>reconfigure themselves each time you read or write.
    > >
    > >
    > > Not really.
    > >
    > >
    > >>It is a hardware
    > >>limitation.
    > >
    > >
    > > What limitation is that exactly?
    > >
    > >
    > >> By reading, the head can stay in the same location, but
    > >>once it is told to write, the head has to position itself to change the
    > >>magnetism of the sector of the platter it is on.
    > >
    > >
    > > That's false.
    > >
    > >
    > >> Then once you request
    > >>to read again, the head has to move again.
    > >
    > >
    > > Not necessarily.
    > >
    > >
  7. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nathan McNulty" <525676@betaweb.com> wrote in message
    news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    > Actually, what is happening is that the heads on the platter need to
    > reconfigure themselves each time you read or write. It is a hardware
    > limitation. By reading, the head can stay in the same location, but
    > once it is told to write, the head has to position itself to change the
    > magnetism of the sector of the platter it is on. Then once you request
    > to read again, the head has to move again. It is the same as seek time
    > when you have two files on different partitions it is going to take
    > longer to find those files than if they were right next to each other.

    Yes, a hardware limitation seems to make more sense.

    I changed the code to this pseudo code, to illiminate the randomness and
    make it regular switching:

    if BooleanRead then
    begin
    Read 4 KB
    BooleanRead := false;
    end else
    begin
    Write 4 KB
    BooleanRead := true;
    end;

    This will cause regular switching like:

    Seek, Read, Write, Read, Write, Read, Write, etc

    Instead of randomness like:

    Seek, Read, Read, Write, Read, Write, Write, etc

    My harddisk performs as follows for these 3 concepts (with the updated
    concept 3 )

    Concept 1 ( Reading )

    It achieves 8 MByte/Sec to 12 MByte/Sec for reading a 36 MB file. ( with 4
    KB block buffer )

    After a few seconds the harddisk led stops burning. The speed increases to
    100 or 180 MByte/Sec.

    This is ofcourse only possible because it's fetched from some RAM I think. I
    am not sure if it is coming from the Harddisk Read Cache or Windows XP file
    cache... or whatever it's called. My guess would be Windows XP's file cache.

    Concept 2 (Writing )

    This test is very fluctating... sometimes 600 Kbyte/sec at worst...
    sometimes a peak to 36 MByte/Sec.

    Mostly it's 2 MByte/Sec with some peaks to 4 MByte/Sec.

    My file system is pretty fragmented though.

    Concept 3 ( Reading / Writing )

    Well this is also pretty weird.

    Sometimes it's 80 KByte/sec to 400 KByte/Sec.

    Now it's 1 to 2 MByte/Sec

    I suspect the small file size of only 36 MByte has to do with that.

    So I will now test again on 100 MB file, to prevent any caching or to detect
    it... possibly memory jump in task manager.

    Concept 1 (Reading)

    This time the speed is pretty constant. 8 MByte/Sec... with some lower peaks
    to 6MByte/Sec and a few high peaks to 9 MByte/Sec.

    But no more caching apperently in windows xp...

    8 MByte/Sec or any multiple of MByte/Sec is what I would call good
    performance.

    This is in the light of my file transfer tool and 100 Megabit network cards
    which are common nowadays.

    100 Megabit is roughly 8 MByte/Sec or so... give or take a few...

    Not that my file transfer tool reaches these speeds just... it has problems
    with harddisk ;) =D

    One more artificact of my benchmark programs after stop the test it takes a
    while stop... probably because of the for loop... no big deal.

    Concept 2 ( Writing )

    Well this time writing was a lot thougher... 1 MByte/Sec to max 2
    MByte/Sec... the program is less responsive than the read program... but
    code is almost the same... and multi threaded. But not using async stuff...
    just sync stuff ;) At least I think so ;) However async stuff aint that
    great either :)
    Since I wrote a program to do async stuff as well. So never mind that :P

    Now comes the big test, since it's getting late :P

    Concept 3 (Reading and Writing, with regular switches )

    Oh my... now that's what I call bad performance !

    The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    Kbyte/sec.

    Max was 200 KByte/sec.

    So it seems switching from read to write to read to write requires extra
    seeking etc...

    Maximum seek time for my HD and most HD's is 20 milliseconds.

    Average Seek time is around 10 to 15 milliseconds.

    So that means 50 seeks per sec for worst case.

    The buffer is 4 KB...

    50x4 KB = 200 KB.

    That's pretty amazing... the harddisk performs even worse than the worst
    case scenerio.

    I did not expect that. :D

    Well I found this document about my harddisk...

    It contains some information about seek times and such.

    However the term 'Head Switch' means something else in this case.

    It means moving from track to next track or something I think...

    As far as I could tell there is no mentioning of latency from read to write
    to read to write etc...

    Or maybe I missed it... Anyway time for me to call it a day.

    http://www.hitachigst.com/tech/techlib.nsf/techdocs/85256AB8006A31E587256A7A006F9551/$file/dtta_sp.pdf

    Bye,
    Skybuck.


    This clearly indicates the file


    With the new code my harddisk now performs in the range of:

    80 KByte / Sec to 400 KByte / Sec which I call poor/bad performance.

    Concept 1 ( The Reading ) can achieve easily 8 MByte/Sec to 12 MByte/Sec.


    After a few seconds on a 36 MB file it achieves 180 MByte/Sec this is
    probably from Windows XP cache or maybe Harddisk Cache ?

    The harddisk is completely silent. I can't imagina th


    can achieve 1 MByte / Sec up to 12 MByte/Sec


    >
    > Nathan McNulty
    >
    > kony wrote:
    >
    > > On Wed, 14 Jul 2004 17:53:52 +0200, "Skybuck Flying"
    > > <nospam@hotmail.com> wrote:
    > >
    > >
    > >>Hi,
    > >>
    > >>Take these 3 concepts and then look at the implementation/performance:
    > >>
    > >>( 3 Concepts for reading/writing with harddisks )
    > >>
    > >>Concept 1:
    > >>
    > >>Seek, Read, Read, Read, Read, Read, Etc
    > >>
    > >>Results: FAST
    > >>
    > >>Concept 2:
    > >>
    > >>Seek, Write, Write, Write, Write, Write, Etc
    > >>
    > >>Results: FAST
    > >>
    > >>Concept 3:
    > >>
    > >>Seek, Read, Write, Read, Write, Read, Write,
    > >>
    > >>Results: SLOW ???
    > >>
    > >>The pseudo code is like:
    > >>
    > >>Seek( 0 ); // offset 0
    > >>
    > >>For I:=0 to FileBlocks-1 do // number of 4KB blocks in file.
    > >>begin
    > >> if Random(2) = 0 then
    > >> Read( 4 KB )
    > >> Else
    > >> Write( 4 KB );
    > >>end;
    > >>
    > >>The original concept is:
    > >>
    > >>Do a seek once.
    > >>
    > >>Then read or write a block of data. The head is automatically forwarded
    to
    > >>the next block. So no extra seek is needed.
    > >>
    > >>For concept 1 and concept 2 this works just fine and gives good
    performance.
    > >>
    > >>However concept 3 has very bad performance.
    > >>
    > >>Is this a software issue ? ( Windows XP )
    > >>
    > >>Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
    > >>can't work together like this and an extra seek is needed ? )
    > >>
    > >>Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )
    > >>
    > >>Bye,
    > >> Skybuck.
    > >>
    > >
    > >
    > >
    > > I may not know the answer but feel an important question might be
    > > "What is very bad performance?", compared to good performance...
    > > numbers are our friends.
    > >
    > > Could it simply be that you're switching back and forth with data
    > > flow so the caching (on the drive) isn't effective?
  8. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...

    > Concept 3 (Reading and Writing, with regular switches )
    >
    > Oh my... now that's what I call bad performance !
    >
    > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    > Kbyte/sec.
    >
    > Max was 200 KByte/sec.
    >
    > So it seems switching from read to write to read to write requires extra
    > seeking etc...

    Nope, calculate the theoretical rate for the data group to be transferred
    at the rate of one per revolution. Each time you switch from read to write
    you likely lose the rest of the current disk rotation.

    > Maximum seek time for my HD and most HD's is 20 milliseconds.

    What is the relation of the location of each 4KB block of data? Are they
    sequential in a file? Where is a write located compared to the preceeding
    read?.

    > Average Seek time is around 10 to 15 milliseconds.

    Seeking has to do with moving the head to a different track. Are you doing
    random I/O of these blocks in a big file or to multiple files?

    It sounds like you haven't well thought out or at least described what you
    are doing.
  9. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nathan McNulty" <525676@betaweb.com> wrote in message news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl
    > Actually, what is happening is that the heads on the platter need to
    > reconfigure themselves each time you read or write.

    > It is a hardware limitation.

    > By reading, the head can stay in the same location, but once it is told to
    > write, the head has to position itself to change the magnetism of the
    > sector of the platter it is on.

    And that's why there is a write-to-read recovery (w-r) field in the make
    up of every sector to allow the R/W channel to switch and the servo
    to adjust the write-to-read element offset to center the write head .
    http://www.hgst.com/hdd/ipl/oem/tech/noid.htm

    > Then once you request to read again, the head has to move again.

    That's actually automatic as the drive reads every servo field and
    every sector to keep track of where it's at.

    > It is the same as seek time

    Nonsense.

    > when you have two files on different partitions it is going to take
    > longer to find those files than if they were right next to each other.

    Nope. And read-ahead cache will have the contents anyway.

    >
    > Nathan McNulty
    >
    > kony wrote:
    >
    > > On Wed, 14 Jul 2004 17:53:52 +0200, "Skybuck Flying" <nospam@hotmail.com> wrote:
    > >
    > >
    > > > Hi,
    > > >
    > > > Take these 3 concepts and then look at the implementation/performance:

    [snip]
  10. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:YdhJc.94726$OB3.56275@bgtnsc05-news.ops.worldnet.att.net
    > "Skybuck Flying" <nospam@hotmail.com> wrote in message news:cd3kli$4k5$1@news5.tilbu1.nb.home.nl...
    >
    > > Do a seek once.
    >
    > Seeks to a particular track and NOT a particular block of data.

    Nope.

    >
    > > Then read or write a block of data.
    >
    > When the head settles and certain switching times have passed and the
    > appropriate data block rotates under the head.
    >
    > > The head is automatically forwarded to the next block.
    >
    > There no kind of automatic "forwarding". The disk however does tend to keep
    > spinning at a constant angular velocity. Often the next data the head
    > encounters is the next data in the file if it's a sequential file.
    >
    > > So no extra seek is needed.

    Seeks are never *needed*.

    >
    > Huh?
    >
    > > For concept 1 and concept 2 this works just fine and gives good performance.
    > >
    > > However concept 3 has very bad performance.
    >
    > Huh, it's just how disks work.

    Nope.

    >
    > > Is this a software issue ? ( Windows XP )
    >
    > WHAT?
    >
    > > Is this a hardware issue ? ( Harddisk Read Head and Harddisk Write Head
    > > can't work together like this and an extra seek is needed ? )
    >
    > There are NOT two heads

    Yes there are, you mighty clueless one.

    "The head consists of a thin film inductive write element and an MR read element.
    The read element is typically narrower than the write element to improve the
    off-track performance. In practice, there is an offset between the center of
    the read and write elements due to the longitudinal separation of the elements.
    When used with a rotary actuator, the head is skewed with respect to the tracks
    as the actuator moves across the disk. The result is a lateral offset between the
    read and write head centerlines.
    Optimum performance is achieved by centering the read head over the data track
    for read operations, and centering the write head over the data track for write
    operations. This operation will cause the read head to be partially off-track
    during a write operation. "

    Source: IBM/HGST http://www.hgst.com/hdd/ipl/oem/tech/noid.htm

    > but just a single head per disk surface. That head both reads and writes
    No, it doesn't.

    > but can do only one or the other at a given instant.
    > There is a finite switch time between read and write mode.

    Because of the 2 heads, one aligned behind the other.

    > During that switch time the disk continues to spin.
    >
    > > Or some sort of driver issue ? ( Harddisk driver / firmware issue ? )
    >
    > What issue?
  11. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    In windows xp I always have harddisk write cache off to prevent data loss in
    case of power failure etc.

    But just for the kick of it I enabled it, and I did no reboot. It had no
    effect on performance, though I only tested shortly ;)

    Tomorrow I might test it once more... but after enabling it and before
    testing it I will do a reboot.

    I doubt I will see any performance difference.

    If I don't see any performance difference in writing speed etc... that would
    be a little bit suprising...

    Since that would mean write cache doesn't help and can only cause loss of
    data anyway.

    Besides from that the document doesn't make any differences in Read and
    Write speed.

    My test programs clearly show there is a difference in Read and Write speed.

    The document just mentions 'Data Transfer' speed... which is probably only
    the Read speed.

    The funny thing is my programs achieve those speeds roughly... so that's
    correct... and my programs are correct ;) :P

    :D
  12. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message

    > My test programs clearly show there is a difference in Read and Write
    speed.

    Well what exactly is your test program doing to what kind of a file?
  13. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nathan McNulty" <525676@betaweb.com> wrote in message
    news:%23G%23AUyeaEHA.3524@TK2MSFTNGP12.phx.gbl...
    > 1. Yes really. You cannot read and write at the same time. The command
    > has to be either read or write.
    >
    > 2. Hardware limitation that it cannot read and write at the same time.

    That's kinda interesting.

    That could mean when downloading and uploading a file for example... or
    doing any other work.

    The number of seeks that can be done per second has to be divided by 2.

    So that would mean in worst case scenerio.. there are only 25 seeks per
    second available !

    So that's 25 seeks for reading and 25 seeks for writing :D

    But... that could be stupid to divide it like that.

    Since writing at least on my harddisk is much slower...

    So maybe spending 25 seeks on writing would be stupid... or maybe it would
    be necessary to still achieve 1 mbyte/sec.

    So to achieve say 10 MByte/Sec... it's 10 MByte / 25 = roughly a 400 KB
    buffer which can be split into 100 reads of 4 KB.

    Which will all (hopefully) be read from the harddisk's read cache... so
    those 100 reads don't require an extra seek.

    For writing I don't dare to do the calculations since writing is weird...
    much slower !

    >
    > 3. From what I have seen on my old harddrives I have taken apart and
    > what I have read, there is a tip on the head that prevents the magnetic
    > part from affecting nearby sectors. I was under the impression these do
    > not always stay in the same position but are required to move each time
    > a write process is initiated.
    >
    > 4. Again, the tips would have to move back to their resting position.
    > Maybe this is just old hardware (especially since my books are all very
    > old) or maybe I've read it wrong, but that was my understanding of how
    > that part worked.
    >
    > Nathan McNulty
    >
    > Ron Reaugh wrote:
    >
    > > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > > news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    > >
    > >>Actually, what is happening is that the heads on the platter need to
    > >>reconfigure themselves each time you read or write.
    > >
    > >
    > > Not really.
    > >
    > >
    > >>It is a hardware
    > >>limitation.
    > >
    > >
    > > What limitation is that exactly?
    > >
    > >
    > >> By reading, the head can stay in the same location, but
    > >>once it is told to write, the head has to position itself to change the
    > >>magnetism of the sector of the platter it is on.
    > >
    > >
    > > That's false.
    > >
    > >
    > >> Then once you request
    > >>to read again, the head has to move again.
    > >
    > >
    > > Not necessarily.
    > >
    > >
  14. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd4dfg$ilt$1@news1.tilbu1.nb.home.nl...
    >
    > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > news:%23G%23AUyeaEHA.3524@TK2MSFTNGP12.phx.gbl...
    > > 1. Yes really. You cannot read and write at the same time. The command
    > > has to be either read or write.
    > >
    > > 2. Hardware limitation that it cannot read and write at the same time.
    >
    > That's kinda interesting.
    >
    > That could mean when downloading and uploading a file for example... or
    > doing any other work.
    >
    > The number of seeks that can be done per second has to be divided by 2.
    >
    > So that would mean in worst case scenerio.. there are only 25 seeks per
    > second available !

    NO, where are you getting this nonsense?
  15. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Hmmm...

    I examined the source code of my read and write benchmark programs ;)

    The read program reads the totaly file.

    So it does

    1 Seek

    X reads until file is read.

    The write program however uses a cache of 1 MB.

    So it does

    1 Seek

    X writes until cache is written and then again

    1 Seek

    X writes until cache is written etc etc.

    So that can explain why writing is slower.

    So I will have to write some new benchmarks... which behave exactly the same
    for reading and writing :D

    Bye,
    Skybuck.
  16. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd4dvf$3k$1@news5.tilbu1.nb.home.nl...
    > Hmmm...
    >
    > I examined the source code of my read and write benchmark programs ;)
    >
    > The read program reads the totaly file.

    How big a file? Does it read all the blocks in order from beginning to
    end(sequential)?

    > So it does
    >
    > 1 Seek

    How do you decide that?

    > X reads until file is read.
    >
    > The write program however uses a cache of 1 MB.
    >
    > So it does
    >
    > 1 Seek

    What 1MB cache handled where?

    > X writes until cache is written and then again
    >
    > 1 Seek

    What says there is a seek to where here?

    > X writes until cache is written etc etc.
    >
    > So that can explain why writing is slower.

    Huh?
  17. Archived from groups: microsoft.public.windowsxp.hardware (More info?)

    Hi Skybuck,

    Thank you for posting!

    In my opinion, the performance of your hard disk is a hardware-specific
    issue. Due to the complexity of this issue, we are unable to assist with
    this request in the newsgroups as the Technet newsgroups are geared towards
    break-fix scenarios.

    For further assistance on this issue, please contact Microsoft Product
    Support Services by telephone so that a dedicated Support Professional can
    assist you further with your request.

    To obtain the phone numbers for specific technology request please take a
    look at the web site listed below.

    http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS

    Have a nice day!

    Thanks & Regards,

    Feng Mao [MSFT], MCSE
    Microsoft Online Partner Support

    Get Secure! - www.microsoft.com/security

    =====================================================
    When responding to posts, please "Reply to Group" via your newsreader so
    that others may learn and benefit from your issue.
    =====================================================
    This posting is provided "AS IS" with no warranties, and confers no rights.
  18. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Skybuck Flying wrote:
    > Hmmm...
    > <snip>
    > 1 Seek
    <snip>

    1 seek that you instructed it to complete. This is a multitasking operating
    system.

    Cheers,
    Nicholas Sherlock
  19. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    news:I7jJc.254413$Gx4.15735@bgtnsc04-news.ops.worldnet.att.net...
    >
    > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > news:cd4dfg$ilt$1@news1.tilbu1.nb.home.nl...
    > >
    > > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > > news:%23G%23AUyeaEHA.3524@TK2MSFTNGP12.phx.gbl...
    > > > 1. Yes really. You cannot read and write at the same time. The command
    > > > has to be either read or write.
    > > >
    > > > 2. Hardware limitation that it cannot read and write at the same time.
    > >
    > > That's kinda interesting.
    > >
    > > That could mean when downloading and uploading a file for example... or
    > > doing any other work.
    > >
    > > The number of seeks that can be done per second has to be divided by 2.
    > >
    > > So that would mean in worst case scenerio.. there are only 25 seeks per
    > > second available !
    >
    > NO, where are you getting this nonsense?
    >

    Well after posting this I realized what the mistake is with the calculation.

    Suppose 1 second has 1000 millisecond and the seek time is 20 milliseconds.

    1000 / 20 = 50 seeks per second.

    But the problem is that 20x50 = 1000 milliseconds.

    So there is no time left, to do a read, or a write.

    Reading and writing data costs time as well.

    So does moving to the next track etc.

    So there is a lot of 'hiding' time requirements.

    So my simple calculation simply ignored all these facts.

    So a much more complicated formula is needed ;)

    Bye,
    Skybuck.
  20. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    news:T7jJc.95077$OB3.11984@bgtnsc05-news.ops.worldnet.att.net...
    >
    > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > news:cd4dvf$3k$1@news5.tilbu1.nb.home.nl...
    > > Hmmm...
    > >
    > > I examined the source code of my read and write benchmark programs ;)
    > >
    > > The read program reads the totaly file.
    >
    > How big a file? Does it read all the blocks in order from beginning to
    > end(sequential)?

    100 MB, Yes.

    >
    > > So it does
    > >
    > > 1 Seek
    >
    > How do you decide that?

    The program has 1 seek instruction.

    >
    > > X reads until file is read.
    > >
    > > The write program however uses a cache of 1 MB.
    > >
    > > So it does
    > >
    > > 1 Seek
    >
    > What 1MB cache handled where?

    Officialy it's called 'User Space'. But let's just call it 'Program Space'.
    Memory allocated by the program.
    >
    > > X writes until cache is written and then again
    > >
    > > 1 Seek
    >
    > What says there is a seek to where here?

    It does a seek into the file at a random location.

    >
    > > X writes until cache is written etc etc.
    > >
    > > So that can explain why writing is slower.
    >
    > Huh?

    Because it seeks more.

    Loop:

    Seek somewhere in file.

    Write 4 KB

    Write 4 KB

    Write 4 KB

    etc up to 1 MB / 4 KB.

    go back to loop.

    So after it has written 1 MB to the file... (in pieces of 4KB)... it goes
    back to loop and does a seek again.

    That's why it does more seeks than the read test.... at least for big files
    ;)

    I thought 1 MB cache was enough to reach maximum harddisk speed... or 'good
    enough' speed...

    But 1 MByte/Sec is not really satisfactory for a 100 Megabit Network.

    So I would prefer higher write speeds of say 4 MByte/Sec to 8 MByte/Sec ;)

    A bigger cache and less seeking might be required to achieve that... I am
    not sure about though :D

    Bye,
    Skybuck.


    >
    >
  21. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Nicholas Sherlock" <n_sherlock@hotmail.com> wrote in message
    news:cd4eav$6qs$1@lust.ihug.co.nz...
    > Skybuck Flying wrote:
    > > Hmmm...
    > > <snip>
    > > 1 Seek
    > <snip>
    >
    > 1 seek that you instructed it to complete. This is a multitasking
    operating
    > system.

    So what's your point ?

    During testing I have no other applications open to minimize any other disk
    activity.

    >
    > Cheers,
    > Nicholas Sherlock
    >
    >
  22. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
    >
    > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...
    >
    > > Concept 3 (Reading and Writing, with regular switches )
    > >
    > > Oh my... now that's what I call bad performance !
    > >
    > > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    > > Kbyte/sec.
    > >
    > > Max was 200 KByte/sec.
    > >
    > > So it seems switching from read to write to read to write requires extra
    > > seeking etc...
    >
    > Nope, calculate the theoretical rate for the data group to be transferred
    > at the rate of one per revolution.

    I don't understand yet how to calculate the data transfer rate ;)

    I will read some documents about that and try to understand... then I will
    get back on this ;)

    > Each time you switch from read to write
    > you likely lose the rest of the current disk rotation.

    Sounds reasonable.

    >
    > > Maximum seek time for my HD and most HD's is 20 milliseconds.
    >
    > What is the relation of the location of each 4KB block of data? Are they
    > sequential in a file? Where is a write located compared to the preceeding
    > read?.

    In concept 3 yes, they should be, but might not be because of file
    fragmentation.

    >
    > > Average Seek time is around 10 to 15 milliseconds.
    >
    > Seeking has to do with moving the head to a different track. Are you
    doing
    > random I/O of these blocks in a big file or to multiple files?

    1 File.

    >
    > It sounds like you haven't well thought out or at least described what you
    > are doing.

    Well I might come back on that ;)

    Anyway here are two new concepts... actually the real concept behind concept
    3.

    Concept 4:

    Seek

    Skip 4 KByte block
    Skip 4 KByte block
    Write 4 KByte block
    Skip 4 KByte block
    Write 4 KByte block
    Skip 4 KByte block
    Skip 4 KByte block
    Write 4 KByte block
    etc

    That's what I would like to do with a file...

    I only want to update some parts of a file... not the complete file... etc.

    The number of seeks I can use is limited so I have to try and do as many
    writes as possible per seek.

    Get it now ? ;)

    Concept 5:

    Skip 4 KByte block
    Skip 4 KByte block
    Read 4 KByte block
    Skip 4 KByte block
    Read 4 KByte block
    Skip 4 KByte block
    Skip 4 KByte block
    Read 4 KByte block
    etc

    I don't think harddisks have a 'skip x number of bytes' command.
  23. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...

    > I will read some documents about that and try to understand... then I will
    > get back on this ;)

    www.storagereview.com
  24. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Here is what needs to be done as efficiently as possible:

    Transferring a file of 100 MByte from Computer A to Computer B.

    The file is split into packets which are send across a network.

    The packets are 512 bytes.

    Sometimes some packets might go lost.

    This creates gaps in the file.

    These gaps have to be filled in later ;)

    Seeking to all these gaps could be very slow.

    So I see some possible solutions.

    Problem:

    Packet 1, 5, 9, 13 are re-transmitted and have to be stored to file.

    Possibly slow solution 1:

    Seek Packet 1, Write Packet 1
    Seek Packet 5, Write Packet 5
    Seek Packet 9, Write Packet 9
    Seek Packet 13, Write Packet 13.

    Possibly faster solution 2:

    Seek Packet 1,
    Read Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 into memory.

    ( Packet 1,5,9,13 are empty )

    Overwrite packet 1,5,9,13 with new data into memory.

    Seek Packet 1
    Write Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 from memory to harddisk.

    Possibly bad solution 3:

    ( because of harddisk design, switching from read to write to read to write
    is slow )

    Seek Packet 1
    Write Packet 1
    Skip or Read Packet 2
    Skip or Read Packet 3,
    Skip or Read Packet 4,
    Write Packet 5
    Skip or Read Packet 6,
    Skip or Read Packet 7,
    Skip or Read Packet 8,
    Write Packet 9
    Skip or Read Packet 10,
    Skip or Read Packet 11,
    Skip or Read Packet 12,
    Write Packet 13.

    If the harddisk and software had a skip command this solution might be very
    fast.

    But because it doesn't have a skip command... I tried a read command
    instead.

    But funny enough that gives very bad performance.

    So currently I think solution 2 is best at the moment.

    At this point I am out of ideas ;)

    Bye,
    Skybuck.
  25. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Try a CD-R


    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd6876$pbb$1@news3.tilbu1.nb.home.nl...
    | Here is what needs to be done as efficiently as possible:
    |
    | Transferring a file of 100 MByte from Computer A to
    Computer B.
    |
    | The file is split into packets which are send across a
    network.
    |
    | The packets are 512 bytes.
    |
    | Sometimes some packets might go lost.
    |
    | This creates gaps in the file.
    |
    | These gaps have to be filled in later ;)
    |
    | Seeking to all these gaps could be very slow.
    |
    | So I see some possible solutions.
    |
    | Problem:
    |
    | Packet 1, 5, 9, 13 are re-transmitted and have to be
    stored to file.
    |
    | Possibly slow solution 1:
    |
    | Seek Packet 1, Write Packet 1
    | Seek Packet 5, Write Packet 5
    | Seek Packet 9, Write Packet 9
    | Seek Packet 13, Write Packet 13.
    |
    | Possibly faster solution 2:
    |
    | Seek Packet 1,
    | Read Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 into memory.
    |
    | ( Packet 1,5,9,13 are empty )
    |
    | Overwrite packet 1,5,9,13 with new data into memory.
    |
    | Seek Packet 1
    | Write Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 from memory to
    harddisk.
    |
    | Possibly bad solution 3:
    |
    | ( because of harddisk design, switching from read to write
    to read to write
    | is slow )
    |
    | Seek Packet 1
    | Write Packet 1
    | Skip or Read Packet 2
    | Skip or Read Packet 3,
    | Skip or Read Packet 4,
    | Write Packet 5
    | Skip or Read Packet 6,
    | Skip or Read Packet 7,
    | Skip or Read Packet 8,
    | Write Packet 9
    | Skip or Read Packet 10,
    | Skip or Read Packet 11,
    | Skip or Read Packet 12,
    | Write Packet 13.
    |
    | If the harddisk and software had a skip command this
    solution might be very
    | fast.
    |
    | But because it doesn't have a skip command... I tried a
    read command
    | instead.
    |
    | But funny enough that gives very bad performance.
    |
    | So currently I think solution 2 is best at the moment.
    |
    | At this point I am out of ideas ;)
    |
    | Bye,
    | Skybuck.
    |
    |
  26. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Anyway...

    With my 'Possibly faster solution 2' mention somewhere else in this thread.

    The big question is:

    How many reads/writes per seek ?

    A secondary question would be how big the buffer size (block size to
    transfer in one read or write ).

    The answer to this secondary question might be simply 512 bytes... or 4 KB
    which should give best results because of cpu page size, ram page size and
    possible harddisk page size etc. So that answer is fixed.

    The remaining question would be:

    How many reads of 4 KB per seek ?

    How many seeks per second are ok ? (possible only 1 )

    The desired speed is 4 MByte/Sec

    The desired speed could be 8 Mbyte/Sec.

    4 MByte/Sec divided by 4 KB buffer = 1000 reads.

    That's a lot !

    The second desired speed is 2000 reads that s twice as much ;)

    Seeing these specification talk about 1 to 2 milliseconds for a command,
    read, switch whatever... it doesn't take a lot of imagination to see how
    exceeing 1 second is easily achieved and ofcourse not desired.

    Suppose each read command take 1 millisecond. 2000x1= 2 seconds... <- oops.

    Or 2 Seeks = 30 Milliseconds + 1000 reads <- 1030 milliseconds <- oops.

    Etc...

    :)

    So the big question is

    1. How to achieve MByte/Sec writing... since that seems most difficult.

    Timing is the key here...

    The bad news is that every harddisk has different timing.

    One could assume worst case timing for all factors etc.

    Only thing left to do is to come up with a formula to find out how many
    reads, how many seeks and how big the transfer buffer should be...

    the transfer buffer might be fixed to 4 KB so that might not be variable
    since 4 KB achieves best performance... so it can't do better than that...

    So that leaves... seeks vs reads....

    StorageReview doesn't seem to help with the formula's... (or least I didn't
    see any page about it ) so I ll dive back into my IBM/Hitachi Deskstar 14
    GXP document and try to make sense of it :D

    Skybuck.
  27. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    On the other hand...

    There are only 3 variables which I can control with my
    software/windows/delphi/TFileStream :) ;)

    1. TFileStream.Seek <- seek command

    2. TFileStream.Read,
    TFileStream.Write <- read command or write command

    3. The Read/Write Buffer Size

    But then there are ofcourse more factors involved:

    4. Offset of seek is also a factor.
    5. Switching between read and write is a factor.

    6. Switching between seek, read and write might be a factor.
    7. Even pausing for a while might be a factor.

    And then there are ofcourse external factors... OS, Other Hardware etc.

    So at least 5 factors amount into 6 requirements :D

    1. The program should do sequential seeks or random seeks. Randomize Offset,
    Or increment Offset. <- Sequential seeks is pretty much bullshit. But not
    quite... since you could seek ahead only.
    2. The program should do, read only, write only, or mixed, possibly with a
    read:write ratio or randomizer.
    3. The program should do seeks per second.
    4. The program should do writes per second. Writes per seek should therefore
    be calculated.
    5. The program should do reads per second. Reads per seek should therefore
    be calculated.
    6. The program should do buffer size variable.

    5 Causes 2 to be partially done... except for the mixed and randomizer.
    Read/Write Randomizer is less interesting. Mixed could be interesting but is
    also automatically handled.
    Ratio is also handled by 2.

    So all this stuff would give a single result ;)

    Speed Per Second :)

    ( Data Transfer Speed From/To Harddisk in Bytes/Sec :D )

    So instead of trying to understand a document about how a single harddisk
    works, it's charactistics, it's timing factors and terms and how it is
    related to performance and unapplyable formula's for application software
    because of missing information like current cylinder number and track and
    sector number, a test program could be made to find the sweet spot in
    practice :D

    To top things off some artificial intelligence mechanisme should try out all
    kinds of settings and find the sweet spot :D hehehehe.

    Bye,
    Skybuck.
  28. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:hjhJc.94738$OB3.83285@bgtnsc05-news.ops.worldnet.att.net
    > "Nathan McNulty" <525676@betaweb.com> wrote in message
    > news:OauKdFeaEHA.1048@tk2msftngp13.phx.gbl...
    > > Actually, what is happening is that the heads on the platter need to
    > > reconfigure themselves each time you read or write.
    >
    > Not really.

    Yes, really. How much depends per cylinder. Not that it matters.

    >
    > > It is a hardware limitation.
    >
    > What limitation is that exactly?

    You need to ask? Not that it matters.

    >
    > > By reading, the head can stay in the same location, but
    > > once it is told to write, the head has to position itself to change the
    > > magnetism of the sector of the platter it is on.
    >
    > That's false.

    Nope. Not that it matters.

    >
    > > Then once you request to read again, the head has to move again.
    >
    > Not necessarily.

    Indeed, as it's automatically done by the Servo system.
  29. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message news:cd625r$cqb$1@news2.tilbu1.nb.home.nl
    > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
    > >
    > > "Skybuck Flying" <nospam@hotmail.com> wrote in message news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...
    > >
    > > > Concept 3 (Reading and Writing, with regular switches )
    > > >
    > > > Oh my... now that's what I call bad performance !
    > > >
    > > > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    > > > Kbyte/sec.
    > > >
    > > > Max was 200 KByte/sec.
    > > >
    > > > So it seems switching from read to write to read to write requires extra
    > > > seeking etc...
    > >
    > > Nope, calculate the theoretical rate for the data group to be transferred
    > > at the rate of one per revolution.
    >
    > I don't understand yet how to calculate the data transfer rate ;)
    >
    > I will read some documents about that and try to understand... then I will
    > get back on this ;)
    >
    > > Each time you switch from read to write
    > > you likely lose the rest of the current disk rotation.
    >
    > Sounds reasonable.

    But it's not.
    In order to write to the correct sector the drive has to know
    if it is the right sector, therefor needs to read the header.
    If it can't, writes would go one sector per rev.
    Obviously not.

    And this is how it used to be when Sector-IDs were still in use
    and obviously things improve with time, not worsen, so if it could
    do it then it certainly can do it now.

    [snip]
  30. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd5uig$d9f$1@news2.tilbu1.nb.home.nl...
    >
    > So does moving to the next track etc.

    That's an electronic headswitch or an adjacent cylinder seek.
  31. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    You need to describe in more detail your program and settings. Why do you
    assume that your program statements have any first order relation to what's
    happening at the physical disk I/O level?

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd61gd$7vq$1@news3.tilbu1.nb.home.nl...
    >
    > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    > news:T7jJc.95077$OB3.11984@bgtnsc05-news.ops.worldnet.att.net...
    > >
    > > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > > news:cd4dvf$3k$1@news5.tilbu1.nb.home.nl...
    > > > Hmmm...
    > > >
    > > > I examined the source code of my read and write benchmark programs ;)
    > > >
    > > > The read program reads the totaly file.
    > >
    > > How big a file? Does it read all the blocks in order from beginning to
    > > end(sequential)?
    >
    > 100 MB, Yes.
    >
    > >
    > > > So it does
    > > >
    > > > 1 Seek
    > >
    > > How do you decide that?
    >
    > The program has 1 seek instruction.
    >
    > >
    > > > X reads until file is read.
    > > >
    > > > The write program however uses a cache of 1 MB.
    > > >
    > > > So it does
    > > >
    > > > 1 Seek
    > >
    > > What 1MB cache handled where?
    >
    > Officialy it's called 'User Space'. But let's just call it 'Program
    Space'.
    > Memory allocated by the program.
    > >
    > > > X writes until cache is written and then again
    > > >
    > > > 1 Seek
    > >
    > > What says there is a seek to where here?
    >
    > It does a seek into the file at a random location.
    >
    > >
    > > > X writes until cache is written etc etc.
    > > >
    > > > So that can explain why writing is slower.
    > >
    > > Huh?
    >
    > Because it seeks more.
    >
    > Loop:
    >
    > Seek somewhere in file.
    >
    > Write 4 KB
    >
    > Write 4 KB
    >
    > Write 4 KB
    >
    > etc up to 1 MB / 4 KB.
    >
    > go back to loop.
    >
    > So after it has written 1 MB to the file... (in pieces of 4KB)... it goes
    > back to loop and does a seek again.
    >
    > That's why it does more seeks than the read test.... at least for big
    files
    > ;)
    >
    > I thought 1 MB cache was enough to reach maximum harddisk speed... or
    'good
    > enough' speed...
    >
    > But 1 MByte/Sec is not really satisfactory for a 100 Megabit Network.
    >
    > So I would prefer higher write speeds of say 4 MByte/Sec to 8 MByte/Sec ;)
    >
    > A bigger cache and less seeking might be required to achieve that... I am
    > not sure about though :D
    >
    > Bye,
    > Skybuck.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > >
    > >
    >
    >
  32. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd61in$5j9$1@news2.tilbu1.nb.home.nl...
    > During testing I have no other applications open to minimize any other
    disk
    > activity.

    There's all sorts of possible blocking and other issues related to OS
    scheduling that could be at work even in an idle system.
  33. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...
    >
    > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    > news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
    > >
    > > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > > news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...
    > >
    > > > Concept 3 (Reading and Writing, with regular switches )
    > > >
    > > > Oh my... now that's what I call bad performance !
    > > >
    > > > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    > > > Kbyte/sec.
    > > >
    > > > Max was 200 KByte/sec.
    > > >
    > > > So it seems switching from read to write to read to write requires
    extra
    > > > seeking etc...
    > >
    > > Nope, calculate the theoretical rate for the data group to be
    transferred
    > > at the rate of one per revolution.
    >
    > I don't understand yet how to calculate the data transfer rate ;)

    Let's assume that your programatic 4K block has a direct relation to the
    actual disk I/O size(it probably does NOT.) Now assume that the disk spins
    at 7200 RPM or 120 revs per second. So the throughput of one 4K block per
    rev is 120 x 4,000 = bytes per second = 480,000. That's the max speed as
    any seeking will slow things down more.
  34. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Go back under the bridge where you belong.

    "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
    news:2lnsitFet5f6U3@uni-berlin.de...
  35. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    news:SvEJc.260533$Gx4.51289@bgtnsc04-news.ops.worldnet.att.net...
    >
    > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...
    > >
    > > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    > > news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
    > > >
    > > > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > > > news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...
    > > >
    > > > > Concept 3 (Reading and Writing, with regular switches )
    > > > >
    > > > > Oh my... now that's what I call bad performance !
    > > > >
    > > > > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds 160
    > > > > Kbyte/sec.
    > > > >
    > > > > Max was 200 KByte/sec.
    > > > >
    > > > > So it seems switching from read to write to read to write requires
    > extra
    > > > > seeking etc...
    > > >
    > > > Nope, calculate the theoretical rate for the data group to be
    > transferred
    > > > at the rate of one per revolution.
    > >
    > > I don't understand yet how to calculate the data transfer rate ;)
    >
    > Let's assume that your programatic 4K block has a direct relation to the
    > actual disk I/O size(it probably does NOT.) Now assume that the disk
    spins
    > at 7200 RPM or 120 revs per second. So the throughput of one 4K block per
    > rev is 120 x 4,000 = bytes per second = 480,000. That's the max speed as
    > any seeking will slow things down more.

    The 4KB size is probably because of the way CPU's and RAM work... CPU's and
    RAM like moving 4 KBytes at a time ;)

    Hmmm...

    Does that mean a harddisk is only able to read 1 block of data per
    revolution ?

    That can't be correct since I have another program that reads/writes block
    of roughly 512 bytes...

    That would mean max: 512 * 120 = 61 KB...

    I am pretty sure the program was able to achieve higher speeds then that.

    That could mean a couple of things:

    1. Windows XP 'groups' multiple 'seeks + read' pairs together if they are
    for example sequantial... and turn it into one big read to the harddisk...
    and then give it back in multiple reads to my program.

    or

    2. The harddisk has some read ahead cache... so that multiple reads can
    occur without having to wait for another revolution.

    There are a couple of things I wonder about:

    1. How long does it take to read 1 sector from the moment it is found
    (seeked, so not including seek time) to the moment it is completely read.

    Maybe this is a weird question because harddisk's like to 'cache' as much
    sectors as possible during a read... I think this is what they call re-ahead
    cache ?... or just harddisk read cache ?

    Anyway I did some calculations...

    And my drive is able to have a sustained speed of 8 Million bytes per
    second.

    So that is roughly:

    ( 8.000.000 Bytes / 512 Bytes Per Sector ) / Sec = 15625 Sectors / Sec.

    So to find the time per sector in seconds:

    1 second / 15625 Sectors = 0.000064 Seconds Per Sector

    So that means roughly 0.064 milliseconds per sector.

    0.000064 * 1000 = 0.064 Millisecond per Sector.

    Maybe I can take this as an average... so it means inclusive of command
    overhead, switch times, all that stuff.

    So I could try to use this in calculations to find throughput.

    The remaining factor is seek time...

    The document about my harddisk states:

    Full Stroke Read Seek Time 18 MSec
    Full Stroke Write Seek Time 19 MSec

    This seems about right since I like to think seek time is mostly 20
    milliseconds anyway in practice. Unless many sequantial seeks are done...

    But for randomly seeking this seems about right.

    So now I might be able to do some calculations like this:

    Suppose I have a write cache like in the write program I posted the results
    from.

    1 Megabyte write cache.

    This cache consists out of 250 blocks of 4 KB = 1 MByte.

    ( Maybe the 4 KB is not that much relevant anyway )

    First a seek is done:

    20 Milliseconds gone.

    1 Megabyte / 512 sector size = 2048 Sectors have to be written.

    2048 * 0.064 = 131.072 milliseconds.

    That's 151 Milliseconds gone.

    1000 milliseconds / 151 = 6.6.

    So the program should roughly be able to do this 6.6 times.

    6.6 x 1 MByte = 6.6 Mbyte / Sec write speed.

    The weird thing is my program does not achieve this speed....

    It sticks around at 1 MByte/Sec.

    Only the first second it achieved 6 or 7 MByte/Sec. Which can probably be
    ignored since the program has to still start etc...

    But still... the program did not update the stats every second...

    So this time I took a look at the task manager and the process list, it
    shows the I/O Write Bytes.

    I notice that the harddisk is spinning a lot and making noise a lot.

    Sometimes it only updates with 20 KB and sometimes with 1 or 2 MByte.

    Could this be because of fragmentation I wonder ?!

    I have a pretty fragmented file system / drive ! :D

    So it could be that it has to seek a lot etc...

    BUTT

    It remains weird... because when I use the other program... to do sequential
    read of the file... from start to end... it goes much faster !

    So that's a bit weird.

    Maybe it's because the write program... seeks randomly into the file.... so
    it could start writing anywhere... maybe half way a cylinder or track etc...
    so then at first has to wait a bit or so until a revolution is past... but
    from that moment on it should write sequantially and that should go fast ?!

    Or maybe windows xp has to do all kinds of updates somewhere in the ntfs
    system etc...

    Oh well...

    Skybuck.
  36. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    "Skybuck Flying" <nospam@hotmail.com> wrote in message
    news:cd8e63$o2a$1@news1.tilbu1.nb.home.nl...
    >
    > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    > news:SvEJc.260533$Gx4.51289@bgtnsc04-news.ops.worldnet.att.net...
    > >
    > > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > > news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...
    > > >
    > > > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
    > > > news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
    > > > >
    > > > > "Skybuck Flying" <nospam@hotmail.com> wrote in message
    > > > > news:cd4bur$b8r$1@news3.tilbu1.nb.home.nl...
    > > > >
    > > > > > Concept 3 (Reading and Writing, with regular switches )
    > > > > >
    > > > > > Oh my... now that's what I call bad performance !
    > > > > >
    > > > > > The first 10 seconds it was 80 Kbyte/Sec... the next 20 seconds
    160
    > > > > > Kbyte/sec.
    > > > > >
    > > > > > Max was 200 KByte/sec.
    > > > > >
    > > > > > So it seems switching from read to write to read to write requires
    > > extra
    > > > > > seeking etc...
    > > > >
    > > > > Nope, calculate the theoretical rate for the data group to be
    > > transferred
    > > > > at the rate of one per revolution.
    > > >
    > > > I don't understand yet how to calculate the data transfer rate ;)
    > >
    > > Let's assume that your programatic 4K block has a direct relation to the
    > > actual disk I/O size(it probably does NOT.) Now assume that the disk
    > spins
    > > at 7200 RPM or 120 revs per second. So the throughput of one 4K block
    per
    > > rev is 120 x 4,000 = bytes per second = 480,000. That's the max speed
    as
    > > any seeking will slow things down more.
    >
    > The 4KB size is probably because of the way CPU's and RAM work... CPU's
    and
    > RAM like moving 4 KBytes at a time ;)

    No, you said 4KB writes. The CPU/RAM aren't relevant.

    > Hmmm...
    >
    > Does that mean a harddisk is only able to read 1 block of data per
    > revolution ?

    Unless the I/O is structured to meet streaming requirements, yes one block
    per rev is often the result.

    > That can't be correct since I have another program that reads/writes
    block
    > of roughly 512 bytes...
    >
    > That would mean max: 512 * 120 = 61 KB...
    >
    > I am pretty sure the program was able to achieve higher speeds then that.

    Yes, you achieved some streaming probably via intelligent buffering in the
    language I/O routines, OS or onboard the drive.

    > That could mean a couple of things:
    >
    > 1. Windows XP 'groups' multiple 'seeks + read' pairs together if they are
    > for example sequantial...

    Exclude seek from the statement.

    >and turn it into one big read to the harddisk...
    > and then give it back in multiple reads to my program.

    Exactly and the drive itself will read into its onboard buffer even more
    physically sequential data than you asked for which puts it in a position to
    send that additional data back to you with no further actual disk surface
    I/O. Keep doing that fast and the drive will try and stay ahead.......and
    your streaming and full disk read rate which is the number of user sectors
    per track at revolution speed. There are equivalent mechanisms for write
    streaming

    > or
    >
    > 2. The harddisk has some read ahead cache... so that multiple reads can
    > occur without having to wait for another revolution.
    >
    > There are a couple of things I wonder about:
    >
    > 1. How long does it take to read 1 sector from the moment it is found
    > (seeked, so not including seek time) to the moment it is completely read.

    Generally speaking it is the fraction of a revolution derived from the
    number of sectors per track and the RPM.

    > Maybe this is a weird question because harddisk's like to 'cache' as much
    > sectors as possible during a read...

    Well, there's an algorithm "as much" is too strong.

    >I think this is what they call re-ahead
    > cache ?... or just harddisk read cache ?

    There's RAM onboard a HD. It's used for write caching, read caching and
    microcode etc.

    > Anyway I did some calculations...
    >
    > And my drive is able to have a sustained speed of 8 Million bytes per
    > second.

    That's very slow for any recent drive. Current drive are generally in the
    30-60MB/sec. vicinity.
  37. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    As I suspected the 100 MB file I was using to test... is pretty heavily
    fragmented :D ;)

    I found this nice little too to find out if it's fragmented.

    http://www.sysinternals.com/ntw2k/info/defrag.shtml

    This was the output ;)

    : n \test files\bufferlog.txt

    Clusters for file: C:\test files\bufferlog.txt
    VCN: 0 LCN: 1300746 LEN: 16
    VCN: 16 LCN: 1346392 LEN: 32
    VCN: 48 LCN: 1345381 LEN: 64
    VCN: 112 LCN: 2295765 LEN: 128
    VCN: 240 LCN: 2510809 LEN: 219
    VCN: 459 LCN: 2619481 LEN: 85
    VCN: 544 LCN: 2467607 LEN: 218
    VCN: 762 LCN: 2326190 LEN: 102
    VCN: 864 LCN: 1866455 LEN: 218
    VCN: 1082 LCN: 2778070 LEN: 102
    VCN: 1184 LCN: 241057 LEN: 225
    VCN: 1409 LCN: 2642790 LEN: 95
    VCN: 1504 LCN: 2765237 LEN: 217
    VCN: 1721 LCN: 2053603 LEN: 119
    VCN: 1840 LCN: 403797 LEN: 217
    VCN: 2057 LCN: 1280178 LEN: 119
    VCN: 2176 LCN: 1870824 LEN: 225
    VCN: 2401 LCN: 2483382 LEN: 111
    VCN: 2512 LCN: 1184381 LEN: 227
    VCN: 2739 LCN: 1280035 LEN: 125
    VCN: 2864 LCN: 2559019 LEN: 229
    VCN: 3093 LCN: 2764708 LEN: 123
    VCN: 3216 LCN: 2058491 LEN: 233
    more ('q' to quit):
    VCN: 3449 LCN: 1382934 LEN: 119
    VCN: 3568 LCN: 404503 LEN: 243
    VCN: 3811 LCN: 2522295 LEN: 125
    VCN: 3936 LCN: 857266 LEN: 243
    VCN: 4179 LCN: 1179615 LEN: 126
    VCN: 4305 LCN: 2176930 LEN: 243
    VCN: 4548 LCN: 1281750 LEN: 126
    VCN: 4674 LCN: 1465119 LEN: 213
    VCN: 4887 LCN: 1184609 LEN: 173
    VCN: 5060 LCN: 1866681 LEN: 250
    VCN: 5310 LCN: 700707 LEN: 130
    VCN: 5440 LCN: 700422 LEN: 252
    VCN: 5692 LCN: 1822219 LEN: 132
    VCN: 5824 LCN: 1284880 LEN: 255
    VCN: 6079 LCN: 2514075 LEN: 146
    VCN: 6225 LCN: 2456167 LEN: 259
    VCN: 6484 LCN: 2559526 LEN: 144
    VCN: 6628 LCN: 2178713 LEN: 260
    VCN: 6888 LCN: 2313913 LEN: 153
    VCN: 7041 LCN: 240583 LEN: 263
    VCN: 7304 LCN: 2501987 LEN: 153
    VCN: 7457 LCN: 2204221 LEN: 271
    VCN: 7728 LCN: 1871065 LEN: 147
    VCN: 7875 LCN: 1158481 LEN: 292
    more ('q' to quit):
    VCN: 8167 LCN: 2391566 LEN: 126
    VCN: 8293 LCN: 2284425 LEN: 304
    VCN: 8597 LCN: 2179820 LEN: 110
    VCN: 8707 LCN: 2560656 LEN: 322
    VCN: 9029 LCN: 2812066 LEN: 93
    VCN: 9122 LCN: 2166757 LEN: 328
    VCN: 9450 LCN: 2177179 LEN: 88
    VCN: 9538 LCN: 90173 LEN: 335
    VCN: 9873 LCN: 543314 LEN: 80
    VCN: 9953 LCN: 2559672 LEN: 338
    VCN: 10291 LCN: 2791169 LEN: 78
    VCN: 10369 LCN: 1871243 LEN: 342
    VCN: 10711 LCN: 1792079 LEN: 74
    VCN: 10785 LCN: 180051 LEN: 346
    VCN: 11131 LCN: 1598333 LEN: 69
    VCN: 11200 LCN: 2188595 LEN: 351
    VCN: 11551 LCN: 2209458 LEN: 65
    VCN: 11616 LCN: 2179948 LEN: 352
    VCN: 11968 LCN: 2063382 LEN: 63
    VCN: 12031 LCN: 2218857 LEN: 17
    VCN: 12048 LCN: 2167213 LEN: 353
    VCN: 12401 LCN: 2068155 LEN: 78
    VCN: 12479 LCN: 2325918 LEN: 17
    VCN: 12496 LCN: 2177854 LEN: 365
    more ('q' to quit):
    VCN: 12861 LCN: 2479980 LEN: 65
    VCN: 12926 LCN: 2589648 LEN: 34
    VCN: 12960 LCN: 2168480 LEN: 383
    VCN: 13343 LCN: 2481639 LEN: 63
    VCN: 13406 LCN: 2600003 LEN: 34
    VCN: 13440 LCN: 2392009 LEN: 384
    VCN: 13824 LCN: 2458964 LEN: 62
    VCN: 13886 LCN: 2609991 LEN: 34
    VCN: 13920 LCN: 2059631 LEN: 205
    VCN: 14125 LCN: 1643586 LEN: 51
    VCN: 14176 LCN: 2293193 LEN: 389
    VCN: 14565 LCN: 2167968 LEN: 72
    VCN: 14637 LCN: 2591060 LEN: 51
    VCN: 14688 LCN: 2171942 LEN: 391
    VCN: 15079 LCN: 2480746 LEN: 69
    VCN: 15148 LCN: 2502200 LEN: 68
    VCN: 15216 LCN: 2219938 LEN: 394
    VCN: 15610 LCN: 2204502 LEN: 82
    VCN: 15692 LCN: 2582807 LEN: 68
    VCN: 15760 LCN: 1158805 LEN: 399
    VCN: 16159 LCN: 2168041 LEN: 76
    VCN: 16235 LCN: 2798382 LEN: 85
    VCN: 16320 LCN: 2170575 LEN: 203
    VCN: 16523 LCN: 2799079 LEN: 85
    more ('q' to quit):
    VCN: 16608 LCN: 1708210 LEN: 203
    VCN: 16811 LCN: 2815815 LEN: 85
    VCN: 16896 LCN: 157273 LEN: 404
    VCN: 17300 LCN: 854129 LEN: 102
    VCN: 17402 LCN: 2829296 LEN: 102
    VCN: 17504 LCN: 2883531 LEN: 419
    VCN: 17923 LCN: 2809129 LEN: 87
    VCN: 18010 LCN: 2766550 LEN: 105
    VCN: 18115 LCN: 2287803 LEN: 199
    VCN: 18314 LCN: 2456794 LEN: 118
    VCN: 18432 LCN: 2176267 LEN: 423
    VCN: 18855 LCN: 2306638 LEN: 98
    VCN: 18953 LCN: 1994350 LEN: 120
    VCN: 19073 LCN: 1280453 LEN: 200
    VCN: 19273 LCN: 2168119 LEN: 138
    VCN: 19411 LCN: 2284221 LEN: 197
    VCN: 19608 LCN: 1868690 LEN: 150
    VCN: 19758 LCN: 2491310 LEN: 187
    VCN: 19945 LCN: 2483073 LEN: 151
    VCN: 20096 LCN: 2594851 LEN: 183
    VCN: 20279 LCN: 1868527 LEN: 156
    VCN: 20435 LCN: 2172345 LEN: 200
    VCN: 20635 LCN: 2623014 LEN: 151
    VCN: 20786 LCN: 2479269 LEN: 200
    more ('q' to quit):
    VCN: 20986 LCN: 2300299 LEN: 156
    VCN: 21142 LCN: 2186850 LEN: 192
    VCN: 21334 LCN: 2512740 LEN: 175
    VCN: 21509 LCN: 1753435 LEN: 193
    VCN: 21702 LCN: 1281897 LEN: 177
    VCN: 21879 LCN: 2558254 LEN: 194
    VCN: 22073 LCN: 1530465 LEN: 177
    VCN: 22250 LCN: 1283329 LEN: 188
    VCN: 22438 LCN: 2209694 LEN: 429
    VCN: 22867 LCN: 242236 LEN: 164
    VCN: 23031 LCN: 240867 LEN: 178
    VCN: 23209 LCN: 2869945 LEN: 436
    VCN: 23645 LCN: 2479534 LEN: 178
    VCN: 23823 LCN: 2789327 LEN: 178
    VCN: 24001 LCN: 1282077 LEN: 179
    VCN: 24180 LCN: 2314613 LEN: 180
    VCN: 24360 LCN: 2871359 LEN: 442
    VCN: 24802 LCN: 2513850 LEN: 129
    VCN: 24931 LCN: 1556977 LEN: 465
    VCN: 25396 LCN: 2176692 LEN: 110
    VCN: 25506 LCN: 89547 LEN: 467
    VCN: 25973 LCN: 241313 LEN: 4
    Enumerate file clusters: STATUS_SUCCESS

    The BufferLog.TXT was extracted from a WinZip file...

    So I see two possibilities:

    1. WinZip causes lot's of fragmentation

    or

    2. The free space was already fragmented...

    I think case 2 was the case ;)

    Since I first deleted a compressed file etc... :D

    And I know I deleted many files before making the compressed file etc...

    So in other words... the free space was already pretty much fragmented ;)

    It would be nice to have a simple little tool... just to defragment a single
    file for testing purposes...

    Also I wonder about the Logic Cluster Numbers...

    How does that work... performance wise ?

    Are sequential Logic Cluster Numbers always garanteed to achieve maximum
    performance ?

    That would be amazing... so I don't think that's necessarily the case...

    I read something about harddisk liking to writing/filling as many clustors
    in a single 'cylinder'... a hollow cylinder that is... only writing the
    rings of the 'cylinder'

    At least that's how I imagine it could work:

    For example:

    Platter 1. Inner track 0 is filled.

    Platter 2. Inner track 0 is filled

    Platter 3. Inner track 0 is filled.

    /\
    | this is what they call a cylinder i think... ;)
    \/

    Then when all tracks 'vertically' are filled.

    Platter 1. Inner track 1 is filled

    Platter 2. Inner track 1 is filled

    Platter 3. Inner track 1 is filled.

    Etc.

    This should be done to minimize track to track movement etc...

    So I wonder how windows xp 'distributes' the logic cluster numbers across
    the disk...

    Does it first fill up all tracks on a platter before proceeding to the next
    platter...

    Like so:

    Case 1:

    Platter 1, Track 1, Track 2, Track 3, Track 4, Track 5

    Or does it use the 'cylinder' performance trick ;)

    Case 2:

    Platter 1, Track 1, Track 4

    Platter 2, Track 2, Track 5

    Platter 3, Track 3, Track 6

    Etc :)

    That would be something... that would mean Windows XP optimizes
    cluster/track placement for each disk differently... since each disk has
    different geometry properties...

    Whatever the case is...

    I will assume placing all logical cluster numbers sequantially will still
    give much better performance than randomly.

    Skybuck.
  38. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Hmm...

    Here is a little link about harddisk's layout and performance optimizations
    though it's kinda old.

    http://home.no.net/tkos/info/hd.html
  39. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    So what I am interested in...

    Is a little bit of information about

    Harddisk numbering in general...

    Like sector numbering, track numbering, platter numbering, head numbering,
    ring numbering, etc.

    How it corresponds to the physical location...

    And ofcourse how harddisk read these ;)
  40. Archived from groups: alt.comp.hardware,alt.comp.lang.borland-delphi,comp.sys.ibm.pc.hardware.storage,microsoft.public.win32.programmer,microsoft.public.windowsxp.hardware (More info?)

    Hmm.. further more it seems... this numbering is called

    Logical Block Addressing :) and it's now the dominant form of addressing the
    disk :D

    http://www.pcguide.com/ref/hdd/bios/modesLBA-c.html
Ask a new question

Read More

Hardware Hard Drives Windows XP