IDE or AHCI ?

[Lynn McGuire]

What is the fastest hard drive access method for
Windows 7 x64, IDE or AHCI ? I have a WD 1 TB
caviar black, a Gigabyte z68xp-ud5 motherboard
and a Intel I3-2500K with 8 GB of ram.

I see these thoughts:
http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/
http://tweaks.com/windows/44119/improve-sata-hard-disk-performance-convert-from-ide-to-ahci/

Thanks,
Lynn

[Arno]

It should not matter much for speed. AHCI has hotplug, IDE does
not though. And AHCI dirvers may be newer, improving speed.
Unfortunately even Win 7 has problematic (no?) AHCI support out
of the box and requires drivers. AFAIK this is motsly an issue for
new installations. Under Linux it does not matter.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: ar...@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

[arno fucker]

Arno wrote:
> Lynn McGuire <l...@winsim.com> wrote:

>> What is the fastest hard drive access method for
>> Windows 7 x64, IDE or AHCI ? I have a WD 1 TB
>> caviar black, a Gigabyte z68xp-ud5 motherboard
>> and a Intel I3-2500K with 8 GB of ram.

>> I see these thoughts:

>> http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/
>> http://tweaks.com/windows/44119/improve-sata-hard-disk-performance-convert-from-ide-to-ahci/

> It should not matter much for speed. AHCI has hotplug, IDE does
> not though. And AHCI dirvers may be newer, improving speed.
> Unfortunately even Win 7 has problematic (no?) AHCI support out
> of the box and requires drivers.

Wrong, as always.

> AFAIK this is motsly an issue for new installations.

Wrong, as always.

> Under Linux it does not matter.

Wrong, as always. The difference isnt huge, but the first set of benchmarks show that the effect is real.

[Rod Speed]

Lynn McGuire wrote:

> What is the fastest hard drive access method for Windows 7 x64, IDE or AHCI ?

There clearly isnt a lot in it give the stats in your first link.

I doubt you'd be able to pick the difference in a proper double blind
trial without being allowed to use a benchmark with normal work.

If you can, with normal work, use the config which gives the best result WITH THAT WORK.

[Yousuf Khan]

I did the switch to AHCI back in the Windows XP days. At that time it
was a difficult transition as there were no default AHCI drivers, and
switching to AHCI without doing some preparation meant that your OS
would not boot. It's still not an easy switch with Windows 7 either, you
basically have to install Windows 7 with AHCI already enabled or else
it'll default to IDE and not include the AHCI drivers in the install.
Otherwise, switching to AHCI after installing Win 7 is already installed
is nearly as difficult as XP. Linux could use either type transparently,
not sure why Microsoft didn't make it as simple with its own drivers.

After doing the switch, I find absolutely no difference in performance.
However, I do have an external eSATA drive which can be enabled and
disabled on the fly just like a USB drive. I think if I were still using
IDE drivers, that wouldn't be nearly as easy though.

Yousuf Khan

[David Brown]

On 04/01/2012 06:07, Yousuf Khan wrote:
> On 03/01/2012 1:30 PM, Lynn McGuire wrote:
>> What is the fastest hard drive access method for Windows 7 x64, IDE
>> or AHCI ? I have a WD 1 TB caviar black, a Gigabyte z68xp-ud5
>> motherboard and a Intel I3-2500K with 8 GB of ram.
>>
>> I see these thoughts:
>> http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/
>>
>>
>>
>> http://tweaks.com/windows/44119/improve-sata-hard-disk-performance-convert-from-ide-to-ahci/
>>
>>
>
> I did the switch to AHCI back in the Windows XP days. At that time it
> was a difficult transition as there were no default AHCI drivers,
> and switching to AHCI without doing some preparation meant that your
> OS would not boot. It's still not an easy switch with Windows 7
> either, you basically have to install Windows 7 with AHCI already
> enabled or else it'll default to IDE and not include the AHCI drivers
> in the install. Otherwise, switching to AHCI after installing Win 7
> is already installed is nearly as difficult as XP. Linux could use
> either type transparently, not sure why Microsoft didn't make it as
> simple with its own drivers.
>

It's hard to comprehend MS's difficulty here. There is little
measurable difference in performance between IDE mode and AHCI mode, but
people often /perceive/ "native SATA" mode as newer and faster than "IDE
emulation" mode. So even if you can't measure a difference, it still
seems absurd that you have to jump through hoops to run "native SATA".

> After doing the switch, I find absolutely no difference in
> performance. However, I do have an external eSATA drive which can be
> enabled and disabled on the fly just like a USB drive. I think if I
> were still using IDE drivers, that wouldn't be nearly as easy
> though.
>

There are two main differences in practice between SATA and IDE modes.
One is hotplug, as you mentioned, and the other is NCQ - native command
queueing. (There are also a few other SATA commands, such as SSD trim
and secure erase.)

NCQ won't make a significant difference in Linux, since it has always
had good algorithms to order disk accesses to minimise head movement.
It will sometimes make things worse, such as when the OS wants to
enforce a particular order (for transactions to filesystem journals, for
example). And NCQ doesn't help windows much either - after all, it only
applies when you do more than one thing at a time.

[Rod Speed]

David Brown wrote
> Yousuf Khan wrote

>> Lynn McGuire wrote

>>> What is the fastest hard drive access method for Windows 7 x64, IDE or AHCI ? I have a WD 1 TB caviar black, a
>>> Gigabyte z68xp-ud5
>>> motherboard and a Intel I3-2500K with 8 GB of ram.

>>> I see these thoughts:
>>> http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/
>>> http://tweaks.com/windows/44119/improve-sata-hard-disk-performance-convert-from-ide-to-ahci/

>> I did the switch to AHCI back in the Windows XP days. At that time it was a difficult transition as there were no
>> default AHCI drivers,
>> and switching to AHCI without doing some preparation meant that your OS would not boot. It's still not an easy switch
>> with Windows 7
>> either, you basically have to install Windows 7 with AHCI already
>> enabled or else it'll default to IDE and not include the AHCI drivers
>> in the install. Otherwise, switching to AHCI after installing Win 7
>> is already installed is nearly as difficult as XP. Linux could use
>> either type transparently, not sure why Microsoft didn't make it as
>> simple with its own drivers.

> It's hard to comprehend MS's difficulty here.

For you, sure.

> There is little measurable difference in performance between IDE mode and AHCI mode,

Yes.

> but people often /perceive/ "native SATA" mode as newer and faster than "IDE emulation" mode.

More fool them.

> So even if you can't measure a difference,

Corse you can.

> it still seems absurd that you have to jump through hoops to run "native SATA".

Why when the difference is so trivial ?

>> After doing the switch, I find absolutely no difference in performance. However, I do have an external eSATA drive
>> which can be enabled and disabled on the fly just like a USB drive. I think if I were still using IDE drivers, that
>> wouldn't be nearly as easy though.

> There are two main differences in practice between SATA and IDE modes.
> One is hotplug, as you mentioned, and the other is NCQ - native command queueing. (There are also a few other SATA
> commands, such as SSD trim and secure erase.)

> NCQ won't make a significant difference in Linux, since it has always
> had good algorithms to order disk accesses to minimise head movement.

And so does Win.

> It will sometimes make things worse, such as when the OS wants to enforce a particular order (for transactions to
> filesystem journals,
> for example). And NCQ doesn't help windows much either

Wrong.

> - after all, it only applies when you do more than one thing at a time.

Which Win does all the time.

[David Brown]

You do realise you are arguing against yourself here, don't you? First
you agree that there is only a trivial difference in performance between
IDE and AHCI modes, then you argue that "of course" you can measure it,
then you argue that there is little point in using it (on Windows) since
the differences are trivial...

Back to reality. Yes, the performance differences are trivial. Yes,
they /can/ be measured - but the differences are below the noise
threshold for most windows machines. To measure them, you have to be
careful about test conditions, background services, repetition of the
tests, clean installs, etc. That's fine for a website specialising in
tests and benchmarks, but of little use to most people.

However, whatever the technical benefits (or lack thereof) of using AHCI
instead of IDE, user perception and expectation should be important to a
supplier like MS. The effort needed to get hard drive drivers in place
and working in Windows, and the scope for getting it wrong and causing
problems, is just silly when you look at how simple it is with Linux.

>
>>> After doing the switch, I find absolutely no difference in
>>> performance. However, I do have an external eSATA drive which can
>>> be enabled and disabled on the fly just like a USB drive. I think
>>> if I were still using IDE drivers, that wouldn't be nearly as
>>> easy though.
>
>> There are two main differences in practice between SATA and IDE
>> modes. One is hotplug, as you mentioned, and the other is NCQ -
>> native command queueing. (There are also a few other SATA
>> commands, such as SSD trim and secure erase.)
>
>> NCQ won't make a significant difference in Linux, since it has
>> always had good algorithms to order disk accesses to minimise head
>> movement.
>
> And so does Win.

I wasn't talking about Windows here.

>
>> It will sometimes make things worse, such as when the OS wants to
>> enforce a particular order (for transactions to filesystem
>> journals, for example). And NCQ doesn't help windows much either
>
> Wrong.
>

No, it is correct - NCQ doesn't help windows much. Benchmarks vary, as
it depends heavily on the usage patterns. It is a win in some cases,
and a loss on others - but seldom by particularly large margins.

>> - after all, it only applies when you do more than one thing at a
>> time.
>
> Which Win does all the time.
>
>

I knew that would provoke you :-)

[Yousuf Khan]

On 04/01/2012 2:53 AM, David Brown wrote:
> NCQ won't make a significant difference in Linux, since it has always
> had good algorithms to order disk accesses to minimise head movement. It
> will sometimes make things worse, such as when the OS wants to enforce a
> particular order (for transactions to filesystem journals, for example).
> And NCQ doesn't help windows much either - after all, it only applies
> when you do more than one thing at a time.

I find that it doesn't even help even when multitasking. I monitor the
disk subsection of the Resource Monitor regularly, and very often when
the disk is busy the Disk Queue Length is over 1.00 (meaning more than 1
process is actively waiting on the disk) and the Active Time is pegged
near 100%. Nothing that can be done about it till SSD's are more affordable.

Yousuf Khan

[David Brown]

NCQ can only really help if you have multiple outstanding transactions,
and the OS itself hasn't ordered them appropriately. Since the OS
(Windows or Linux) /does/ order transactions, NCQ will only help if the
OS is doing a bad job. The disk knows a bit more than the OS regarding
disk ordering (since it knows the full 3D geometry, rather than just a
linear LBA number), but on the other hand it knows nothing about which
processes are waiting for disk access, or the priorities of said
accesses, and it knows nothing about barrier writes. I don't know how
Windows handles write barriers, but on Linux they are important to
ensure the integrity of critical disk accesses such as journalling -
they ensure that everything that was supposed to be written earlier
/has/ been written. NCQ totally screws this up, and means that the OS's
IO subsystem must ensure the disk queue is completely empty before
sending the barrier write, and wait for it to finish completely before
sending anything else. If the disk handles transactions in the order
they are given, then such writes can be buffered better.

[Arno]

David Brown <da...@westcontrol.removethisbit.com> wrote:
> On 04/01/2012 06:07, Yousuf Khan wrote:
>> On 03/01/2012 1:30 PM, Lynn McGuire wrote:
>>> What is the fastest hard drive access method for Windows 7 x64, IDE
>>> or AHCI ? I have a WD 1 TB caviar black, a Gigabyte z68xp-ud5
>>> motherboard and a Intel I3-2500K with 8 GB of ram.
>>>
>>> I see these thoughts:
>>> http://expertester.wordpress.com/2008/07/24/ahci-vs-ide-%E2%80%93-benchmark-advantage/
>>>
>>>
>>>
>>> http://tweaks.com/windows/44119/improve-sata-hard-disk-performance-convert-from-ide-to-ahci/
>>>
>>>
>>
>> I did the switch to AHCI back in the Windows XP days. At that time it
>> was a difficult transition as there were no default AHCI drivers,
>> and switching to AHCI without doing some preparation meant that your
>> OS would not boot. It's still not an easy switch with Windows 7
>> either, you basically have to install Windows 7 with AHCI already
>> enabled or else it'll default to IDE and not include the AHCI drivers
>> in the install. Otherwise, switching to AHCI after installing Win 7
>> is already installed is nearly as difficult as XP. Linux could use
>> either type transparently, not sure why Microsoft didn't make it as
>> simple with its own drivers.
>>

> It's hard to comprehend MS's difficulty here. There is little
> measurable difference in performance between IDE mode and AHCI mode, but
> people often /perceive/ "native SATA" mode as newer and faster than "IDE
> emulation" mode. So even if you can't measure a difference, it still
> seems absurd that you have to jump through hoops to run "native SATA".

Indeed. And you onlu get reliably working hotplug with AHCI,
which is a factor for eSATA. Basically shows that when it
comes to things on the hardcore tech layer, MS is still
pretty far behind.

>> After doing the switch, I find absolutely no difference in
>> performance. However, I do have an external eSATA drive which can be
>> enabled and disabled on the fly just like a USB drive. I think if I
>> were still using IDE drivers, that wouldn't be nearly as easy
>> though.
>>

> There are two main differences in practice between SATA and IDE modes.
> One is hotplug, as you mentioned, and the other is NCQ - native command
> queueing. (There are also a few other SATA commands, such as SSD trim
> and secure erase.)

> NCQ won't make a significant difference in Linux, since it has always
> had good algorithms to order disk accesses to minimise head movement.
> It will sometimes make things worse, such as when the OS wants to
> enforce a particular order (for transactions to filesystem journals, for
> example). And NCQ doesn't help windows much either - after all, it only
> applies when you do more than one thing at a time.

Indeed again. NCQ is motsly for server loads, where a lot
of things run in parallel, with a sub-standard buffer-cache.
This certainly does not apply to Linux or the BSDs. No
idea whether it applies to Windows on servers.

[Arno]

Interessting.

[Arno]

Well, yes. Write-barriers are getting more and more important
on Linux, with filesystems deferring more and using jourmalling
more agressively. Looks like NCQ is basically obsolete.

If I remember correctly, it is a thing that was brought on in
SCSI disks a long time ago, when it still had merit. Not so
anymore, just one more TLA that can be trhown at customers
to make them think they are getting more for their money.

[Rod Speed]

David Brown wrote

Like hell I am.

> First you agree that there is only a trivial difference in performance between IDE and AHCI modes,

I didnt agree with your TRIVIAL claim, just what you actually said, LITTLE difference.

> then you argue that "of course" you can measure it,

Her first link clearly shows that it can be measured.

> then you argue that there is little point in using it (on Windows) since the differences are trivial...

No I did not. One obvious reason to use it is if you use the hot plugging.

> Back to reality.

You wouldnt know what reality was if bit you on your lard arse.

> Yes, the performance differences are trivial.

Not always.

> Yes, they /can/ be measured - but the differences are below the noise threshold for most windows machines.

That is just plain wrong.

> To measure them, you have to be careful about test conditions, background services, repetition of the tests, clean
> installs, etc.

Wrong, as always.

> That's fine for a website specialising in tests and benchmarks, but of little use to most people.

Irrelevant to it providing support for hot plugging that IDE does not.

> However, whatever the technical benefits (or lack thereof) of using AHCI instead of IDE, user perception and
> expectation should be important to a supplier like MS.

Mindlessly silly.

> The effort needed to get hard drive drivers in place and working in Windows,

Is completely trivial with Win7

> and the scope for getting it wrong and causing problems,

Thats a lie with Win7.

> is just silly when you look at how simple it is with Linux.

Its even simpler with Win7.

>>>> After doing the switch, I find absolutely no difference in performance. However, I do have an external eSATA drive
>>>> which can be enabled and disabled on the fly just like a USB drive. I think if I were still using IDE drivers, that
>>>> wouldn't be nearly as easy though.

>>> There are two main differences in practice between SATA and IDE
>>> modes. One is hotplug, as you mentioned, and the other is NCQ -
>>> native command queueing. (There are also a few other SATA
>>> commands, such as SSD trim and secure erase.)

>>> NCQ won't make a significant difference in Linux, since it has always had good algorithms to order disk accesses to
>>> minimise head movement.

>> And so does Win.

> I wasn't talking about Windows here.

You clearly were.

>>> It will sometimes make things worse, such as when the OS wants to enforce a particular order (for transactions to
>>> filesystem journals, for example). And NCQ doesn't help windows much either

>> Wrong.

> No, it is correct - NCQ doesn't help windows much.

Depends on how you define much and which sort of work you are talking about.

> Benchmarks vary, as it depends heavily on the usage patterns.

And it does help some usage patterns significantly.

> It is a win in some cases,

Yes.

> and a loss on others

Hardly ever in many real world situations.

> - but seldom by particularly large margins.

Only because most real work isnt particularly drive IO bound anymore.

>>> - after all, it only applies when you do more than one thing at a time.

>> Which Win does all the time.

> I knew that would provoke you :-)

You spew mindless silly shit, you can be quite confident that I will point that out if I
notice that and can be bothered to expose you stupiditys for the world to laugh at, again.

[Rod Speed]

Yousuf Khan wrote

> David Brown wrote

>> NCQ won't make a significant difference in Linux, since it has always
>> had good algorithms to order disk accesses to minimise head
>> movement. It will sometimes make things worse, such as when the OS
>> wants to enforce a particular order (for transactions to filesystem
>> journals, for example). And NCQ doesn't help windows much either -
>> after all, it only applies when you do more than one thing at a time.

> I find that it doesn't even help even when multitasking.

The benchmarks clearly show that it does.

Not very dramatically tho.

> I monitor the disk subsection of the Resource Monitor regularly, and very often when the disk is busy the Disk Queue
> Length is over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near
> 100%.

Doesnt mean that NCQ doesnt help in that situaiton.

> Nothing that can be done about it till SSD's are more affordable.

Wrong. NCQ does help in that situaition, albeit not very dramatically.

[Rod Speed]

David Brown wrote
> Yousuf Khan wrote

>> David Brown wrote

>>> NCQ won't make a significant difference in Linux, since it has
>>> always had good algorithms to order disk accesses to minimise head
>>> movement. It will sometimes make things worse, such as when the OS
>>> wants to enforce a particular order (for transactions to filesystem
>>> journals, for example). And NCQ doesn't help windows much either -
>>> after all, it only applies when you do more than one thing at a time.

And any modern OS is doing that all the time.

>> I find that it doesn't even help even when multitasking. I monitor
>> the disk subsection of the Resource Monitor regularly, and very
>> often when the disk is busy the Disk Queue Length is over 1.00
>> (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near 100%. Nothing that
>> can be done about it till SSD's are more affordable.

> NCQ can only really help if you have multiple outstanding transactions,

Yes.

> and the OS itself hasn't ordered them appropriately.

Yes.

> Since the OS (Windows or Linux) /does/ order transactions, NCQ will only help if the OS is doing a bad job.

It will also help when it can do a better job.

> The disk knows a bit more than the OS regarding disk ordering (since it knows the full 3D geometry, rather than just a
> linear LBA number),

And so it can do a much better job when knowing that allows it to decide what
ordering makes sense, something the OS can never do, most obviously with
what is currently the biggest variable now, when something has just gone past
the heads and you will need to wait an entire revolution before it shows up again.

> but on the other hand it knows nothing about which processes are waiting for disk access, or the priorities of said
> accesses,

The OS doesnt necessarily know that either except with what it initiates itself.

> and it knows nothing about barrier writes. I don't know how Windows handles write barriers, but on Linux they are
> important to ensure the integrity of critical disk accesses such as journalling - they ensure that
> everything that was supposed to be written earlier /has/ been written. NCQ totally screws this up,

Not if the OS allows for it being there.

> and means that the OS's IO subsystem must ensure the disk queue is completely empty before sending the barrier write,

Wrong.

> and wait for it to finish completely before sending anything else.

Wrong.

> If the disk handles transactions in the order they are given, then such writes can be buffered better.

Wrong.

[David Brown]

On 04/01/12 21:37, Rod Speed wrote:
> David Brown wrote

>

>> I knew that would provoke you :-)
>
> You spew mindless silly shit, you can be quite confident that I will point that out if I
> notice that and can be bothered to expose you stupiditys for the world to laugh at, again.
>

It doesn't matter what I write - your Rodbot mode goes on automatic.
But it is sometimes mildly entertaining to see how easy it is to trigger
your outbursts of witless knee-jerk childishness.

It's a pity, really. I know that deep down below the image of a sad,
angry flamer lies a fair amount of knowledge and experience. But once
someone suggests you might be wrong on a point, your Rodbot alter-ego
takes over, and the sane Rod is lost.

Do you act the same in real life, or is this just your Usenet persona?

[David Brown]

The feature introduced on SCSI was TCQ - Tagged Command Queuing. It was
more flexible, and more useful - each command sent to the disk could be
tagged as "head of queue" (do this command with highest priority),
"ordered" (enforcing the order of the tagged commands) and "simple" (do
in whatever order the disk wants). NCQ is pretty much TCQ "simple". If
SATA supported the "ordered" mode of TCQ, it would be very useful. I
don't know what happens when mixing different tag types in TCQ, but I
think if "order" had top priority for writes, "head of queue" had top
priority for reads, and "simple" had lowest priority for both, then
you'd have a system that would improve speed in almost all cases as well
as being easy to make write-barrier safe.

I assume that SAS supports TCQ.

[Rod Speed]

David Brown wrote

> Rod Speed wrote
>> David Brown wrote

>>> I knew that would provoke you :-)

>> You spew mindless silly shit, you can be quite confident that I will point that out if I notice that and can be
>> bothered to expose you stupiditys for the world to laugh at, again.

> It doesn't matter what I write - your Rodbot mode goes on automatic.

Everyone can see for themselves that you are lying, just like you
always end up doing when you have got done like a fucking dinner,
just like you always are when you desperately attempt to bullshit
and lie your way out of your predicament when you mindless silly
shit is exposed for the whole world to laugh at, as it always is.

<reams of your puerile attempt at insults any 2 year old could leave for dead flushed where it belongs>

[Ed Light]

On 1/4/2012 1:56 PM, David Brown wrote:
> On 04/01/12 21:37, Rod Speed wrote:
>> David Brown wrote

> It's a pity, really. I know that deep down below the image of a sad,
> angry flamer

Lots of us have Roddy filtered out.

--
Ed Light

Better World News TV Channel:
http://realnews.com

Iraq Veterans Against the War and Related:
http://ivaw.org
http://couragetoresist.org
http://antiwar.com

Send spam to the FTC at
sp...@uce.gov
Thanks, robots.

[Mike Tomlinson]

En el artículo <HY-dnbi5joOPVpnS...@lyse.net>, David Brown
<david...@removethis.hesbynett.no> escribió:

>It doesn't matter what I write - your Rodbot mode goes on automatic.
>But it is sometimes mildly entertaining to see how easy it is to trigger
>your outbursts of witless knee-jerk childishness.

Funny isn't it, how he feels threatened and lashes out when confronted
by someone who actually knows what they are talking about?

>It's a pity, really. I know that deep down below the image of a sad,
>angry flamer lies a fair amount of knowledge and experience.

i.e. he's a dinosaur

>Do you act the same in real life, or is this just your Usenet persona?

I have in my mind's eye a sad, lonely individual who masturbates
obsessively over his collection of ST225's.

--
(\_/)
(='.'=)
(")_(")

[Rod Speed]

Mike Tomlinson wrote

> Funny isn't it, how he feels threatened and lashes out when confronted
> by someone who actually knows what they are talking about?

That fool never does with Win.

You never ever do with anything at all, ever.

> I have in my mind's eye a sad, lonely individual who
> masturbates obsessively over his collection of ST225's.

You're projecting now. I dont even have even one, fuckwit.

[Arno]

Ah, yes. TCQ it was indeed.

[Yousuf Khan]

On 1/4/2012 3:41 PM, Rod Speed wrote:
> Yousuf Khan wrote
>> David Brown wrote
>
>>> NCQ won't make a significant difference in Linux, since it has always
>>> had good algorithms to order disk accesses to minimise head
>>> movement. It will sometimes make things worse, such as when the OS
>>> wants to enforce a particular order (for transactions to filesystem
>>> journals, for example). And NCQ doesn't help windows much either -
>>> after all, it only applies when you do more than one thing at a time.
>
>> I find that it doesn't even help even when multitasking.
>
> The benchmarks clearly show that it does.
>
> Not very dramatically tho.

Too bad you can't run benchmarks as your applications.

>> I monitor the disk subsection of the Resource Monitor regularly, and very often when the disk is busy the Disk Queue
>> Length is over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near
>> 100%.
>
> Doesnt mean that NCQ doesnt help in that situaiton.

When I'm talking about the disk queue being higher than 1.00, I don't
mean just something minor like 1.01, or 1.10, but I'm talking about
5.00, or even 10.00! There could be 10 process waiting on the disk queue
at any given time. This normally happens during boot-up time, but it
doesn't take very long for the disk queue to kick up to the stratosphere
at any time. Just a few apps trying to access the same disk at the same
time, and you got major delays.

Yousuf Khan

[Rod Speed]

Yousuf Khan wrote

> Rod Speed wrote
>> Yousuf Khan wrote
>>> David Brown wrote

>>>> NCQ won't make a significant difference in Linux, since it has
>>>> always had good algorithms to order disk accesses to minimise head
>>>> movement. It will sometimes make things worse, such as when the OS
>>>> wants to enforce a particular order (for transactions to filesystem
>>>> journals, for example). And NCQ doesn't help windows much either -
>>>> after all, it only applies when you do more than one thing at a time.

>>> I find that it doesn't even help even when multitasking.

>> The benchmarks clearly show that it does.

>> Not very dramatically tho.

> Too bad you can't run benchmarks as your applications.

You can however use what you care about the speed of as the benchmark.

>>> I monitor the disk subsection of the Resource Monitor regularly,
>>> and very often when the disk is busy the Disk Queue Length is over 1.00 (meaning more than 1 process is actively
>>> waiting on the disk) and the Active Time is pegged near 100%.

>> Doesnt mean that NCQ doesnt help in that situaiton.

> When I'm talking about the disk queue being higher than 1.00, I don't mean just something minor like 1.01, or 1.10,
> but I'm talking about 5.00, or even 10.00! There could be 10 process waiting on the disk queue at any given time.

I just dont believe that that happens all that much for long to matter.

> This normally happens during boot-up time,

Like I have said to you before, anyone with even half a clue
boots so rarely that that situation is completely irrelevant. If
you care about the speed of your system, the only thing that
makes any sense at all is to only boot very rarely, weeks or
months apart, and suspend or hibernate, not shutdown.

Even if you are silly enough to religiously update as often as you can,
any reboot involved should happen when you arent using the system.

> but it doesn't take very long for the disk queue to kick up to the stratosphere at any time.

Thats just plain wrong with numbers like that.

> Just a few apps trying to access the same disk at the same time, and you got major delays.

Thats just plain wrong with modern hard drives. Very
minor delays in fact with modern fast seeking drives.

[Arno]

Yousuf Khan <bbb...@spammenot.yahoo.com> wrote:
> On 1/4/2012 3:41 PM, Rod Speed wrote:
>> Yousuf Khan wrote
>>> David Brown wrote

[...]

>>> I monitor the disk subsection of the Resource Monitor regularly, and very often when the disk is busy the Disk Queue
>>> Length is over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near
>>> 100%.
>>
>> Doesnt mean that NCQ doesnt help in that situaiton.

> When I'm talking about the disk queue being higher than 1.00, I don't
> mean just something minor like 1.01, or 1.10, but I'm talking about
> 5.00, or even 10.00! There could be 10 process waiting on the disk queue
> at any given time. This normally happens during boot-up time, but it
> doesn't take very long for the disk queue to kick up to the stratosphere
> at any time. Just a few apps trying to access the same disk at the same
> time, and you got major delays.

> Yousuf Khan

Seems tsomething was done here in 3.2 and moire maybe done in
the near future. Although from an article on LWN, its seems
the curent FS people have trouble understanding some of the
proposals made.

[Krypsis]

I turn my computers off when not in use. No point using electricity when
I'm not using the computer. I turn the power off at the UPS but not at
the wall socket. Waiting for a bootup is no great pain. I walk past my
computer, hit a few buttons, do a few other things and by the time I
have finished that, the beast is up and ready.

I've yet to see Windows last months without a complete shutdown. Friends
of mine are forced to reboot often because Windows gets itself tied up
in knots. Linux, on the other hand, can go for years without even
suspending or hibernating.

>
> Even if you are silly enough to religiously update as often as you can,
> any reboot involved should happen when you arent using the system.
>
>> but it doesn't take very long for the disk queue to kick up to the stratosphere at any time.
>
> Thats just plain wrong with numbers like that.
>
>> Just a few apps trying to access the same disk at the same time, and you got major delays.
>
> Thats just plain wrong with modern hard drives. Very
> minor delays in fact with modern fast seeking drives.

You don't know what you're talking about. I have modern fast seeking
drives in all my computers bar my Powermac and they ALL bog down when
accessed by multiple programs at the same time. I suggest you do a few
simple experiments to prove this to yourself. Do you reckon the seek
limitations of mechanical hard drives might be the reason SSDs are so
popular in applications where speed is paramount?


--

Krypsis

[Arno]

Windows was never intended as a server OS. It still shows.
There is a lot that cannot be done on Windows without a shurdown.
Machines get slower and slower with uptime. I know a few people
that administrate Windows servers, and they usually do scheduled
reboots every 30 days or so.

Longest uptime I had with with Linux server/firewall box was
400 days, then I replaced the kernel. No issues at that
time despite constant i/o and network load during the day.
This experience is fairly typical. Still, for my desktop system
I shut down Linux as well. Hibernating is at the very least a
security risk and basically unneccessary. I do the same as you,
1-2 minutes are not hard to pass.

>> Even if you are silly enough to religiously update as often as you can,
>> any reboot involved should happen when you arent using the system.
>>
>>> but it doesn't take very long for the disk queue to kick up to the stratosphere at any time.
>>
>> Thats just plain wrong with numbers like that.
>>
>>> Just a few apps trying to access the same disk at the same time, and you got major delays.
>>
>> Thats just plain wrong with modern hard drives. Very
>> minor delays in fact with modern fast seeking drives.

> You don't know what you're talking about.

As usual for him. Even the fastest stinning disks can
be brought to their knees with a few processes that are I/O
intensive. (That means aggregated delivered I/O bandwidth is far
lower than the maximum.) For SSDs the situation is different
at least for large accesses. For small accesses you can run
into the same problem.

> I have modern fast seeking
> drives in all my computers bar my Powermac and they ALL bog down when
> accessed by multiple programs at the same time. I suggest you do a few
> simple experiments to prove this to yourself. Do you reckon the seek
> limitations of mechanical hard drives might be the reason SSDs are so
> popular in applications where speed is paramount?

Or even RAM-disks in some applications. At least before SSDs became
cheap.

Don't worry about Rod, he is not using any kind of
understanding to post his opinions, he uses the parrot
model with some obscure selction function. Most of us
have him filtered out.

[Rod Speed]

Krypsis wrote

Even if you do, you can set it to hibernate or suspend when that
happens so you dont get a full boot when you turn it on again,
and so wont see that disk activity when you turn it on again.

> I turn the power off at the UPS but not at the wall socket.

Why waste the power that the UPS uses ?

> Waiting for a bootup is no great pain.

Its even less of a pain if you set it to hibernate or suspend.

> I walk past my computer, hit a few buttons, do a few other things and by the time I have finished that, the beast is
> up and ready.

He was talking about obsessing about the disk activity.

> I've yet to see Windows last months without a complete shutdown.

More fool you.

> Friends of mine are forced to reboot often because Windows gets itself tied up in knots.

They dont have a clue about how to use it.

> Linux, on the other hand, can go for years without even suspending or hibernating.

But usually doesnt for various reasons.

>> Even if you are silly enough to religiously update as often as you can, any reboot involved should happen when you
>> arent using the system.

>>> but it doesn't take very long for the disk queue to kick up to the
>>> stratosphere at any time.

>> Thats just plain wrong with numbers like that.

>>> Just a few apps trying to access the same disk at the same time,and you got major delays.

>> Thats just plain wrong with modern hard drives. Very
>> minor delays in fact with modern fast seeking drives.

> You don't know what you're talking about.

Everyone can see for themselves who doesnt know what they are talking about, child.

> I have modern fast seeking drives in all my computers bar my Powermac and they ALL bog down when accessed by multiple
> programs at the same time.

How odd that mine dont. I dont even bother to have a separate PVR anymore
and I bet you couldnt even work out when its recording in a proper double blind
trial with not being allowed to use the task manager to see whats running etc.

> I suggest you do a few simple experiments to prove this to yourself.

Been doing that since before you were even born thanks child.

> Do you reckon the seek limitations of mechanical hard drives might be the reason SSDs are so popular in applications
> where speed is paramount?

Taint the SEEK speed thats the reason for that, child.

[Mike Tomlinson]

En el artículo <9mp2dl...@mid.individual.net>, Arno <m...@privacy.net>
escribió:

>Longest uptime I had with with Linux server/firewall box was
>400 days

http://www.jasper.org.uk/uptime.jpg

Now that's a *proper* OS :-)

[cjt]

On 01/06/2012 03:13 PM, Mike Tomlinson wrote:
> En el artículo<9mp2dl...@mid.individual.net>, Arno<m...@privacy.net>
> escribió:
>
>> Longest uptime I had with with Linux server/firewall box was
>> 400 days
>
> http://www.jasper.org.uk/uptime.jpg
>
> Now that's a *proper* OS :-)
>

Indeed.

FWIW, I've been using Solaris for some time to serve files, and have
routinely had uptimes of about a year before something has come along to
force a shutdown -- usually me wanting to change the hardware
configuration or location. I've just switched to OpenIndiana -- hope I
do as well with it.

[David Brown]

On 06/01/12 22:13, Mike Tomlinson wrote:
> En el artículo<9mp2dl...@mid.individual.net>, Arno<m...@privacy.net>
> escribió:
>
>> Longest uptime I had with with Linux server/firewall box was
>> 400 days
>
> http://www.jasper.org.uk/uptime.jpg
>
> Now that's a *proper* OS :-)
>

The easiest uptime records to find on the net are for Novell Netware
machines running for over six years:

<http://www.networkworld.com/newsletters/netware/2005/1128nw2.html>

I read an article once about an IBM mainframe that had been running
non-stop for a couple of decades - but the only original part was the
frame. Everything else had been hot-swapped over time, usually for
preventive maintenance rather than as a result of failure.

[Arno]

David Brown <david...@removethis.hesbynett.no> wrote:
> On 06/01/12 22:13, Mike Tomlinson wrote:

>> En el art?culo<9mp2dl...@mid.individual.net>, Arno<m...@privacy.net>
>> escribi?:

>>
>>> Longest uptime I had with with Linux server/firewall box was
>>> 400 days
>>
>> http://www.jasper.org.uk/uptime.jpg
>>
>> Now that's a *proper* OS :-)
>>

> The easiest uptime records to find on the net are for Novell Netware
> machines running for over six years:

> <http://www.networkworld.com/newsletters/netware/2005/1128nw2.html>

> I read an article once about an IBM mainframe that had been running
> non-stop for a couple of decades - but the only original part was the
> frame. Everything else had been hot-swapped over time, usually for
> preventive maintenance rather than as a result of failure.

Indeed. Linux already is in the lower-quality sector. Still
good for many tasks, but not high-reliability or high-uptime.
Just fullfilling the minimal sane requirements for a server OS.

That shows that Windows is properly placed in the "toy" class here.
It never ceases to amaze me that people are willing to settle for
that.

[Krypsis]

If it is hibernated, a memory image is stored on the hard disk. Ergo,
there needs to be disk activity to restore said image to RAM.

In suspend mode, the computer goes into a low power mode but does not
save data. A power outage whilst in this state will result in data loss.
From Vista onwards, suspend mode will become hibernate on laptops after
3 hours of inactivity (default time).

From my experience, hibernate and suspend, on Windows, is not reliable.

>
>> I turn the power off at the UPS but not at the wall socket.
>
> Why waste the power that the UPS uses ?

Because my modem and router also run from it and others in my household
use them wirelessly.

>
>> Waiting for a bootup is no great pain.
>
> Its even less of a pain if you set it to hibernate or suspend.

How much of a pain is it to press one (1) button and enter one (1)
password???

>
>> I walk past my computer, hit a few buttons, do a few other things and by the time I have finished that, the beast is
>> up and ready.
>
> He was talking about obsessing about the disk activity.

I was talking about turning off versus hibernate/suspend.

>
>> I've yet to see Windows last months without a complete shutdown.
>
> More fool you.

You need to get out more.

>
>> Friends of mine are forced to reboot often because Windows gets itself tied up in knots.
>
> They dont have a clue about how to use it.
>
>> Linux, on the other hand, can go for years without even suspending or hibernating.
>
> But usually doesnt for various reasons.

Yes, people like me turn them off for various reasons, ie. to save on
power when not in use. Windows, on the other hand, can't go the distance
without a regular reboot.

>
>>> Even if you are silly enough to religiously update as often as you can, any reboot involved should happen when you
>>> arent using the system.
>
>>>> but it doesn't take very long for the disk queue to kick up to the
>>>> stratosphere at any time.
>
>>> Thats just plain wrong with numbers like that.
>
>>>> Just a few apps trying to access the same disk at the same time,and you got major delays.
>
>>> Thats just plain wrong with modern hard drives. Very
>>> minor delays in fact with modern fast seeking drives.
>
>> You don't know what you're talking about.
>
> Everyone can see for themselves who doesnt know what they are talking about, child.

True, most people here seem to have worked out that you're a moron.

>
>> I have modern fast seeking drives in all my computers bar my Powermac and they ALL bog down when accessed by multiple
>> programs at the same time.
>
> How odd that mine dont. I dont even bother to have a separate PVR anymore
> and I bet you couldnt even work out when its recording in a proper double blind
> trial with not being allowed to use the task manager to see whats running etc.

As if I care! I don't even bother with a PVR.

>
>> I suggest you do a few simple experiments to prove this to yourself.
>
> Been doing that since before you were even born thanks child.

At 74 years of age, it's a fair guess that I was born a rather long time
before you. Given the childish nature of your arguments, it's fairly
obvious who is the child here.

>
>> Do you reckon the seek limitations of mechanical hard drives might be the reason SSDs are so popular in applications
>> where speed is paramount?
>
> Taint the SEEK speed thats the reason for that, child.
>

It is ONE of the reasons but not the only one.
>


--

Krypsis

[Mike Tomlinson]

En el artículo <SYCdnWGYj8SoopXS...@lyse.net>, David Brown
<david...@removethis.hesbynett.no> escribió:

>The easiest uptime records to find on the net are for Novell Netware
>machines running for over six years:

Not difficult for them to achieve, not being internet-facing and thus
not having to have security updates applied every ten minutes.

I installed several Netware networks years ago running on Token Ring.
This was in the days when Ethernet was still installed using thin coax
cable.

I remember a story - possibly urban myth - about a company which called
out a consultancy to fix a Netware server which had gone down. The firm
had ground to a halt as no-one could get any work done. The problem was
no-one knew where it was; it had been up and running so long. They
eventually found it behind a walled-in space which had been created
during building modifications.

[Krypsis]

On 8/01/2012 1:36 AM, Mike Tomlinson wrote:
> En el artículo<SYCdnWGYj8SoopXS...@lyse.net>, David Brown
> <david...@removethis.hesbynett.no> escribió:
>
>> The easiest uptime records to find on the net are for Novell Netware
>> machines running for over six years:
>
> Not difficult for them to achieve, not being internet-facing and thus
> not having to have security updates applied every ten minutes.
>
> I installed several Netware networks years ago running on Token Ring.
> This was in the days when Ethernet was still installed using thin coax
> cable.

I remember IBM token ring networks back in the 80s... Yech!!

>
> I remember a story - possibly urban myth - about a company which called
> out a consultancy to fix a Netware server which had gone down. The firm
> had ground to a halt as no-one could get any work done. The problem was
> no-one knew where it was; it had been up and running so long. They
> eventually found it behind a walled-in space which had been created
> during building modifications.
>


--

Krypsis

[David Brown]

On 07/01/12 15:36, Mike Tomlinson wrote:
> En el artículo<SYCdnWGYj8SoopXS...@lyse.net>, David Brown
> <david...@removethis.hesbynett.no> escribió:
>
>> The easiest uptime records to find on the net are for Novell Netware
>> machines running for over six years:
>
> Not difficult for them to achieve, not being internet-facing and thus
> not having to have security updates applied every ten minutes.
>

Absolutely. When you don't need to update the kernel or other critical
software, then there is no need for downtime other than because of power
cuts, hardware issues, or just because you want to move things around.
I had a Windows NT 4.0 server that was never updated, never crashed
(other than for hardware problems on the power supply), and was never
rebooted except in connection with power cuts or moving it physically.
It was in service for about 10 years before the hardware finally gave up
(though for the last few years the load was very low).

> I installed several Netware networks years ago running on Token Ring.
> This was in the days when Ethernet was still installed using thin coax
> cable.
>
> I remember a story - possibly urban myth - about a company which called
> out a consultancy to fix a Netware server which had gone down. The firm
> had ground to a halt as no-one could get any work done. The problem was
> no-one knew where it was; it had been up and running so long. They
> eventually found it behind a walled-in space which had been created
> during building modifications.
>

I heard it was at a university. But I also suspect it is an urban myth
- though not an unrealistic one.

[Rod Speed]

Yes, but you dont get lots of different processes all attempting
drive access simultanously, so you dont get the problem he was
clearly talking about. You just have ONE process restoring the
ram contents from the ONE file on the hard drive, and reading
that linearly too.

> Ergo, there needs to be disk activity to restore said image to RAM.

But NOT a number of different processes competing for access to the drive.

> In suspend mode, the computer goes into a low power mode but does not save data. A power outage whilst in this state
> will result in data loss.

Not with a laptop.

> From Vista onwards, suspend mode will become hibernate on laptops after 3 hours of inactivity (default time).

No reason why you have to accept the default setting.

> From my experience, hibernate and suspend, on Windows, is not reliable.

You're wrong, as always.

The most you have to do is an occassional full reboot every month or few
depending on how the machine is used, as Win cant go forever without a full reboot.

>>> I turn the power off at the UPS but not at the wall socket.

>> Why waste the power that the UPS uses ?

> Because my modem and router also run from it and others in my household use them wirelessly.

>>> Waiting for a bootup is no great pain.

>> Its even less of a pain if you set it to hibernate or suspend.

> How much of a pain is it to press one (1) button and enter one (1) password???

There is a much longer wait till its performing at full speed again.

>>> I walk past my computer, hit a few buttons, do a few other things
>>> and by the time I have finished that, the beast is up and ready.

>> He was talking about obsessing about the disk activity.

> I was talking about turning off versus hibernate/suspend.

And ignoring his complaint about seeing lots of processes competing for
drive access with a full reboot which you dont bet with hibernate and suspend.

>>> I've yet to see Windows last months without a complete shutdown.

>> More fool you.

> You need to get out more.

Nope, I use systems like that all the time thanks child.

>>> Friends of mine are forced to reboot often because Windows gets itself tied up in knots.

>> They dont have a clue about how to use it.

>>> Linux, on the other hand, can go for years without even suspending or hibernating.

>> But usually doesnt for various reasons.

> Yes, people like me turn them off for various reasons, ie. to save on power when not in use.

Thats just one way of saving power.

> Windows, on the other hand, can't go the distance without a regular reboot.

And that is MUCH less often than every time you stop using the PC.

>>>> Even if you are silly enough to religiously update as often as you can, any reboot involved should happen when you
>>>> arent using the system.

>>>>> but it doesn't take very long for the disk queue to kick up to the
>>>>> stratosphere at any time.

>>>> Thats just plain wrong with numbers like that.

>>>>> Just a few apps trying to access the same disk at the same
>>>>> time,and you got major delays.

>>>> Thats just plain wrong with modern hard drives. Very
>>>> minor delays in fact with modern fast seeking drives.

>>> You don't know what you're talking about.

>> Everyone can see for themselves who doesnt know what they are talking about, child.

> True, most people here seem to have worked out that you're a moron.

Everyone can see for themselves that you are lying, as always.

>>> I have modern fast seeking drives in all my computers bar my
>>> Powermac and they ALL bog down when accessed by multiple programs at the same time.

>> How odd that mine dont. I dont even bother to have a separate PVR
>> anymore and I bet you couldnt even work out when its recording in a proper double blind trial with not being allowed
>> to use the task manager to see whats running etc.

> As if I care! I don't even bother with a PVR.

You have always been, and always will be, completely and utterly irrelevant.

What you may or may not claim to care about in spades.

>>> I suggest you do a few simple experiments to prove this to yourself.

>> Been doing that since before you were even born thanks child.

> At 74 years of age, it's a fair guess that I was born a rather long time before you.

Guess which pathetic little prat has just got egg all over its pathetic little face, yet again ?

> Given the childish nature of your arguments, it's fairly obvious who is the child here.

Guess which pathetic little prat has just got egg all over its pathetic little face, yet again ?

>>> Do you reckon the seek limitations of mechanical hard drives might be the reason SSDs are so popular in applications
>>> where speed is paramount?

>> Taint the SEEK speed thats the reason for that, child.

> It is ONE of the reasons

Wrong, as always.

> but not the only one.

It aint even one of them, child.

[JW]

On Sun, 8 Jan 2012 06:43:09 +1100 "Rod Speed" <rod.sp...@gmail.com>
wrote in Message id: <9mrlif...@mid.individual.net>:

>Krypsis wrote
[...]

>> True, most people here seem to have worked out that you're a moron.
>
>Everyone can see for themselves that you are lying, as always.

Nope, he's right. Everyone here *does* know you're a moron, and you prove
it each and every time you post.

What you need is a team of mental health professionals to keep you away
from your computer long enough to stop embarrassing yourself on usenet.

[Mike Tomlinson]

In article <je9nbr$drn$1...@dont-email.me>, Krypsis
<kry...@optusnet.com.au> writes

>I remember IBM token ring networks back in the 80s... Yech!!

To be fair, it was a very well thought-out network protocol which beat
the pants off CSMA/CD Ethernet.

The main problem was the prohibitive cost of network cards (often
containing a more powerful processor than the host system) and the MAUs
(concentrators). They suffered from IBM's propensity to over-engineer
everything.

Even though IBM developed it to run at 16Mbps (originally 4) and to use
two tokens instead of one, the advent of cheap Ethernet cards and cheap
UTP cabling eventually killed off Token Ring.

--
(\__/)

[Yousuf Khan]

On 06/01/2012 1:35 AM, Rod Speed wrote:
> Yousuf Khan wrote
>> Rod Speed wrote
>>> Yousuf Khan wrote

>>>> I find that it doesn't even help even when multitasking.
>
>>> The benchmarks clearly show that it does.
>
>>> Not very dramatically tho.
>
>> Too bad you can't run benchmarks as your applications.
>
> You can however use what you care about the speed of as the benchmark.

Unfortunately there is nothing from benchmarks that are relevant to
real-world apps, therefore there is nothing in them that I care about.

>>>> I monitor the disk subsection of the Resource Monitor regularly,
>>>> and very often when the disk is busy the Disk Queue Length is over 1.00 (meaning more than 1 process is actively
>>>> waiting on the disk) and the Active Time is pegged near 100%.
>
>>> Doesnt mean that NCQ doesnt help in that situaiton.
>
>> When I'm talking about the disk queue being higher than 1.00, I don't mean just something minor like 1.01, or 1.10,
>> but I'm talking about 5.00, or even 10.00! There could be 10 process waiting on the disk queue at any given time.
>
> I just dont believe that that happens all that much for long to matter.

I really don't care what you believe. I know what I have seen and what
I've measured.

>> This normally happens during boot-up time,
>
> Like I have said to you before, anyone with even half a clue
> boots so rarely that that situation is completely irrelevant. If
> you care about the speed of your system, the only thing that
> makes any sense at all is to only boot very rarely, weeks or
> months apart, and suspend or hibernate, not shutdown.

It also happens after a standby or hibernate resume, not just during
full boot. It's a little less intense with hibernate, and even less with
standby, but it's still there.

Besides, we're not here to take your advice on when or when not to boot
our systems, we know when it needs to reboot, and there are good reasons
to do it.

BTW, apparently Windows 8 will have a super-fast boot which will reload
the kernel and drivers from something similar to a mini-hibernate file,
which should result in 10 second reboots or less. They will give you the
option to do a full reload just in case there are changes needed.

> Even if you are silly enough to religiously update as often as you can,
> any reboot involved should happen when you arent using the system.

Most of us would say you're being silly not updating regularly. You do
have the option of ignoring the updates as long you're in the middle of
important work, so I have my Windows update set to just notify me but
not to automatically apply the updates, but eventually you should
update. Windows security holes abound, and they're usually bad.

>> but it doesn't take very long for the disk queue to kick up to the stratosphere at any time.
>
> Thats just plain wrong with numbers like that.
>
>> Just a few apps trying to access the same disk at the same time, and you got major delays.
>
> Thats just plain wrong with modern hard drives. Very
> minor delays in fact with modern fast seeking drives.

"Modern fast seeking hard drives" are the biggest burdens on modern PCs
there is. If you take a look at the Windows 7 Experience Index, which
rates the speed of components from 1 to 7.9, slow to fast respectively;
yes it's a benchmark like any of the others and arbitrary in its
measurements, but it is a common benchmark for everyone. It bases the
overall experience number on the slowest component number in the system.
In modern systems, that's invariably the hard drive system. It doesn't
matter whether you have the latest top-line CPU, or hottest new GPU
which are running close to the theoretical top 7.9 number, every system
these days will be stuck with a 5.9 rating if they use a hard drive to
boot up from. All modern hard drives are now stuck at the 5.9 rating
level, therefore all of the fastest HD-based systems are stuck at the
5.9 rating level. In fact, that speed rating is the same whether you
have a hard drive that's less than a year old, or if you have one from 5
years back; if you go back to 10 years ago, the speed rating might go
down to an insignificantly smaller 5.7 vs. 5.9. There are big
improvements in capacity year after year, but not in speed.

That is unless you go with an SSD as your boot device. SSD's seem to be
the only significant new speed-up technology on the storage front. In
the CPU and GPU realm, there have been great leaps and bounds made in
speed, but in storage it's been pretty static for years at a time.

[Yousuf Khan]

On 06/01/2012 3:04 PM, Arno wrote:

> Krypsis<kry...@optusnet.com.au> wrote:
>> I've yet to see Windows last months without a complete shutdown. Friends
>> of mine are forced to reboot often because Windows gets itself tied up
>> in knots. Linux, on the other hand, can go for years without even
>> suspending or hibernating.
>
> Windows was never intended as a server OS. It still shows.
> There is a lot that cannot be done on Windows without a shurdown.
> Machines get slower and slower with uptime. I know a few people
> that administrate Windows servers, and they usually do scheduled
> reboots every 30 days or so.
>
> Longest uptime I had with with Linux server/firewall box was
> 400 days, then I replaced the kernel. No issues at that
> time despite constant i/o and network load during the day.
> This experience is fairly typical. Still, for my desktop system
> I shut down Linux as well. Hibernating is at the very least a
> security risk and basically unneccessary. I do the same as you,
> 1-2 minutes are not hard to pass.

Linux is just as bad these days, at least desktop versions, like Ubuntu.
There's a constant barrage of updates, most don't require a reboot, but
whenever there's a new kernel update, that does require a reboot. And
there seems to be a kernel update every two weeks nowadays. It's damn
near impossible to keep Linux running constantly for more than a week
now without ignoring updates.

Yousuf Khan

[Arno]

There was another problem: Inadequate resilience to card failure.
ATM was killed by the same thing plus extreme vendor egoism (fully
compatible only within one vendor).

The main driving point for Ethernet is that it is simple and there
is a good standard that does not leave critical grey areas.

Or in one sentence: Ethernet is infrastrucutre, while Token-Ring
was one vendores ego-trip.

[Arno]

My guess is thet these vendors think they have to do it this
way in order to keep their business. Go to Debian stable,
update automatically only from the security repo. This solves
the issue.

Of course if you want the colorful lights on your desktop (i.e.
the broken MS interface or one of its clones), forget about
stability.

[Yousuf Khan]

Not to mention the fact that Ethernet is hardly the underachieving
shared bus architecture it once was, switching hubs have now transformed
it into a full-blown star architecture. Even everyday home routers are
Ethernet switches now.

Yousuf Khan

[Yousuf Khan]

On 06/01/2012 4:48 AM, Arno wrote:
> Yousuf Khan<bbb...@spammenot.yahoo.com> wrote:
>> On 1/4/2012 3:41 PM, Rod Speed wrote:
>>> Yousuf Khan wrote
>>>> David Brown wrote
> [...]
>>>> I monitor the disk subsection of the Resource Monitor regularly, and very often when the disk is busy the Disk Queue
>>>> Length is over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near
>>>> 100%.
>>>
>>> Doesnt mean that NCQ doesnt help in that situaiton.
>
>> When I'm talking about the disk queue being higher than 1.00, I don't
>> mean just something minor like 1.01, or 1.10, but I'm talking about
>> 5.00, or even 10.00! There could be 10 process waiting on the disk queue
>> at any given time. This normally happens during boot-up time, but it
>> doesn't take very long for the disk queue to kick up to the stratosphere
>> at any time. Just a few apps trying to access the same disk at the same
>> time, and you got major delays.
>
>> Yousuf Khan
>
> Seems tsomething was done here in 3.2 and moire maybe done in
> the near future. Although from an article on LWN, its seems
> the curent FS people have trouble understanding some of the
> proposals made.
>
> Arno

I'm sorry, I didn't understand a word you said, what are you talking about?

Yousuf Khan

[Mike Tomlinson]

En el artículo <9n0ir6...@mid.individual.net>, Arno <m...@privacy.net>
escribió:

> Ethernet is infrastrucutre,

The original Ethernet wasn't intended to be infrastructural, it was
invented to link together workstations at Xerox PARC. It ran at
2.94Mbps, and was developed further by DIX (Digital, Intel and Xerox)
and its speed increased to 10Mbps.

--
(\_/)

[Mike Tomlinson]

En el artículo <9n0ir6...@mid.individual.net>, Arno <m...@privacy.net>
escribió:

> Token-Ring
>was one vendores ego-trip.

Bit unfair, I think. Ego-trips generally don't become IEEE standards.

--
(\_/)

[GMAN]

In article <fU90B8AW...@jasper.org.uk>, Mike Tomlinson <mi...@jasper.org.uk> wrote:
>En el artículo <9n0ir6...@mid.individual.net>, Arno <m...@privacy.net>
>escribió:
>
>> Token-Ring
>>was one vendores ego-trip.
>
>Bit unfair, I think. Ego-trips generally don't become IEEE standards.
>

Tell that to Apple !!!!


"flame suit on"

[David Brown]

Or Micro "OOXML" soft.

> "flame suit on"

[David Brown]

It depends on how much you want to update (if you are a normal user on a
reasonably safe network, you don't need to be too paranoid about
security updates), and what you define as "uptime". Most updates don't
lead to a reboot, but many mean you have to re-start a particular
program (such as your browser), or to log out and in (such as to update
your desktop or X). Depending on how you use the machine, you may view
this as being as bad as a reboot, or just a minor inconvenience.

For server systems, most updates only lead to a restart of the services
being updated - though again, that may be as bad as a reboot.

[David Brown]

It made some sense to me - maybe this key will help:

Translation of the abbreviations:

"3.2" = Linux kernel version 3.2
"LWM" = Linux Weekly News (a website)
"FS" = Filesystem

And the typos:

"tsomething" = something
"moire" = more
"its" = it
"curent" = current


I couldn't figure out which article Arno was referring to - maybe we
could have a link?

mvh.,

David

[Mike Tomlinson]

En el artículo <7VGOq.198616$xz3.1...@en-nntp-11.dc1.easynews.com>,
GMAN <Winnie...@100acrewoods.net> escribió:

>Tell that to Apple !!!!

Touché :-)

[Rod Speed]

Yousuf Khan wrote
> Rod Speed wrote
>> Yousuf Khan wrote
>>> Rod Speed wrote
>>>> Yousuf Khan wrote

>>>>> I find that it doesn't even help even when multitasking.

>>>> The benchmarks clearly show that it does.

>>>> Not very dramatically tho.

>>> Too bad you can't run benchmarks as your applications.

>> You can however use what you care about the speed of as the benchmark.

> Unfortunately there is nothing from benchmarks that are relevant to
> real-world apps, therefore there is nothing in them that I care about.

Thats the opposite of what I was talking about. You should take whatever
it is that you care about the speed of, and USE THAT AS THE BENCHMARK.

Take whatever real world work you care about the
speed of AND USE THAT AS THE BENCHMARK.

>>>>> I monitor the disk subsection of the Resource Monitor regularly,
>>>>> and very often when the disk is busy the Disk Queue Length is
>>>>> over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near 100%.

>>>> Doesnt mean that NCQ doesnt help in that situaiton.

>>> When I'm talking about the disk queue being higher than 1.00, I don't mean just something minor like 1.01, or 1.10,
>>> but I'm talking about 5.00, or even 10.00! There could be 10 process waiting on the disk queue at any given time.

>> I just dont believe that that happens all that much for long to matter.

> I really don't care what you believe. I know what I have seen and what I've measured.

And the only example you have actually been able to list where
that actually happens for long enough to matter is with the boot,
and there are lots of ways to avoid that happening enough to matter.

>>> This normally happens during boot-up time,

>> Like I have said to you before, anyone with even half a clue
>> boots so rarely that that situation is completely irrelevant. If
>> you care about the speed of your system, the only thing that
>> makes any sense at all is to only boot very rarely, weeks or
>> months apart, and suspend or hibernate, not shutdown.

> It also happens after a standby or hibernate resume,

Like hell it does with 10 different processes competing for drive access.

> not just during full boot. It's a little less intense with hibernate,

It doesnt happen at all with a return from hibernate, JUST
ONE process is using the drive to load the content of ram
from the hibernate file and its just from one file too, so
there isnt even access to multiple files going on either.

> and even less with standby,

None at all with suspend to ram in fact.

> but it's still there.

That is just plain wrong.

> Besides, we're not here to take your advice on when or when not to boot our systems, we know when it needs to reboot,

You clearly dont if you choose to do a full shutdown and
reboot when you arent using the system and dont like the
competition for drive access you get in a full reboot.

> and there are good reasons to do it.

Nope, not one if you dont like the competition for disk access by various processes.

> BTW, apparently Windows 8 will have a super-fast boot which will reload the kernel and drivers from something similar
> to a
> mini-hibernate file, which should result in 10 second reboots or less.

A hibernate doesnt take that long right now. A suspend in spades.

> They will give you the option to do a full reload just in case there are changes needed.

>> Even if you are silly enough to religiously update as often as you can, any reboot involved should happen when you
>> arent using the system.

> Most of us would say you're being silly not updating regularly.

Thats not the same thing as AS OFTEN AS YOU CAN.

> You do have the option of ignoring the updates as long you're in the middle of important work, so I have my Windows
> update set to just notify me but not to automatically apply the updates, but eventually you should update. Windows
> security holes abound, and they're usually bad.

That last is a bare faced pig ignorant lie.

And thats an entirely separate matter to the other point that there
is no reason you cant do the update WHEN YOU ARENT USING
THE SYSTEM, SO YOU DONT CARE ABOUT HOW LONG THE
REBOOT THAT IS ASSOCIATED WITH THAT TAKES ANYWAY.

>>> but it doesn't take very long for the disk queue to kick up to the stratosphere at any time.

>> Thats just plain wrong with numbers like that.

>>> Just a few apps trying to access the same disk at the same time, and you got major delays.

>> Thats just plain wrong with modern hard drives. Very
>> minor delays in fact with modern fast seeking drives.

> "Modern fast seeking hard drives" are the biggest burdens on modern PCs there is.

Wrong again, the user is.

> If you take a look at the Windows 7 Experience Index, which rates the speed of components from 1 to 7.9, slow to fast
> respectively; yes it's a benchmark like any of the others and
> arbitrary in its measurements, but it is a common benchmark for everyone. It bases the overall experience number on
> the slowest component number in the system.

Its just some fool's 'index' of nothing meaningful at all.

> In modern systems, that's invariably the hard drive system.

Pity that in the real world, with most disk activity actually being media
files, where the file is accessed linearly, and the speed of access is
entirely determined by the media play speed, the drive has no effect
whatever on the speed at which the media is played.

> It doesn't matter whether you have the latest top-line CPU, or hottest new GPU which are running close to the
> theoretical top 7.9 number, every system these days will be stuck
> with a 5.9 rating if they use a hard drive to boot up from.

The boot time is completely irrelevant for anyone with even half
a clue, because they arrange for that boot to happen when they
arent using the system.

> All modern hard drives are now stuck at the 5.9 rating level, therefore all of the fastest HD-based systems are stuck
> at the 5.9 rating level. In fact, that speed rating is the same whether you
> have a hard drive that's less than a year old, or if you have one
> from 5 years back; if you go back to 10 years ago, the speed rating
> might go down to an insignificantly smaller 5.7 vs. 5.9. There are big
> improvements in capacity year after year, but not in speed.

PIty its the boot speed thats completely irrelevant to anyone with
even half a clue because anyone with even half a clue arranges
for their system to boot when they arent using it.

> That is unless you go with an SSD as your boot device. SSD's seem to
> be the only significant new speed-up technology on the storage front.

Wrong again. Suspend and hibernate are.

> In the CPU and GPU realm, there have been great leaps and bounds made in speed, but in storage it's been pretty static
> for years at a time.

More mindless silly drivel.

[cjt]

My experience has been different. I use MythTV running on Linux, and I
keep that machine running for months at a time. But it's nearly a
dedicated machine (it also acts as a DHCP server, but that's not much of
a load), and not used for Internet access.

It all depends what you're trying to accomplish which platform(s) will suit.

[Yousuf Khan]

On 09/01/2012 5:34 PM, Rod Speed wrote:
> Yousuf Khan wrote
>> Rod Speed wrote
>>> Yousuf Khan wrote

>>>> Too bad you can't run benchmarks as your applications.
>
>>> You can however use what you care about the speed of as the benchmark.
>
>> Unfortunately there is nothing from benchmarks that are relevant to
>> real-world apps, therefore there is nothing in them that I care about.
>
> Thats the opposite of what I was talking about. You should take whatever
> it is that you care about the speed of, and USE THAT AS THE BENCHMARK.
>
> Take whatever real world work you care about the
> speed of AND USE THAT AS THE BENCHMARK.

Well, in the real world, what I care about most is multitasking, when
several apps would be hitting the disk(s) at the same time. When they
decide to hit the disk(s) is unpredictable. There are various apps
running automatically in the background that hit the disk, from virus
scanners, to streaming media services, to disk backups, bittorrents,
etc., plus whatever app I'm using at the time in the foreground. I've
had them all hit simultaneously at times. This cannot be adequately
modelled by any single benchmark. If I were to run several instances of
the benchmark at the same time, then it might work.

>>>>>> I monitor the disk subsection of the Resource Monitor regularly,
>>>>>> and very often when the disk is busy the Disk Queue Length is
>>>>>> over 1.00 (meaning more than 1 process is actively waiting on the disk) and the Active Time is pegged near 100%.
>
>>>>> Doesnt mean that NCQ doesnt help in that situaiton.
>
>>>> When I'm talking about the disk queue being higher than 1.00, I don't mean just something minor like 1.01, or 1.10,
>>>> but I'm talking about 5.00, or even 10.00! There could be 10 process waiting on the disk queue at any given time.
>
>>> I just dont believe that that happens all that much for long to matter.
>
>> I really don't care what you believe. I know what I have seen and what I've measured.
>
> And the only example you have actually been able to list where
> that actually happens for long enough to matter is with the boot,
> and there are lots of ways to avoid that happening enough to matter.

It's the only example that's easy to describe, every other instance this
happens is random processes running simultaneously at random times.

>> It also happens after a standby or hibernate resume,
>
> Like hell it does with 10 different processes competing for drive access.
>
>> not just during full boot. It's a little less intense with hibernate,
>
> It doesnt happen at all with a return from hibernate, JUST
> ONE process is using the drive to load the content of ram
> from the hibernate file and its just from one file too, so
> there isnt even access to multiple files going on either.
>
>> and even less with standby,
>
> None at all with suspend to ram in fact.

After they come back from standby or hibernate, the OS still does a
rescan of the hardware to see that everything is still there, you'll see
large plateaus in the disk activity graphs during this time that can
last upto 10 seconds. My system is unusually huge, more a server than a
desktop really: 6 internal hard drives, 2 internal optical drives, and
various external USB & eSATA hard drives. It's probably not a system
that should be running a desktop Windows really, more likely it should
be running a Windows Server. In fact, that's probably the reason why
running Linux on this system seems to be so much smoother on it.

>> but it's still there.
>
> That is just plain wrong.

It's only wrong because your little world view doesn't allow for it.
What's beyond your horizon doesn't exist for you.

>>> Thats just plain wrong with modern hard drives. Very
>>> minor delays in fact with modern fast seeking drives.
>
>> "Modern fast seeking hard drives" are the biggest burdens on modern PCs there is.
>
> Wrong again, the user is.

Then why is the user waiting for things to get done when the hard drives
get busy?

>> If you take a look at the Windows 7 Experience Index, which rates the speed of components from 1 to 7.9, slow to fast
>> respectively; yes it's a benchmark like any of the others and
>> arbitrary in its measurements, but it is a common benchmark for everyone. It bases the overall experience number on
>> the slowest component number in the system.
>
> Its just some fool's 'index' of nothing meaningful at all.
>
>> In modern systems, that's invariably the hard drive system.
>
> Pity that in the real world, with most disk activity actually being media
> files, where the file is accessed linearly, and the speed of access is
> entirely determined by the media play speed, the drive has no effect
> whatever on the speed at which the media is played.
>
>> It doesn't matter whether you have the latest top-line CPU, or hottest new GPU which are running close to the
>> theoretical top 7.9 number, every system these days will be stuck
>> with a 5.9 rating if they use a hard drive to boot up from.
>
> The boot time is completely irrelevant for anyone with even half
> a clue, because they arrange for that boot to happen when they
> arent using the system.

The WEI disk benchmark is always based on the system disk, i.e. the boot
disk. The boot times are irrelevant here, it's just measuring the raw
performance of the boot disk, but not during boot. You could conceivably
have an SSD as a secondary data disk, while still booting from an HD,
and your SSD's speed will be ignored completely and the times will be
based completely on the HD's speed, because that's what you boot from.

It actually makes sense to use this disk as the benchmark target, as
most or all of the Windows system files are located on the boot disk.
Also, the applications are most often located on this drive too. So it's
quite likely to be the most accessed drive in the system.

Yousuf Khan

[Rod Speed]

Yousuf Khan wrote
> Rod Speed wrote
>> Yousuf Khan wrote
>>> Rod Speed wrote
>>>> Yousuf Khan wrote

>>>>> Too bad you can't run benchmarks as your applications.

>>>> You can however use what you care about the speed of as the benchmark.

>>> Unfortunately there is nothing from benchmarks that are relevant to
>>> real-world apps, therefore there is nothing in them that I care about.

>> Thats the opposite of what I was talking about. You should take whatever it is that you care about the speed of, and
>> USE THAT AS THE BENCHMARK.

>> Take whatever real world work you care about the
>> speed of AND USE THAT AS THE BENCHMARK.

> Well, in the real world, what I care about most is multitasking, when several apps would be hitting the disk(s) at the
> same time.

Then you should be using that config as the benchmark if you actually
use that config much of the time so the speed of that matters.

> When they decide to hit the disk(s) is unpredictable.

Not really.

> There are various apps running automatically in the background that hit the disk, from virus scanners, to streaming
> media services, to disk backups, bittorrents, etc.,

Yes, but with those that significantly affect the speed of
the work the user is doing, when they do that is mostly
configurable, most obviously with backups and virus scans.

Streaming media services and bit torrents dont significantly
affect the speed of what the user is actually doing.

I dont even bother to have a separate PVR anymore,
and that can be recording anything up to 10 broadcast
TV channels simulataneously, and playing one of the
recorded programs, on one of the 5400 RPM eco drives,
while doing bittorrents and other downloads as well,
without having any noticable effect on what the user is doing.

> plus whatever app I'm using at the time in the foreground. I've had them all hit simultaneously at times.

Then you havent configured your system properly with the virus
scans and backups.

> This cannot be adequately modelled by any single benchmark.

I'M NOT TALKING ABOUT ANY BENCHMARK MODELLING ANYTHING.

I AM TALKING ABOUT USING THE CONFIG YOU CARE ABOUT
THE SPEED DOING REAL LIVE WORK YOU DO ALL THE TIME
AS THE TEST OF THE SPEED OF THE CONFIG.

> If I were to run several instances of the benchmark at the same time, then it might work.

See just above.

You should be using the combination of stuff like bitorrents and
media streaming that can happen at the same time as the user
task as the test of the speed of the config, not any benchmark at all.

>>>>>>> I monitor the disk subsection of the Resource Monitor regularly,
>>>>>>> and very often when the disk is busy the Disk Queue Length is
>>>>>>> over 1.00 (meaning more than 1 process is actively waiting on
>>>>>>> the disk) and the Active Time is pegged near 100%.

>>>>>> Doesnt mean that NCQ doesnt help in that situaiton.

>>>>> When I'm talking about the disk queue being higher than 1.00, I don't mean just something minor like 1.01, or
>>>>> 1.10, but I'm
>>>>> talking about 5.00, or even 10.00! There could be 10 process
>>>>> waiting on the disk queue at any given time.

>>>> I just dont believe that that happens all that much for long to matter.

>>> I really don't care what you believe. I know what I have seen and what I've measured.

>> And the only example you have actually been able to list where
>> that actually happens for long enough to matter is with the boot,
>> and there are lots of ways to avoid that happening enough to matter.

> It's the only example that's easy to describe, every other instance this happens is random processes running
> simultaneously at random times.

There is nothing random about when backups and virus scans happen.

And those can be configured to have minimal impact on what the user is
doing if you are actually silly enough to have scheduled them to happen at
the time when you dont like the impact of them on the work the user is doing.

>>> It also happens after a standby or hibernate resume,

>> Like hell it does with 10 different processes competing for drive access.

>>> not just during full boot. It's a little less intense with hibernate,

>> It doesnt happen at all with a return from hibernate, JUST
>> ONE process is using the drive to load the content of ram
>> from the hibernate file and its just from one file too, so
>> there isnt even access to multiple files going on either.

>>> and even less with standby,

>> None at all with suspend to ram in fact.

> After they come back from standby or hibernate, the OS still does a rescan of the hardware to see that everything is
> still there,

And that does NOT involve multiple processes competing for drive access.

> you'll see large plateaus in the disk activity graphs during this time that can last upto 10 seconds.

Like hell you do. In spades when coming out of suspend,
you in fact see no disk activity what so ever.

> My system is unusually huge, more a server than a desktop really:

Irrelevant to that silly claim of yours about multiple processes
competing for drive access when coming out of hibernate or suspend.

> 6 internal hard drives, 2 internal optical drives, and various external USB & eSATA hard drives.

Thats nothing unusual and irrelevant to what is being discussed,
your silly claim about multiple apps competing for drive activity
when coming out of hibernate or suspend instead of a full boot.

> It's probably not a system that should be running a desktop Windows really, more likely it should be running a Windows
> Server.

Depends on how the drives are used.

> In fact, that's probably the reason why running Linux on this system seems to be so much smoother on it.

Fraid not.

>>> but it's still there.

>> That is just plain wrong.

> It's only wrong because your little world view doesn't allow for it.

Wrong with your stupid claim about what happens with coming out of suspend and drive activity.

Anyone can see for themselves that there is NO drive activity as a result of that.

> What's beyond your horizon doesn't exist for you.

Usual puerile attempt at insults.

>>>> Thats just plain wrong with modern hard drives. Very
>>>> minor delays in fact with modern fast seeking drives.

>>> "Modern fast seeking hard drives" are the biggest burdens on modern PCs there is.

>> Wrong again, the user is.

> Then why is the user waiting for things to get done when the hard drives get busy?

Irrelevant to your silly BIGGEST BURDON claim.

>>> If you take a look at the Windows 7 Experience Index, which rates
>>> the speed of components from 1 to 7.9, slow to fast respectively;
>>> yes it's a benchmark like any of the others and arbitrary in its measurements, but it is a common benchmark for
>>> everyone. It bases the overall experience number on the slowest
>>> component number in the system.

>> Its just some fool's 'index' of nothing meaningful at all.

>>> In modern systems, that's invariably the hard drive system.

>> Pity that in the real world, with most disk activity actually being
>> media files, where the file is accessed linearly, and the speed of
>> access is entirely determined by the media play speed, the drive has no effect whatever on the speed at which the
>> media is played.

>>> It doesn't matter whether you have the latest top-line CPU, or
>>> hottest new GPU which are running close to the theoretical top 7.9 number, every system these days will be stuck
>>> with a 5.9 rating if they use a hard drive to boot up from.

>> The boot time is completely irrelevant for anyone with even half
>> a clue, because they arrange for that boot to happen when they
>> arent using the system.

> The WEI disk benchmark is always based on the system disk, i.e. the boot disk. The boot times are irrelevant here,
> it's just measuring
> the raw performance of the boot disk, but not during boot.

It isnt 'measuring' a damned thing.

> You could conceivably have an SSD as a secondary data disk, while still booting from an HD, and your SSD's speed will
> be ignored completely

So it isnt actually 'measuring' a damned thing.

> and the times will be based completely on the HD's speed, because that's what you boot from.

So it isnt actually 'measuring' a damned thing.

> It actually makes sense to use this disk as the benchmark target,

Like hell it does.

> as most or all of the Windows system files are located on the boot disk.

Pity they dont get access much at all once the boot is complete if you have plenty of ram.

> Also, the applications are most often located on this drive too.

Where the apps are located is also irrelevant when the machine is configured
properly so the apps that are used much are started at boot time.

> So it's quite likely to be the most accessed drive in the system.

Wrong again. The most accessed drive is where the data
files are stored for all except virus scans and full backups.

[Arno]

All correct.

> And the typos:

> "tsomething" = something
> "moire" = more
> "its" = it
> "curent" = current

Note to self: Don't post when drunk ;-)

> I couldn't figure out which article Arno was referring to - maybe we
> could have a link?

Sure: http://lwn.net/Articles/456904/

[Mike Tomlinson]

In article <zqidnervSLDy85XS...@lyse.net>, David Brown
<david...@removethis.hesbynett.no> writes

>I heard it was at a university. But I also suspect it is an urban myth
>- though not an unrealistic one.

You're right.

<http://www.informationweek.com/story/IWK20010409S0001>

<http://www.theregister.co.uk/2001/04/12/missing_novell_server_discovere
d_after/>

--
(\__/)

[Yousuf Khan]

Ah! Okay, I understand it now. BTW, my measurements were referring to
Windows 7 here, not Linux. I actually don't have much of an issue with
Linux using the same hardware, everything runs very fast. I just wish I
could do more of my work in Linux, but I'm somewhat dependent on Windows
apps in many cases. My Linux usage mainly consists of light-duty web
surfing, which is fine, but I can't leave it in Linux most of the time
simply for web surfing alone; in Windows, I can get the web surfing done
and other work too.

>> I couldn't figure out which article Arno was referring to - maybe we
>> could have a link?
>
> Sure: http://lwn.net/Articles/456904/
>
> Arno

Oh interesting, so some cutting edge algorithms are being proposed for
the Linux kernel to avoid overloading the disk queues. So has this
Fengguang Wu's rejigged i/o patchset been implemented into Linux kernel
3.2 full time now?

Yousuf Khan