Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
I know this is a kind of stubid question, but what does the buffer on hard drive do?
I know this is a kind of stubid question, but what does the buffer on hard drive do?
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
it buffers
ok...enough with the schmarty pants
Buffer is a place to hold data that comes from the drive, that may available
before the CPU is ready for it. If that happens, then when CPU is ready, if
the data isn't available, it has to call the drive up and say "hey you
remember that data i asked for a few nanoseconds ago, well, I need it now"
Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
it again. With the buffer, the data is stored in some RAM on the drive
electronics so that when the CPU says "OK" ready, the drive says "here you
are right in my hand" and doesn't have to go look again. The advantage is
that its a lot faster to get data from the buffer than from the disk
platters.
It works in a similar way for writing data. If the CPU can dump the data to
the drives buffer to be written when the drive is good and ready, it can say
"good, on to the next thing" instead of having to wait until the disk is
availalbe to perform the the write ....
Make sense. I hope so. At end of the day, more buffer is better for disk
intensive operations.
"Dan Irwin" <harryguy082589@aol.com> wrote in message
news:2a779348.0408260936.2d99d539@posting.google.com...
> I know this is a kind of stubid question, but what does the buffer on hard
drive do?
it buffers
ok...enough with the schmarty pants
Buffer is a place to hold data that comes from the drive, that may available
before the CPU is ready for it. If that happens, then when CPU is ready, if
the data isn't available, it has to call the drive up and say "hey you
remember that data i asked for a few nanoseconds ago, well, I need it now"
Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
it again. With the buffer, the data is stored in some RAM on the drive
electronics so that when the CPU says "OK" ready, the drive says "here you
are right in my hand" and doesn't have to go look again. The advantage is
that its a lot faster to get data from the buffer than from the disk
platters.
It works in a similar way for writing data. If the CPU can dump the data to
the drives buffer to be written when the drive is good and ready, it can say
"good, on to the next thing" instead of having to wait until the disk is
availalbe to perform the the write ....
Make sense. I hope so. At end of the day, more buffer is better for disk
intensive operations.
"Dan Irwin" <harryguy082589@aol.com> wrote in message
news:2a779348.0408260936.2d99d539@posting.google.com...
> I know this is a kind of stubid question, but what does the buffer on hard
drive do?
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Ruth wrote:
> it buffers
>
> ok...enough with the schmarty pants
> Buffer is a place to hold data that comes from the drive, that may available
> before the CPU is ready for it. If that happens, then when CPU is ready, if
> the data isn't available, it has to call the drive up and say "hey you
> remember that data i asked for a few nanoseconds ago, well, I need it now"
> Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> it again. With the buffer, the data is stored in some RAM on the drive
> electronics so that when the CPU says "OK" ready, the drive says "here you
> are right in my hand" and doesn't have to go look again. The advantage is
> that its a lot faster to get data from the buffer than from the disk
> platters.
> It works in a similar way for writing data. If the CPU can dump the data to
> the drives buffer to be written when the drive is good and ready, it can say
> "good, on to the next thing" instead of having to wait until the disk is
> availalbe to perform the the write ....
>
> Make sense. I hope so. At end of the day, more buffer is better for disk
> intensive operations.
A couple of embellishments -
The drive can be clever about its read buffers, and pre-load into them
sectors that haven't yet been identified as desired, but which follow
ones that have been, under the assumption that data is often read
sequentially.
Write buffering has implications for error recovery -- what happens if
the power fails (or the machine reboots) while the drive's buffers are
full of information that has not yet been written to the disk? As a
result, it is often turned off in high reliability systems.
>
> "Dan Irwin" <harryguy082589@aol.com> wrote in message
> news:2a779348.0408260936.2d99d539@posting.google.com...
>
>>I know this is a kind of stubid question, but what does the buffer on hard
>
> drive do?
>
>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Ruth wrote:
> it buffers
>
> ok...enough with the schmarty pants
> Buffer is a place to hold data that comes from the drive, that may available
> before the CPU is ready for it. If that happens, then when CPU is ready, if
> the data isn't available, it has to call the drive up and say "hey you
> remember that data i asked for a few nanoseconds ago, well, I need it now"
> Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> it again. With the buffer, the data is stored in some RAM on the drive
> electronics so that when the CPU says "OK" ready, the drive says "here you
> are right in my hand" and doesn't have to go look again. The advantage is
> that its a lot faster to get data from the buffer than from the disk
> platters.
> It works in a similar way for writing data. If the CPU can dump the data to
> the drives buffer to be written when the drive is good and ready, it can say
> "good, on to the next thing" instead of having to wait until the disk is
> availalbe to perform the the write ....
>
> Make sense. I hope so. At end of the day, more buffer is better for disk
> intensive operations.
A couple of embellishments -
The drive can be clever about its read buffers, and pre-load into them
sectors that haven't yet been identified as desired, but which follow
ones that have been, under the assumption that data is often read
sequentially.
Write buffering has implications for error recovery -- what happens if
the power fails (or the machine reboots) while the drive's buffers are
full of information that has not yet been written to the disk? As a
result, it is often turned off in high reliability systems.
>
> "Dan Irwin" <harryguy082589@aol.com> wrote in message
> news:2a779348.0408260936.2d99d539@posting.google.com...
>
>>I know this is a kind of stubid question, but what does the buffer on hard
>
> drive do?
>
>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Where does the ram play into this?
Also just so i have it right becacue of the way buffer functions it is
something that would not affect the seek time on a hard drive
CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> Ruth wrote:
>
> > it buffers
> >
> > ok...enough with the schmarty pants
> > Buffer is a place to hold data that comes from the drive, that may available
> > before the CPU is ready for it. If that happens, then when CPU is ready, if
> > the data isn't available, it has to call the drive up and say "hey you
> > remember that data i asked for a few nanoseconds ago, well, I need it now"
> > Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> > it again. With the buffer, the data is stored in some RAM on the drive
> > electronics so that when the CPU says "OK" ready, the drive says "here you
> > are right in my hand" and doesn't have to go look again. The advantage is
> > that its a lot faster to get data from the buffer than from the disk
> > platters.
> > It works in a similar way for writing data. If the CPU can dump the data to
> > the drives buffer to be written when the drive is good and ready, it can say
> > "good, on to the next thing" instead of having to wait until the disk is
> > availalbe to perform the the write ....
> >
> > Make sense. I hope so. At end of the day, more buffer is better for disk
> > intensive operations.
>
> A couple of embellishments -
>
> The drive can be clever about its read buffers, and pre-load into them
> sectors that haven't yet been identified as desired, but which follow
> ones that have been, under the assumption that data is often read
> sequentially.
>
> Write buffering has implications for error recovery -- what happens if
> the power fails (or the machine reboots) while the drive's buffers are
> full of information that has not yet been written to the disk? As a
> result, it is often turned off in high reliability systems.
>
> >
> > "Dan Irwin" <harryguy082589@aol.com> wrote in message
> > news:2a779348.0408260936.2d99d539@posting.google.com...
> >
> >>I know this is a kind of stubid question, but what does the buffer on hard
> >
> > drive do?
> >
> >
Where does the ram play into this?
Also just so i have it right becacue of the way buffer functions it is
something that would not affect the seek time on a hard drive
CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> Ruth wrote:
>
> > it buffers
> >
> > ok...enough with the schmarty pants
> > Buffer is a place to hold data that comes from the drive, that may available
> > before the CPU is ready for it. If that happens, then when CPU is ready, if
> > the data isn't available, it has to call the drive up and say "hey you
> > remember that data i asked for a few nanoseconds ago, well, I need it now"
> > Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> > it again. With the buffer, the data is stored in some RAM on the drive
> > electronics so that when the CPU says "OK" ready, the drive says "here you
> > are right in my hand" and doesn't have to go look again. The advantage is
> > that its a lot faster to get data from the buffer than from the disk
> > platters.
> > It works in a similar way for writing data. If the CPU can dump the data to
> > the drives buffer to be written when the drive is good and ready, it can say
> > "good, on to the next thing" instead of having to wait until the disk is
> > availalbe to perform the the write ....
> >
> > Make sense. I hope so. At end of the day, more buffer is better for disk
> > intensive operations.
>
> A couple of embellishments -
>
> The drive can be clever about its read buffers, and pre-load into them
> sectors that haven't yet been identified as desired, but which follow
> ones that have been, under the assumption that data is often read
> sequentially.
>
> Write buffering has implications for error recovery -- what happens if
> the power fails (or the machine reboots) while the drive's buffers are
> full of information that has not yet been written to the disk? As a
> result, it is often turned off in high reliability systems.
>
> >
> > "Dan Irwin" <harryguy082589@aol.com> wrote in message
> > news:2a779348.0408260936.2d99d539@posting.google.com...
> >
> >>I know this is a kind of stubid question, but what does the buffer on hard
> >
> > drive do?
> >
> >
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Dan Irwin wrote:
> Where does the ram play into this?
The computer also has buffers in RAM above and beyond those actually
on the drive.
>
> Also just so i have it right becacue of the way buffer functions it is
> something that would not affect the seek time on a hard drive
>
It depends on what you mean. With enough buffers, the computer/drive
combination can also be clever about the order in which pending accesses
are done, which can affect the apparent aggregate seek time (i.e.
avoiding having to seek, or shortening the seeks done, is as good as
brute force speeding up seeks). The devil is in the details. But I
would say the size of the buffers doesn't directly affect seek time.
> CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>
>>Ruth wrote:
>>
>>
>>>it buffers
>>>
>>>ok...enough with the schmarty pants
>>>Buffer is a place to hold data that comes from the drive, that may available
>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>the data isn't available, it has to call the drive up and say "hey you
>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>that its a lot faster to get data from the buffer than from the disk
>>>platters.
>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>the drives buffer to be written when the drive is good and ready, it can say
>>>"good, on to the next thing" instead of having to wait until the disk is
>>>availalbe to perform the the write ....
>>>
>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>intensive operations.
>>
>>A couple of embellishments -
>>
>>The drive can be clever about its read buffers, and pre-load into them
>>sectors that haven't yet been identified as desired, but which follow
>>ones that have been, under the assumption that data is often read
>>sequentially.
>>
>>Write buffering has implications for error recovery -- what happens if
>>the power fails (or the machine reboots) while the drive's buffers are
>>full of information that has not yet been written to the disk? As a
>>result, it is often turned off in high reliability systems.
>>
>>
>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>
>>>
>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>
>>>drive do?
>>>
>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Dan Irwin wrote:
> Where does the ram play into this?
The computer also has buffers in RAM above and beyond those actually
on the drive.
>
> Also just so i have it right becacue of the way buffer functions it is
> something that would not affect the seek time on a hard drive
>
It depends on what you mean. With enough buffers, the computer/drive
combination can also be clever about the order in which pending accesses
are done, which can affect the apparent aggregate seek time (i.e.
avoiding having to seek, or shortening the seeks done, is as good as
brute force speeding up seeks). The devil is in the details. But I
would say the size of the buffers doesn't directly affect seek time.
> CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>
>>Ruth wrote:
>>
>>
>>>it buffers
>>>
>>>ok...enough with the schmarty pants
>>>Buffer is a place to hold data that comes from the drive, that may available
>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>the data isn't available, it has to call the drive up and say "hey you
>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>that its a lot faster to get data from the buffer than from the disk
>>>platters.
>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>the drives buffer to be written when the drive is good and ready, it can say
>>>"good, on to the next thing" instead of having to wait until the disk is
>>>availalbe to perform the the write ....
>>>
>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>intensive operations.
>>
>>A couple of embellishments -
>>
>>The drive can be clever about its read buffers, and pre-load into them
>>sectors that haven't yet been identified as desired, but which follow
>>ones that have been, under the assumption that data is often read
>>sequentially.
>>
>>Write buffering has implications for error recovery -- what happens if
>>the power fails (or the machine reboots) while the drive's buffers are
>>full of information that has not yet been written to the disk? As a
>>result, it is often turned off in high reliability systems.
>>
>>
>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>
>>>
>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>
>>>drive do?
>>>
>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
could conceivably have the documented average seek time, while the
16mb one would be faster in real life application
CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> Dan Irwin wrote:
>
> > Where does the ram play into this?
>
> The computer also has buffers in RAM above and beyond those actually
> on the drive.
> >
> > Also just so i have it right becacue of the way buffer functions it is
> > something that would not affect the seek time on a hard drive
> >
> It depends on what you mean. With enough buffers, the computer/drive
> combination can also be clever about the order in which pending accesses
> are done, which can affect the apparent aggregate seek time (i.e.
> avoiding having to seek, or shortening the seeks done, is as good as
> brute force speeding up seeks). The devil is in the details. But I
> would say the size of the buffers doesn't directly affect seek time.
>
> > CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >
> >>Ruth wrote:
> >>
> >>
> >>>it buffers
> >>>
> >>>ok...enough with the schmarty pants
> >>>Buffer is a place to hold data that comes from the drive, that may available
> >>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>the data isn't available, it has to call the drive up and say "hey you
> >>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>that its a lot faster to get data from the buffer than from the disk
> >>>platters.
> >>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>the drives buffer to be written when the drive is good and ready, it can say
> >>>"good, on to the next thing" instead of having to wait until the disk is
> >>>availalbe to perform the the write ....
> >>>
> >>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>intensive operations.
> >>
> >>A couple of embellishments -
> >>
> >>The drive can be clever about its read buffers, and pre-load into them
> >>sectors that haven't yet been identified as desired, but which follow
> >>ones that have been, under the assumption that data is often read
> >>sequentially.
> >>
> >>Write buffering has implications for error recovery -- what happens if
> >>the power fails (or the machine reboots) while the drive's buffers are
> >>full of information that has not yet been written to the disk? As a
> >>result, it is often turned off in high reliability systems.
> >>
> >>
> >>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>
> >>>
> >>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>
> >>>drive do?
> >>>
> >>>
So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
could conceivably have the documented average seek time, while the
16mb one would be faster in real life application
CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> Dan Irwin wrote:
>
> > Where does the ram play into this?
>
> The computer also has buffers in RAM above and beyond those actually
> on the drive.
> >
> > Also just so i have it right becacue of the way buffer functions it is
> > something that would not affect the seek time on a hard drive
> >
> It depends on what you mean. With enough buffers, the computer/drive
> combination can also be clever about the order in which pending accesses
> are done, which can affect the apparent aggregate seek time (i.e.
> avoiding having to seek, or shortening the seeks done, is as good as
> brute force speeding up seeks). The devil is in the details. But I
> would say the size of the buffers doesn't directly affect seek time.
>
> > CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >
> >>Ruth wrote:
> >>
> >>
> >>>it buffers
> >>>
> >>>ok...enough with the schmarty pants
> >>>Buffer is a place to hold data that comes from the drive, that may available
> >>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>the data isn't available, it has to call the drive up and say "hey you
> >>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>that its a lot faster to get data from the buffer than from the disk
> >>>platters.
> >>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>the drives buffer to be written when the drive is good and ready, it can say
> >>>"good, on to the next thing" instead of having to wait until the disk is
> >>>availalbe to perform the the write ....
> >>>
> >>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>intensive operations.
> >>
> >>A couple of embellishments -
> >>
> >>The drive can be clever about its read buffers, and pre-load into them
> >>sectors that haven't yet been identified as desired, but which follow
> >>ones that have been, under the assumption that data is often read
> >>sequentially.
> >>
> >>Write buffering has implications for error recovery -- what happens if
> >>the power fails (or the machine reboots) while the drive's buffers are
> >>full of information that has not yet been written to the disk? As a
> >>result, it is often turned off in high reliability systems.
> >>
> >>
> >>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>
> >>>
> >>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>
> >>>drive do?
> >>>
> >>>
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Dan Irwin wrote:
> So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> could conceivably have the documented average seek time, while the
> 16mb one would be faster in real life application
Could be.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>Where does the ram play into this?
>>
>>The computer also has buffers in RAM above and beyond those actually
>>on the drive.
>>
>>>Also just so i have it right becacue of the way buffer functions it is
>>>something that would not affect the seek time on a hard drive
>>>
>>
>>It depends on what you mean. With enough buffers, the computer/drive
>>combination can also be clever about the order in which pending accesses
>>are done, which can affect the apparent aggregate seek time (i.e.
>>avoiding having to seek, or shortening the seeks done, is as good as
>>brute force speeding up seeks). The devil is in the details. But I
>>would say the size of the buffers doesn't directly affect seek time.
>>
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>
>>>
>>>>Ruth wrote:
>>>>
>>>>
>>>>
>>>>>it buffers
>>>>>
>>>>>ok...enough with the schmarty pants
>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>platters.
>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>availalbe to perform the the write ....
>>>>>
>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>intensive operations.
>>>>
>>>>A couple of embellishments -
>>>>
>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>sectors that haven't yet been identified as desired, but which follow
>>>>ones that have been, under the assumption that data is often read
>>>>sequentially.
>>>>
>>>>Write buffering has implications for error recovery -- what happens if
>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>full of information that has not yet been written to the disk? As a
>>>>result, it is often turned off in high reliability systems.
>>>>
>>>>
>>>>
>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>
>>>>>
>>>>>
>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>
>>>>>drive do?
>>>>>
>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Dan Irwin wrote:
> So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> could conceivably have the documented average seek time, while the
> 16mb one would be faster in real life application
Could be.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>Where does the ram play into this?
>>
>>The computer also has buffers in RAM above and beyond those actually
>>on the drive.
>>
>>>Also just so i have it right becacue of the way buffer functions it is
>>>something that would not affect the seek time on a hard drive
>>>
>>
>>It depends on what you mean. With enough buffers, the computer/drive
>>combination can also be clever about the order in which pending accesses
>>are done, which can affect the apparent aggregate seek time (i.e.
>>avoiding having to seek, or shortening the seeks done, is as good as
>>brute force speeding up seeks). The devil is in the details. But I
>>would say the size of the buffers doesn't directly affect seek time.
>>
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>
>>>
>>>>Ruth wrote:
>>>>
>>>>
>>>>
>>>>>it buffers
>>>>>
>>>>>ok...enough with the schmarty pants
>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>platters.
>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>availalbe to perform the the write ....
>>>>>
>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>intensive operations.
>>>>
>>>>A couple of embellishments -
>>>>
>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>sectors that haven't yet been identified as desired, but which follow
>>>>ones that have been, under the assumption that data is often read
>>>>sequentially.
>>>>
>>>>Write buffering has implications for error recovery -- what happens if
>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>full of information that has not yet been written to the disk? As a
>>>>result, it is often turned off in high reliability systems.
>>>>
>>>>
>>>>
>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>
>>>>>
>>>>>
>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>
>>>>>drive do?
>>>>>
>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Now lets say you had one drive with a 16mb buffer and 12ms avg seek
time and one with 8mb buffer and a 10ms avg seek time. Which would be
better in pratical application?
CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
> Dan Irwin wrote:
>
> > So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> > could conceivably have the documented average seek time, while the
> > 16mb one would be faster in real life application
>
> Could be.
> >
> > CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> >
> >>Dan Irwin wrote:
> >>
> >>
> >>>Where does the ram play into this?
> >>
> >>The computer also has buffers in RAM above and beyond those actually
> >>on the drive.
> >>
> >>>Also just so i have it right becacue of the way buffer functions it is
> >>>something that would not affect the seek time on a hard drive
> >>>
> >>
> >>It depends on what you mean. With enough buffers, the computer/drive
> >>combination can also be clever about the order in which pending accesses
> >>are done, which can affect the apparent aggregate seek time (i.e.
> >>avoiding having to seek, or shortening the seeks done, is as good as
> >>brute force speeding up seeks). The devil is in the details. But I
> >>would say the size of the buffers doesn't directly affect seek time.
> >>
> >>
> >>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >>>
> >>>
> >>>>Ruth wrote:
> >>>>
> >>>>
> >>>>
> >>>>>it buffers
> >>>>>
> >>>>>ok...enough with the schmarty pants
> >>>>>Buffer is a place to hold data that comes from the drive, that may available
> >>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>>>the data isn't available, it has to call the drive up and say "hey you
> >>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>>>that its a lot faster to get data from the buffer than from the disk
> >>>>>platters.
> >>>>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>>>the drives buffer to be written when the drive is good and ready, it can say
> >>>>>"good, on to the next thing" instead of having to wait until the disk is
> >>>>>availalbe to perform the the write ....
> >>>>>
> >>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>>>intensive operations.
> >>>>
> >>>>A couple of embellishments -
> >>>>
> >>>>The drive can be clever about its read buffers, and pre-load into them
> >>>>sectors that haven't yet been identified as desired, but which follow
> >>>>ones that have been, under the assumption that data is often read
> >>>>sequentially.
> >>>>
> >>>>Write buffering has implications for error recovery -- what happens if
> >>>>the power fails (or the machine reboots) while the drive's buffers are
> >>>>full of information that has not yet been written to the disk? As a
> >>>>result, it is often turned off in high reliability systems.
> >>>>
> >>>>
> >>>>
> >>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>>>
> >>>>>drive do?
> >>>>>
> >>>>>
Now lets say you had one drive with a 16mb buffer and 12ms avg seek
time and one with 8mb buffer and a 10ms avg seek time. Which would be
better in pratical application?
CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
> Dan Irwin wrote:
>
> > So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> > could conceivably have the documented average seek time, while the
> > 16mb one would be faster in real life application
>
> Could be.
> >
> > CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> >
> >>Dan Irwin wrote:
> >>
> >>
> >>>Where does the ram play into this?
> >>
> >>The computer also has buffers in RAM above and beyond those actually
> >>on the drive.
> >>
> >>>Also just so i have it right becacue of the way buffer functions it is
> >>>something that would not affect the seek time on a hard drive
> >>>
> >>
> >>It depends on what you mean. With enough buffers, the computer/drive
> >>combination can also be clever about the order in which pending accesses
> >>are done, which can affect the apparent aggregate seek time (i.e.
> >>avoiding having to seek, or shortening the seeks done, is as good as
> >>brute force speeding up seeks). The devil is in the details. But I
> >>would say the size of the buffers doesn't directly affect seek time.
> >>
> >>
> >>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >>>
> >>>
> >>>>Ruth wrote:
> >>>>
> >>>>
> >>>>
> >>>>>it buffers
> >>>>>
> >>>>>ok...enough with the schmarty pants
> >>>>>Buffer is a place to hold data that comes from the drive, that may available
> >>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>>>the data isn't available, it has to call the drive up and say "hey you
> >>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>>>that its a lot faster to get data from the buffer than from the disk
> >>>>>platters.
> >>>>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>>>the drives buffer to be written when the drive is good and ready, it can say
> >>>>>"good, on to the next thing" instead of having to wait until the disk is
> >>>>>availalbe to perform the the write ....
> >>>>>
> >>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>>>intensive operations.
> >>>>
> >>>>A couple of embellishments -
> >>>>
> >>>>The drive can be clever about its read buffers, and pre-load into them
> >>>>sectors that haven't yet been identified as desired, but which follow
> >>>>ones that have been, under the assumption that data is often read
> >>>>sequentially.
> >>>>
> >>>>Write buffering has implications for error recovery -- what happens if
> >>>>the power fails (or the machine reboots) while the drive's buffers are
> >>>>full of information that has not yet been written to the disk? As a
> >>>>result, it is often turned off in high reliability systems.
> >>>>
> >>>>
> >>>>
> >>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>>>
> >>>>>
> >>>>>
> >>>>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>>>
> >>>>>drive do?
> >>>>>
> >>>>>
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Dan Irwin wrote:
> Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> time and one with 8mb buffer and a 10ms avg seek time. Which would be
> better in pratical application?
Whichever was cheaper.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
>>>could conceivably have the documented average seek time, while the
>>>16mb one would be faster in real life application
>>
>>Could be.
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>>>
>>>
>>>>Dan Irwin wrote:
>>>>
>>>>
>>>>
>>>>>Where does the ram play into this?
>>>>
>>>>The computer also has buffers in RAM above and beyond those actually
>>>>on the drive.
>>>>
>>>>
>>>>>Also just so i have it right becacue of the way buffer functions it is
>>>>>something that would not affect the seek time on a hard drive
>>>>>
>>>>
>>>>It depends on what you mean. With enough buffers, the computer/drive
>>>>combination can also be clever about the order in which pending accesses
>>>>are done, which can affect the apparent aggregate seek time (i.e.
>>>>avoiding having to seek, or shortening the seeks done, is as good as
>>>>brute force speeding up seeks). The devil is in the details. But I
>>>>would say the size of the buffers doesn't directly affect seek time.
>>>>
>>>>
>>>>
>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>>>
>>>>>
>>>>>
>>>>>>Ruth wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>it buffers
>>>>>>>
>>>>>>>ok...enough with the schmarty pants
>>>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>>>platters.
>>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>>>availalbe to perform the the write ....
>>>>>>>
>>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>>>intensive operations.
>>>>>>
>>>>>>A couple of embellishments -
>>>>>>
>>>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>>>sectors that haven't yet been identified as desired, but which follow
>>>>>>ones that have been, under the assumption that data is often read
>>>>>>sequentially.
>>>>>>
>>>>>>Write buffering has implications for error recovery -- what happens if
>>>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>>>full of information that has not yet been written to the disk? As a
>>>>>>result, it is often turned off in high reliability systems.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>>>
>>>>>>>drive do?
>>>>>>>
>>>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Dan Irwin wrote:
> Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> time and one with 8mb buffer and a 10ms avg seek time. Which would be
> better in pratical application?
Whichever was cheaper.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
>>>could conceivably have the documented average seek time, while the
>>>16mb one would be faster in real life application
>>
>>Could be.
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>>>
>>>
>>>>Dan Irwin wrote:
>>>>
>>>>
>>>>
>>>>>Where does the ram play into this?
>>>>
>>>>The computer also has buffers in RAM above and beyond those actually
>>>>on the drive.
>>>>
>>>>
>>>>>Also just so i have it right becacue of the way buffer functions it is
>>>>>something that would not affect the seek time on a hard drive
>>>>>
>>>>
>>>>It depends on what you mean. With enough buffers, the computer/drive
>>>>combination can also be clever about the order in which pending accesses
>>>>are done, which can affect the apparent aggregate seek time (i.e.
>>>>avoiding having to seek, or shortening the seeks done, is as good as
>>>>brute force speeding up seeks). The devil is in the details. But I
>>>>would say the size of the buffers doesn't directly affect seek time.
>>>>
>>>>
>>>>
>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>>>
>>>>>
>>>>>
>>>>>>Ruth wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>it buffers
>>>>>>>
>>>>>>>ok...enough with the schmarty pants
>>>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>>>platters.
>>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>>>availalbe to perform the the write ....
>>>>>>>
>>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>>>intensive operations.
>>>>>>
>>>>>>A couple of embellishments -
>>>>>>
>>>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>>>sectors that haven't yet been identified as desired, but which follow
>>>>>>ones that have been, under the assumption that data is often read
>>>>>>sequentially.
>>>>>>
>>>>>>Write buffering has implications for error recovery -- what happens if
>>>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>>>full of information that has not yet been written to the disk? As a
>>>>>>result, it is often turned off in high reliability systems.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>>>
>>>>>>>drive do?
>>>>>>>
>>>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Would any of this change in the case of a laptop?
CJT <abujlehc@prodigy.net> wrote in message news:<41313203.10705@prodigy.net>...
> Dan Irwin wrote:
>
> > Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> > time and one with 8mb buffer and a 10ms avg seek time. Which would be
> > better in pratical application?
>
> Whichever was cheaper.
>
> >
> > CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
> >
> >>Dan Irwin wrote:
> >>
> >>
> >>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> >>>could conceivably have the documented average seek time, while the
> >>>16mb one would be faster in real life application
> >>
> >>Could be.
> >>
> >>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> >>>
> >>>
> >>>>Dan Irwin wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Where does the ram play into this?
> >>>>
> >>>>The computer also has buffers in RAM above and beyond those actually
> >>>>on the drive.
> >>>>
> >>>>
> >>>>>Also just so i have it right becacue of the way buffer functions it is
> >>>>>something that would not affect the seek time on a hard drive
> >>>>>
> >>>>
> >>>>It depends on what you mean. With enough buffers, the computer/drive
> >>>>combination can also be clever about the order in which pending accesses
> >>>>are done, which can affect the apparent aggregate seek time (i.e.
> >>>>avoiding having to seek, or shortening the seeks done, is as good as
> >>>>brute force speeding up seeks). The devil is in the details. But I
> >>>>would say the size of the buffers doesn't directly affect seek time.
> >>>>
> >>>>
> >>>>
> >>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Ruth wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>it buffers
> >>>>>>>
> >>>>>>>ok...enough with the schmarty pants
> >>>>>>>Buffer is a place to hold data that comes from the drive, that may available
> >>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>>>>>the data isn't available, it has to call the drive up and say "hey you
> >>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>>>>>that its a lot faster to get data from the buffer than from the disk
> >>>>>>>platters.
> >>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>>>>>the drives buffer to be written when the drive is good and ready, it can say
> >>>>>>>"good, on to the next thing" instead of having to wait until the disk is
> >>>>>>>availalbe to perform the the write ....
> >>>>>>>
> >>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>>>>>intensive operations.
> >>>>>>
> >>>>>>A couple of embellishments -
> >>>>>>
> >>>>>>The drive can be clever about its read buffers, and pre-load into them
> >>>>>>sectors that haven't yet been identified as desired, but which follow
> >>>>>>ones that have been, under the assumption that data is often read
> >>>>>>sequentially.
> >>>>>>
> >>>>>>Write buffering has implications for error recovery -- what happens if
> >>>>>>the power fails (or the machine reboots) while the drive's buffers are
> >>>>>>full of information that has not yet been written to the disk? As a
> >>>>>>result, it is often turned off in high reliability systems.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>>>>>
> >>>>>>>drive do?
> >>>>>>>
> >>>>>>>
Would any of this change in the case of a laptop?
CJT <abujlehc@prodigy.net> wrote in message news:<41313203.10705@prodigy.net>...
> Dan Irwin wrote:
>
> > Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> > time and one with 8mb buffer and a 10ms avg seek time. Which would be
> > better in pratical application?
>
> Whichever was cheaper.
>
> >
> > CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
> >
> >>Dan Irwin wrote:
> >>
> >>
> >>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
> >>>could conceivably have the documented average seek time, while the
> >>>16mb one would be faster in real life application
> >>
> >>Could be.
> >>
> >>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
> >>>
> >>>
> >>>>Dan Irwin wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Where does the ram play into this?
> >>>>
> >>>>The computer also has buffers in RAM above and beyond those actually
> >>>>on the drive.
> >>>>
> >>>>
> >>>>>Also just so i have it right becacue of the way buffer functions it is
> >>>>>something that would not affect the seek time on a hard drive
> >>>>>
> >>>>
> >>>>It depends on what you mean. With enough buffers, the computer/drive
> >>>>combination can also be clever about the order in which pending accesses
> >>>>are done, which can affect the apparent aggregate seek time (i.e.
> >>>>avoiding having to seek, or shortening the seeks done, is as good as
> >>>>brute force speeding up seeks). The devil is in the details. But I
> >>>>would say the size of the buffers doesn't directly affect seek time.
> >>>>
> >>>>
> >>>>
> >>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Ruth wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>it buffers
> >>>>>>>
> >>>>>>>ok...enough with the schmarty pants
> >>>>>>>Buffer is a place to hold data that comes from the drive, that may available
> >>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
> >>>>>>>the data isn't available, it has to call the drive up and say "hey you
> >>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
> >>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
> >>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
> >>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
> >>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
> >>>>>>>that its a lot faster to get data from the buffer than from the disk
> >>>>>>>platters.
> >>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
> >>>>>>>the drives buffer to be written when the drive is good and ready, it can say
> >>>>>>>"good, on to the next thing" instead of having to wait until the disk is
> >>>>>>>availalbe to perform the the write ....
> >>>>>>>
> >>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
> >>>>>>>intensive operations.
> >>>>>>
> >>>>>>A couple of embellishments -
> >>>>>>
> >>>>>>The drive can be clever about its read buffers, and pre-load into them
> >>>>>>sectors that haven't yet been identified as desired, but which follow
> >>>>>>ones that have been, under the assumption that data is often read
> >>>>>>sequentially.
> >>>>>>
> >>>>>>Write buffering has implications for error recovery -- what happens if
> >>>>>>the power fails (or the machine reboots) while the drive's buffers are
> >>>>>>full of information that has not yet been written to the disk? As a
> >>>>>>result, it is often turned off in high reliability systems.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
> >>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
> >>>>>>>
> >>>>>>>drive do?
> >>>>>>>
> >>>>>>>
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Dan Irwin wrote:
> Would any of this change in the case of a laptop?
Perhaps. Another metric to consider in the case of a laptop is power
consumption. You might be willing to pay a bit of a premium for
something that won't drain your battery.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<41313203.10705@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>>>time and one with 8mb buffer and a 10ms avg seek time. Which would be
>>>better in pratical application?
>>
>>Whichever was cheaper.
>>
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
>>>
>>>
>>>>Dan Irwin wrote:
>>>>
>>>>
>>>>
>>>>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
>>>>>could conceivably have the documented average seek time, while the
>>>>>16mb one would be faster in real life application
>>>>
>>>>Could be.
>>>>
>>>>
>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>>>>>
>>>>>
>>>>>
>>>>>>Dan Irwin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Where does the ram play into this?
>>>>>>
>>>>>>The computer also has buffers in RAM above and beyond those actually
>>>>>>on the drive.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Also just so i have it right becacue of the way buffer functions it is
>>>>>>>something that would not affect the seek time on a hard drive
>>>>>>>
>>>>>>
>>>>>>It depends on what you mean. With enough buffers, the computer/drive
>>>>>>combination can also be clever about the order in which pending accesses
>>>>>>are done, which can affect the apparent aggregate seek time (i.e.
>>>>>>avoiding having to seek, or shortening the seeks done, is as good as
>>>>>>brute force speeding up seeks). The devil is in the details. But I
>>>>>>would say the size of the buffers doesn't directly affect seek time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Ruth wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>it buffers
>>>>>>>>>
>>>>>>>>>ok...enough with the schmarty pants
>>>>>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>>>>>platters.
>>>>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>>>>>availalbe to perform the the write ....
>>>>>>>>>
>>>>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>>>>>intensive operations.
>>>>>>>>
>>>>>>>>A couple of embellishments -
>>>>>>>>
>>>>>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>>>>>sectors that haven't yet been identified as desired, but which follow
>>>>>>>>ones that have been, under the assumption that data is often read
>>>>>>>>sequentially.
>>>>>>>>
>>>>>>>>Write buffering has implications for error recovery -- what happens if
>>>>>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>>>>>full of information that has not yet been written to the disk? As a
>>>>>>>>result, it is often turned off in high reliability systems.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>>>>>
>>>>>>>>>drive do?
>>>>>>>>>
>>>>>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Dan Irwin wrote:
> Would any of this change in the case of a laptop?
Perhaps. Another metric to consider in the case of a laptop is power
consumption. You might be willing to pay a bit of a premium for
something that won't drain your battery.
>
> CJT <abujlehc@prodigy.net> wrote in message news:<41313203.10705@prodigy.net>...
>
>>Dan Irwin wrote:
>>
>>
>>>Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>>>time and one with 8mb buffer and a 10ms avg seek time. Which would be
>>>better in pratical application?
>>
>>Whichever was cheaper.
>>
>>
>>>CJT <abujlehc@prodigy.net> wrote in message news:<412FF890.2060105@prodigy.net>...
>>>
>>>
>>>>Dan Irwin wrote:
>>>>
>>>>
>>>>
>>>>>So just to confirm a hard drive with a 8mb buffer and a 16mb buffer
>>>>>could conceivably have the documented average seek time, while the
>>>>>16mb one would be faster in real life application
>>>>
>>>>Could be.
>>>>
>>>>
>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412EF106.9030607@prodigy.net>...
>>>>>
>>>>>
>>>>>
>>>>>>Dan Irwin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Where does the ram play into this?
>>>>>>
>>>>>>The computer also has buffers in RAM above and beyond those actually
>>>>>>on the drive.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Also just so i have it right becacue of the way buffer functions it is
>>>>>>>something that would not affect the seek time on a hard drive
>>>>>>>
>>>>>>
>>>>>>It depends on what you mean. With enough buffers, the computer/drive
>>>>>>combination can also be clever about the order in which pending accesses
>>>>>>are done, which can affect the apparent aggregate seek time (i.e.
>>>>>>avoiding having to seek, or shortening the seeks done, is as good as
>>>>>>brute force speeding up seeks). The devil is in the details. But I
>>>>>>would say the size of the buffers doesn't directly affect seek time.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>CJT <abujlehc@prodigy.net> wrote in message news:<412E28B2.3040208@prodigy.net>...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Ruth wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>it buffers
>>>>>>>>>
>>>>>>>>>ok...enough with the schmarty pants
>>>>>>>>>Buffer is a place to hold data that comes from the drive, that may available
>>>>>>>>>before the CPU is ready for it. If that happens, then when CPU is ready, if
>>>>>>>>>the data isn't available, it has to call the drive up and say "hey you
>>>>>>>>>remember that data i asked for a few nanoseconds ago, well, I need it now"
>>>>>>>>>Without the buffer the drive grumbles and says oh #@#$!! and has to go fetch
>>>>>>>>>it again. With the buffer, the data is stored in some RAM on the drive
>>>>>>>>>electronics so that when the CPU says "OK" ready, the drive says "here you
>>>>>>>>>are right in my hand" and doesn't have to go look again. The advantage is
>>>>>>>>>that its a lot faster to get data from the buffer than from the disk
>>>>>>>>>platters.
>>>>>>>>>It works in a similar way for writing data. If the CPU can dump the data to
>>>>>>>>>the drives buffer to be written when the drive is good and ready, it can say
>>>>>>>>>"good, on to the next thing" instead of having to wait until the disk is
>>>>>>>>>availalbe to perform the the write ....
>>>>>>>>>
>>>>>>>>>Make sense. I hope so. At end of the day, more buffer is better for disk
>>>>>>>>>intensive operations.
>>>>>>>>
>>>>>>>>A couple of embellishments -
>>>>>>>>
>>>>>>>>The drive can be clever about its read buffers, and pre-load into them
>>>>>>>>sectors that haven't yet been identified as desired, but which follow
>>>>>>>>ones that have been, under the assumption that data is often read
>>>>>>>>sequentially.
>>>>>>>>
>>>>>>>>Write buffering has implications for error recovery -- what happens if
>>>>>>>>the power fails (or the machine reboots) while the drive's buffers are
>>>>>>>>full of information that has not yet been written to the disk? As a
>>>>>>>>result, it is often turned off in high reliability systems.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>"Dan Irwin" <harryguy082589@aol.com> wrote in message
>>>>>>>>>news:2a779348.0408260936.2d99d539@posting.google.com...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>I know this is a kind of stubid question, but what does the buffer on hard
>>>>>>>>>
>>>>>>>>>drive do?
>>>>>>>>>
>>>>>>>>>
--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
wrote:
>Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>time and one with 8mb buffer and a 10ms avg seek time. Which would be
>better in pratical application?
seek time has little bearing these day. mS is less than a blink of
your eye.
Back in 80's, seek time used to matter a lot as they were much slower
than they are today. Ultimately, I'd choose whichever that costs
less, probably the one with 8MB buffer.
--
To reply, replace digi.mon with tds.net
On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
wrote:
>Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>time and one with 8mb buffer and a 10ms avg seek time. Which would be
>better in pratical application?
seek time has little bearing these day. mS is less than a blink of
your eye.
Back in 80's, seek time used to matter a lot as they were much slower
than they are today. Ultimately, I'd choose whichever that costs
less, probably the one with 8MB buffer.
--
To reply, replace digi.mon with tds.net
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
Impmon wrote:
> On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
> wrote:
>
>> Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>> time and one with 8mb buffer and a 10ms avg seek time. Which would be
>> better in pratical application?
>
> seek time has little bearing these day. mS is less than a blink of
> your eye.
Going off topic:
CD drives always have slow seek times, but always quote times
excluding spin-up time (and some will get that first access a full
second or two quicker than others)
I`ve never seen a comparative review of CD drives mention this,
which is odd.
--
Mike
Impmon wrote:
> On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
> wrote:
>
>> Now lets say you had one drive with a 16mb buffer and 12ms avg seek
>> time and one with 8mb buffer and a 10ms avg seek time. Which would be
>> better in pratical application?
>
> seek time has little bearing these day. mS is less than a blink of
> your eye.
Going off topic:
CD drives always have slow seek times, but always quote times
excluding spin-up time (and some will get that first access a full
second or two quicker than others)
I`ve never seen a comparative review of CD drives mention this,
which is odd.
--
Mike
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)
"Impmon" <impmon@digi.mon> wrote in message news:ibt6j0h9rihf8a37uss5prl55q58i63a72@4ax.com
> On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
> wrote:
>
> > Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> > time and one with 8mb buffer and a 10ms avg seek time. Which would be
> > better in pratical application?
>
> seek time has little bearing these day.
Clueless. It has actually much more bearing 'these days'.
> mS is less than a blink of your eye.
And 100 blinks is a full second, a small lifetime in data transfer time.
The actual data transfer time of 100 5kB files is 10 ms (at 50MB/s media
to buffer) out of a whopping 1410 ms or 1610 ms (*) of total transfer time.
That is a whopping less than 1% spent in actually transferring the data.
If the 500kB were transferred as a single contiguous file it would have
transfered in ~25ms total, ~60 times faster than the seperate files.
* 4 ms latency added to 10 or 12 ms seek time.
>
> Back in 80's, seek time used to matter a lot as they were much slower
> than they are today.
Nonsense.
STR has increased a huge amount more than access time decreased.
The gap between STR and average random access transfer rate has
only widened.
> Ultimately, I'd choose whichever that costs less, probably the one
> with 8MB buffer.
"Impmon" <impmon@digi.mon> wrote in message news:ibt6j0h9rihf8a37uss5prl55q58i63a72@4ax.com
> On 28 Aug 2004 18:06:16 -0700, harryguy082589@aol.com (Dan Irwin)
> wrote:
>
> > Now lets say you had one drive with a 16mb buffer and 12ms avg seek
> > time and one with 8mb buffer and a 10ms avg seek time. Which would be
> > better in pratical application?
>
> seek time has little bearing these day.
Clueless. It has actually much more bearing 'these days'.
> mS is less than a blink of your eye.
And 100 blinks is a full second, a small lifetime in data transfer time.
The actual data transfer time of 100 5kB files is 10 ms (at 50MB/s media
to buffer) out of a whopping 1410 ms or 1610 ms (*) of total transfer time.
That is a whopping less than 1% spent in actually transferring the data.
If the 500kB were transferred as a single contiguous file it would have
transfered in ~25ms total, ~60 times faster than the seperate files.
* 4 ms latency added to 10 or 12 ms seek time.
>
> Back in 80's, seek time used to matter a lot as they were much slower
> than they are today.
Nonsense.
STR has increased a huge amount more than access time decreased.
The gap between STR and average random access transfer rate has
only widened.
> Ultimately, I'd choose whichever that costs less, probably the one
> with 8MB buffer.
Facebook
Twitter
Instagram