Anyone using XEON-based DAWs?

[Guest]

Archived from groups: rec.audio.pro (More info?)

> > Do the math and ask yourself if it's worth the money. How long before
> > you replace the box anyway?
>
> Other things to consider is whether a single CPU is any kind of a serious
> bottleneck.
>
> I might imagine that there are more than a few people who go the dual CPU
> route, but have a single hard drive.
The Floating Point processor seems to be a bottleneck for
hyper-threading to work effectively in DAW applications.

Check out this paper: Multiprocessing in SONAR 3.1
-http/www.digitalproducer.com/articles/viewarticle.jsp?id=24197.

My DAWs are fast enough for me right now. I'm not upgrading until the
64 bit OS & hardware as in place.

Mike
DAW Builder - http/www.MusicIsLove.com

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

> Join mailtoCDAW-subscribe@yahoogroups.com and search the recent archives
> for posts by Dave Haynie.
Since I made the original post, I'll provide Haynie's response:

> What's the consensus on Wintel based dual CPU machines, performance
> wise? Apple seems to be going this way.

Intel-based SMP systems offer the least additional per-processor add-on
performance (at least based on similar cache sizes), as they're all
based on conventional shared-bus technology -- always potentially in
contention for the main memory pool. Apple's "G4" machines are of a
similar design, though they have been made with L3 caches (as, I suppose,
are some flavors of Intel Xeon high-end P4s), which helps to an extent.

Apple's G5 (IBM's PowerPC 970) is roughly comparable to AMD's Athlon in
terms of architecture. In each case, the CPU presents an independent,
point-to-point high speed link to the "memory hub" chip, which
internally routes access to I/O and memory. This moves the burden of SMP
performance away from the CPU and into system, where at least
potentially, the performance over uniprocessor can scale. In the AMDs,
for example, access to the main memory is buffered on writes, one CPU's
access of I/O doesn't block the other's access of main memory, etc.

AMD took this a step further in the Opteron systems, in which there are
still high-speed, point to point links... only several of them. They've
also moved the memory controller onto the CPU, which basically allows
each CPU to add its own pool of memory, thus much less contention for
memory. Obviously, this resultes in a NUMA system (non-uniform memory
access), not a fully symmetric system, but the basic effect is that a
CPU's local memory is accessed dramatically faster than in
Apple/K7/Intel systems, while access between CPUs is roughly as fast as
in any conventional machine. With a NUMA-optimized OS, this is the
fastest kind of multiprocessor machine going for under $100K or so
(where they move to ultra-fast main shared buses behind huge caches,
memory-tagged coherency rather than snooping, and other really expensive
ideas).

> Hyper-threading doesn't seem to cut it completely.

It's a good use of a relatively few number of transistors. What it winds
up doing is finding useful work for otherwise lost time in the
single-threaded CPU's work -- filling in those pipeline stalls by
shifting to the other thread. The obvious downside is that, when you're
just building two sets of registers, you effectively devote have the
L1/L2 cache to each CPU's work (at least in the worst case). This is the
main reason HT-enabled is sometimes slower than HT-disabled.

As well, this is threading only; it doesn't accelerate the execution of
unrelated programs, as SMP does, but only threads within the same memory
context. Well written code is multithreaded in general, but it hasn't
been the rule that Windows programmers (or Linux programmers, for that
matter) know how to properly thread code. They have been getting better
at it, at least (in the latter case, it helped to actually have threads
added to the Linux OS).

Mike
http/www.MusicIsLove.com

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

Roger wrote:

>I'd say dropouts is a sign of buffer settings. I can easily track 24
>simultaneous channels of audio, and haven't ever run out of power on
>mixdowns, although I'm of a mind that 15 reverbs is probably a little
>overkill. I admit, some plugs like to eat cycles, but I don't use them.
>About the worst I've used is Acoustic Mirror and even at that I've gotten
>near real time response out of minor changes, and I'm only running a 1600+
>Athlon on that system with Win2K.
>
>You must be running some hellacious number of tracks or plugs.
>


Nuendo 2 is a CPU hog though I think. Group Channels, Waves L2 etc, makes the
"Performance Meter" move large.


>--
>
>
>Roger W. Norman
>SirMusic Studio
>
>"John" <jsvice@aol.com> wrote in message
>news:20040722011714.16931.00001525@mb-m20.aol.com...
>> >From: "Arny Krueger" arnyk@hotpop.com
>>
>> >
>> >> A single CPU is a serious bottleneck. I max out my CPU usage on all
>> >> but the most spartan of projects.
>> >
>> >You are aware that under some circumstances, 100% CPU does not mean that
>the
>> >CPU is 100% engaged, but rather that it is engaged in polling?
>> >
>>
>> The CPU usage meter is a guideline, not an absolute. I'm talking about
>the
>> computer choking on plugins and experiencing dropouts.
>>
>>
>> >> I'm disinclined to constantly have
>> >> to apply effects offline and hope that I don't need to tweak the
>> >> effect later.
>> >
>> >What software?
>> >
>>
>> Sonar 3 and Nuendo 2.
>>
>> >> I do have 2 hard drives though! At one point I was
>> >> using a RAID setup, but found that to be overkill. The extra HDD
>> >> throughput simply wasn't needed. Processing power will always be in
>> >> a shortage.
>> >
>> >Not necessarily.
>>
>> I hope you're right.
>>
>> >
>> >> CPU's will ever increase in power, and plugins (and
>> >> users) will increase their demand accordingly.
>> >
>> >Are you applying effects during recording?
>>
>> Never have. It wouldn't occur to me to do that.
>>
>> -John Vice
>> www.summertimestudios.com
>
>
>
>
>
>
>
>





Me at:
http/www.soundclick.com/bands/5/andymostmusic.htm

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

John Vice wrote:

>>From: mrivers@d-and-d.com (Mike Rivers)
>
>>
>>Your experience doesn't jive with a lot of others'. Maybe it's time to
>>retire that 66 MHz 486 and get yourself a good 2.5 GHz Celeron.
>
>I wasn't aware of the "good" Celerons.. j/k. I'm using a P4 2.8. Could be
>that I'm running low on RAM, as I just have 512 MB. I do run lots and lots
>of
>plugs though. Minimum 15... I'd say average is 20+. My experience jives
>with
>people who I talk to outside this group.

It jives with me also & Nuendo 2.2 - P4 2.3
512MB. Perhaps I should get another 512...although a couple of UAD cards
wouldn't hurt. <g>

Remember, I'm not using ProTools or
>a
>Powercore or a UAD... All my processing is native. I don't usually run that
>many tracks either. I never go over 35 or so. And I do remember to archive
>(rather than just mute) tracks that are no longer used (scratch tracks, etc.)
>
>I'm also alware of how to adjust buffer settings. Do you think I'm running
>an
>inordinately large amount of plug-ins? I don't use any more than I need. I
>even bus tracks to avoid the useless running of several instances of the same
>plug.
>-John Vice
>www.summertimestudios.com
>
>
>
>
>
>

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in message
newspWdnWcYv51UZWPdRVn-tA@comcast.com...
> "reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
> news6-dnU5qucUeamPdRVn-uA@adelphia.com
> > "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> > news:ZSzLc.13831$qa2.1154@fe2.texas.rr.com...
> >> If you have the money, a dual CPU machine could make sense even if
> >> the primary application doesn't support dual CPU.
> >>
> >> By allowing all the system and background services and activities
> >> run on one CPU and the core application run on the other, you can
> >> really improve performance of the core application. Also, several
> >> DAWs run multiple apps at the same time, such as Gigastudio AND
> >> Cubase/Protools. These could be running on different CPUs.
>
> > Do the math and ask yourself if it's worth the money. How long before
> > you replace the box anyway?
>
> Other things to consider is whether a single CPU is any kind of a serious
> bottleneck.
>

For tracking, editing and mixing, at this point, it really shouldn't be.
Soft synths tend to eat up the cycles pretty quick, though.

> I might imagine that there are more than a few people who go the dual CPU
> route, but have a single hard drive.
>

Hard drives in and of themselves can be a drain on cpu power. The newer SATA
10k rpm drives decrease that signifigantly. A purchase of two wd raptors
would make more sense to me than dual cpu's in terms of price/performance
ratio.

Really, the only workstation applications where I would recommend dual cpu's
involve 3d rendering - animation, game development, some CAD applications.
It's really unnecessary for everything else - I realize there are people who
want to run 150 plugins and never print a track, but this makes no sense to
me as you can print as many takes as your storage space will allow, and I
can't imagine needing that many plugins.

The issue gets a little more complicated when you get into the soft synths,
but that's where audio is an improvement over other workstation
applications, because it is relatively painless to run and sync two machines
side by side. The cost of two workstations, one for tracking and one for
synthesis, is similair to the cost of a single SMP daw, with it's high end
boards and processors, and the flexibility and power is actually far
greater.

jb

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"John" <jsvice@aol.com> wrote in message
news:20040723044951.18077.00000432@mb-m03.aol.com...
> >From: mrivers@d-and-d.com (Mike Rivers)
>
> >
> >Your experience doesn't jive with a lot of others'. Maybe it's time to
> >retire that 66 MHz 486 and get yourself a good 2.5 GHz Celeron.
>
> I wasn't aware of the "good" Celerons.. j/k. I'm using a P4 2.8. Could
be
> that I'm running low on RAM, as I just have 512 MB. I do run lots and
lots of
> plugs though. Minimum 15... I'd say average is 20+. My experience jives
with
> people who I talk to outside this group. Remember, I'm not using ProTools
or a
> Powercore or a UAD... All my processing is native. I don't usually run
that
> many tracks either. I never go over 35 or so.

I don't know, sounds about like what I was doing on a 1ghz box with half the
RAM. How are your disks configured?

It is just possible I was using more efficient plugins. What software do you
use?

jb









>And I do remember to archive
> (rather than just mute) tracks that are no longer used (scratch tracks,
etc.)
> I'm also alware of how to adjust buffer settings. Do you think I'm
running an
> inordinately large amount of plug-ins? I don't use any more than I need.
I
> even bus tracks to avoid the useless running of several instances of the
same
> plug.
> -John Vice
> www.summertimestudios.com

 

[Flint]

Archived from groups: rec.audio.pro (More info?)

"reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
newstednQ4dxvKQdZzcRVn-pw@adelphia.com...
>
> "Arny Krueger" <arnyk@hotpop.com> wrote in message
> newspWdnWcYv51UZWPdRVn-tA@comcast.com...
> > "reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
> > news6-dnU5qucUeamPdRVn-uA@adelphia.com
> > > "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> > > news:ZSzLc.13831$qa2.1154@fe2.texas.rr.com...
> > >> If you have the money, a dual CPU machine could make sense even if
> > >> the primary application doesn't support dual CPU.
> > >>
> > >> By allowing all the system and background services and activities
> > >> run on one CPU and the core application run on the other, you can
> > >> really improve performance of the core application. Also, several
> > >> DAWs run multiple apps at the same time, such as Gigastudio AND
> > >> Cubase/Protools. These could be running on different CPUs.
> >
> > > Do the math and ask yourself if it's worth the money. How long before
> > > you replace the box anyway?
> >
> > Other things to consider is whether a single CPU is any kind of a
serious
> > bottleneck.
> >
>
> For tracking, editing and mixing, at this point, it really shouldn't be.
> Soft synths tend to eat up the cycles pretty quick, though.
>
> > I might imagine that there are more than a few people who go the dual
CPU
> > route, but have a single hard drive.
> >
>
> Hard drives in and of themselves can be a drain on cpu power. The newer
SATA
> 10k rpm drives decrease that signifigantly. A purchase of two wd raptors
> would make more sense to me than dual cpu's in terms of price/performance
> ratio.

Actually, the new SATA 10K RPM drives require the same CPU overhead as ATA
drives because each block level read and write requires the CPU to process
the action. A fast drive just makes the potential of more CPU overhead to be
consumed by the activity. SCSI drives reduce the block level overhead on the
CPUs. The soon to be released Serial attached SCSI (SAS) drives will reduce
the CPU overhead since the SCSI protocol is less CPU intensive.

A faster ATA or SATA drive means potentially more CPU utilization.

>
> Really, the only workstation applications where I would recommend dual
cpu's
> involve 3d rendering - animation, game development, some CAD applications.
> It's really unnecessary for everything else - I realize there are people
who
> want to run 150 plugins and never print a track, but this makes no sense
to
> me as you can print as many takes as your storage space will allow, and I
> can't imagine needing that many plugins.
>
> The issue gets a little more complicated when you get into the soft
synths,
> but that's where audio is an improvement over other workstation
> applications, because it is relatively painless to run and sync two
machines
> side by side. The cost of two workstations, one for tracking and one for
> synthesis, is similair to the cost of a single SMP daw, with it's high end
> boards and processors, and the flexibility and power is actually far
> greater.
>
> jb
>
>

 

[john]

Archived from groups: rec.audio.pro (More info?)

>
>I don't know, sounds about like what I was doing on a 1ghz box with half the
>RAM. How are your disks configured?
>
>It is just possible I was using more efficient plugins. What software do you
>use?
>
>jb
>

I'm using Sonar 3.1 for most of my tracking and mixing. I use Waves, Lexicon,
TC, and Sonitus plugins mostly. I use the occasional softsynth, but not often.
There are some plugs that I avoid for various reasons (overhead, and quality)
such as the Hyperprism, and the DSP FX bundles.



>>And I do remember to archive
>> (rather than just mute) tracks that are no longer used (scratch tracks,
>etc.)
>> I'm also alware of how to adjust buffer settings. Do you think I'm
>running an
>> inordinately large amount of plug-ins? I don't use any more than I need.
>I
>> even bus tracks to avoid the useless running of several instances of the
>same
>> plug.
>> -John Vice
>> www.summertimestudios.com
>
>

>From: "reddred" opaloka@REMOVECAPSyahoo.com


-John Vice
www.summertimestudios.com

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

In article <PtednQ4dxvKQdZzcRVn-pw@adelphia.com> opaloka@REMOVECAPSyahoo.com writes:

> Hard drives in and of themselves can be a drain on cpu power. The newer SATA
> 10k rpm drives decrease that signifigantly. A purchase of two wd raptors
> would make more sense to me than dual cpu's in terms of price/performance
> ratio.

Seems to me that just a few weeks ago I read a discussion here where
people seemed to concur that SATA drives gave poorer performance in
DAW applications than plain-old-ATA. Perhaps raising the speed from
7200 to 10,000 RPM helps, in a similar manner that raising the CPU
speed allows the use of bloated appications and operating systems
without apparent slowdown.


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1090665400k@trad
> In article <PtednQ4dxvKQdZzcRVn-pw@adelphia.com>
> opaloka@REMOVECAPSyahoo.com writes:
>
>> Hard drives in and of themselves can be a drain on cpu power. The
>> newer SATA 10k rpm drives decrease that significantly. A purchase of
>> two wd raptors would make more sense to me than dual cpu's in terms
>> of price/performance ratio.
>
> Seems to me that just a few weeks ago I read a discussion here where
> people seemed to concur that SATA drives gave poorer performance in
> DAW applications than plain-old-ATA. Perhaps raising the speed from
> 7200 to 10,000 RPM helps, in a similar manner that raising the CPU
> speed allows the use of bloated applications and operating systems
> without apparent slowdown.

I think that discussion was colored by a particular implementation of SATA
controller. There are at least 3 different implementations of it that one
can find on the market today:

(1) SATA <-> ATA adaptors

Examples:
http/www.macgurus.com/productpages/sata/AM1010.php
http/www.coolerexpress.com/iwparatatose.html
http/www.wiredzone.com/xq/asp/ic.31113358/qx/itemdesc.htm

(2) SATA PCI host adaptors

Examples
http/www.dalco.com/moreinfo.cfm?Product_ID=582539&CFID=1374664&CFTOKEN=95370098
http/www.granitedigital.com/catalog/pg49_fasthostadapters.htm
http/www.mittoni.com.au/catalog/product_info.php/products_id/1565



(3) SATA that talks to the CPU & RAM by some other, higher-speed bus than
PCI or ATA

Examples:
http/www.sis.com/products/chipsets/southbridge/96x.htm#964
http/www.via.com.tw/en/apollo/vt8237.jsp
http/www.amdboard.com/ali_uli_m1573.html

If you compare and contrast these alternatives, it's pretty easy to see that
option 3 has the greatest potential for high performance by virtue of its
higher-speed-than-PCI host bus. If you compare ATA on one of these
higher-speed busses to SATA on a PCI bus, its easy to see how the particular
implementation of SATA hobbles it.

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

In article <JJGdnQtoU9RZ4p_cRVn-jg@comcast.com> arnyk@hotpop.com writes:

> > Seems to me that just a few weeks ago I read a discussion here where
> > people seemed to concur that SATA drives gave poorer performance in
> > DAW applications than plain-old-ATA.

> I think that discussion was colored by a particular implementation of SATA
> controller. There are at least 3 different implementations of it that one
> can find on the market today:

See, you gotta be too smart in order not to make a mistake with these
things. <g>


--
I'm really Mike Rivers (mrivers@d-and-d.com)
However, until the spam goes away or Hell freezes over,
lots of IP addresses are blocked from this system. If
you e-mail me and it bounces, use your secret decoder ring
and reach me here: double-m-eleven-double-zero at yahoo

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"flint" <fcflintNOSPAM@hotmail.com> wrote in message
news:5tmMc.25073$qa2.23666@fe2.texas.rr.com...
>

> Actually, the new SATA 10K RPM drives require the same CPU overhead as ATA
> drives because each block level read and write requires the CPU to process
> the action. A fast drive just makes the potential of more CPU overhead to
be
> consumed by the activity. SCSI drives reduce the block level overhead on
the
> CPUs. The soon to be released Serial attached SCSI (SAS) drives will
reduce
> the CPU overhead since the SCSI protocol is less CPU intensive.
>

Although theoretically correct, as far as r/w operations go, I think you
will find that newer drives in general consume less system resources, and
that the 10k sata drives are particularly efficient.

jb

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"Mike Rivers" <mrivers@d-and-d.com> wrote in message
news:znr1090665400k@trad...
>
> In article <PtednQ4dxvKQdZzcRVn-pw@adelphia.com>
opaloka@REMOVECAPSyahoo.com writes:
>
> > Hard drives in and of themselves can be a drain on cpu power. The newer
SATA
> > 10k rpm drives decrease that signifigantly. A purchase of two wd raptors
> > would make more sense to me than dual cpu's in terms of
price/performance
> > ratio.
>
> Seems to me that just a few weeks ago I read a discussion here where
> people seemed to concur that SATA drives gave poorer performance in
> DAW applications than plain-old-ATA. Perhaps raising the speed from
> 7200 to 10,000 RPM helps, in a similar manner that raising the CPU
> speed allows the use of bloated appications and operating systems
> without apparent slowdown.
>

With sata-150 at 7200 you saw a general -decrease- in performance from
ata-133 at 7200, in any application. The 10k rpm drives are quite a bit
better, but as platters are added they lose that edge somewhat. Interface
technology aside, though, the little Western Digital Raptors - the smaller
the better - are really nice and fast, and cost effective compared to SCSI
hardware.

But you're right about the bloatware. If software was efficient, the whole
industry would dry up and blow away.

jb

 

[Flint]

Archived from groups: rec.audio.pro (More info?)

"reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
news:ZcidnV9tku8fxJ7cRVn-ig@adelphia.com...
>
> "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> news:5tmMc.25073$qa2.23666@fe2.texas.rr.com...
> >
>
> > Actually, the new SATA 10K RPM drives require the same CPU overhead as
ATA
> > drives because each block level read and write requires the CPU to
process
> > the action. A fast drive just makes the potential of more CPU overhead
to
> be
> > consumed by the activity. SCSI drives reduce the block level overhead on
> the
> > CPUs. The soon to be released Serial attached SCSI (SAS) drives will
> reduce
> > the CPU overhead since the SCSI protocol is less CPU intensive.
> >
>
> Although theoretically correct, as far as r/w operations go, I think you
> will find that newer drives in general consume less system resources, and
> that the 10k sata drives are particularly efficient.
>
> jb
>
>
>

What does that mean, "10k SATA drives are particularly efficient?"

The CPU still has to manage each block level read and write to the drive as
well as managing the drive geometry in exactly the same fashion as a
standard IDE drive. While it is true, the faster drives reduce latency and
improve wait states, that doesn't reduce the CPU overhead in any way. If an
application (like most audio applications) are not bottlenecked by the
drive, then increasing the throughput of the drive will not change the
performance of the application unless large amounts of RAM paging is going
on.

I agree that a faster 10k drive on a SATA bus will likely improve the
performance of a DAW, I completely disagree with the logic you used to argue
why that is the case. The only current hard drive technologies that reduce
CPU overhead over IDE is SCSI and Fibre Channel (which utilizes the SCSI
protocol). With SCSI protocols, block level reads & writes are managed by
the controller, not the system's CPU. Intelligent controllers offer other
performance enhancements as well, such as better caching, improved queuing,
and such.

- FLINT

 

[Guest]

Archived from groups: rec.audio.pro (More info?)

"flint" <fcflintNOSPAM@hotmail.com> wrote in message
news:EQRMc.39535$qa2.15655@fe2.texas.rr.com...
>
> "reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
> news:ZcidnV9tku8fxJ7cRVn-ig@adelphia.com...
> >
> > "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> > news:5tmMc.25073$qa2.23666@fe2.texas.rr.com...
> > >
> >
> > > Actually, the new SATA 10K RPM drives require the same CPU overhead as
> ATA
> > > drives because each block level read and write requires the CPU to
> process
> > > the action. A fast drive just makes the potential of more CPU overhead
> to
> > be
> > > consumed by the activity. SCSI drives reduce the block level overhead
on
> > the
> > > CPUs. The soon to be released Serial attached SCSI (SAS) drives will
> > reduce
> > > the CPU overhead since the SCSI protocol is less CPU intensive.
> > >
> >
> > Although theoretically correct, as far as r/w operations go, I think you
> > will find that newer drives in general consume less system resources,
and
> > that the 10k sata drives are particularly efficient.
> >
> > jb
> >
> >
> >
>
> What does that mean, "10k SATA drives are particularly efficient?"
>
> The CPU still has to manage each block level read and write to the drive
as
> well as managing the drive geometry in exactly the same fashion as a
> standard IDE drive. While it is true, the faster drives reduce latency and
> improve wait states, that doesn't reduce the CPU overhead in any way. If
an
> application (like most audio applications) are not bottlenecked by the
> drive, then increasing the throughput of the drive will not change the
> performance of the application unless large amounts of RAM paging is going
> on.
>

Again, A+. I never disagreed with you. But you are being too narrow in
wanting to argue about a feature of the storage subsystem when my statement
was meant to communicate to DAW builders of varying technical knowledge that
use of 10k SATA drives will help with CPU overhead issues. These drives
are, as I said, generally more efficient in that regard than 'last years'
ata drives.

jb

 

[Flint]

Archived from groups: rec.audio.pro (More info?)

"reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
news:mY-dnTHN7NJ8Y57c4p2dnA@adelphia.com...
>
> "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> news:EQRMc.39535$qa2.15655@fe2.texas.rr.com...
> >
> > "reddred" <opaloka@REMOVECAPSyahoo.com> wrote in message
> > news:ZcidnV9tku8fxJ7cRVn-ig@adelphia.com...
> > >
> > > "flint" <fcflintNOSPAM@hotmail.com> wrote in message
> > > news:5tmMc.25073$qa2.23666@fe2.texas.rr.com...
> > > >
> > >
> > > > Actually, the new SATA 10K RPM drives require the same CPU overhead
as
> > ATA
> > > > drives because each block level read and write requires the CPU to
> > process
> > > > the action. A fast drive just makes the potential of more CPU
overhead
> > to
> > > be
> > > > consumed by the activity. SCSI drives reduce the block level
overhead
> on
> > > the
> > > > CPUs. The soon to be released Serial attached SCSI (SAS) drives will
> > > reduce
> > > > the CPU overhead since the SCSI protocol is less CPU intensive.
> > > >
> > >
> > > Although theoretically correct, as far as r/w operations go, I think
you
> > > will find that newer drives in general consume less system resources,
> and
> > > that the 10k sata drives are particularly efficient.
> > >
> > > jb
> > >
> > >
> > >
> >
> > What does that mean, "10k SATA drives are particularly efficient?"
> >
> > The CPU still has to manage each block level read and write to the drive
> as
> > well as managing the drive geometry in exactly the same fashion as a
> > standard IDE drive. While it is true, the faster drives reduce latency
and
> > improve wait states, that doesn't reduce the CPU overhead in any way. If
> an
> > application (like most audio applications) are not bottlenecked by the
> > drive, then increasing the throughput of the drive will not change the
> > performance of the application unless large amounts of RAM paging is
going
> > on.
> >
>
> Again, A+. I never disagreed with you. But you are being too narrow in
> wanting to argue about a feature of the storage subsystem when my
statement
> was meant to communicate to DAW builders of varying technical knowledge
that
> use of 10k SATA drives will help with CPU overhead issues. These drives
> are, as I said, generally more efficient in that regard than 'last years'
> ata drives.
>
> jb
>
>

The logic is the problem. 10K SATA drives are NOT more efficient, unless you
are referring to power consumption, which I have no information about.

10K SATA drives are faster, but not more efficient; they do not reduce the
CPU overhead. That is my point. I also recommend them to people who can
afford SATA, yet cannot afford SCSI, because they are faster. Faster is
usually a good thing (not always).

If you think about it, though, faster ATA drives actually increase the CPU
overhead during continuous reads & writes since the CPU has to manage more
block level I/O requests per second with the newer faster drives. The faster
the ATA drive, the more I/O traffic the CPU could potentially have to
manage.

- FLINT