Hi,
Anybody can point me to info or can state if there is a performance
improvement from running 5.0.6 versus 5.0.4. Application is database access
centered.

Regards,
Marian

news wrote:
> Hi,
> Anybody can point me to info or can state if there is a performance
> improvement from running 5.0.6 versus 5.0.4. Application is database
access
> centered.

I don't think you are going to get a useful answer.

Let's assume that I could authoritatively say that 5.0.6 has
performance related improvements over .4 in certain areas.  I can't
recall if it does or doesn't, but the release notes would surely
mention any.

But so what?  What does that say about YOUR application?  Do we know
where its performance issuees are now?  Nope.  We could assume it's
probably disk bound, because that's a pretty safe assumption most any
time, but even if true, what have you done for better or worse in that
regard already?  Maybe this is an Oracle database and you have it
running on a RAID 5 system.  As that's usually going to be a bad idea,
you could gain nothing even if 5.0.6 did otherwise provide features
that would otherwise improve your lot.  Maybe you have the whole thing
improperly tuned.  Maybe you have it so perfectly tuned that an upgrade
would make it worse because everything is so critically balanced to
what you have now..

There are plenty of good reasons to upgrade to 5.0.6/7.  If that's what
you are lookimg for (a reason to sell the idea to a customer or a
boss), just say so.  If it's performance, those who could comment would
need more info than you provided.

-- 
Tony Lawrence
http://aplawrence.com

"Tony Lawrence" <pcunix@gmail.com> wrote in message
news:1110229486.385837.132150@f14g2000cwb.googlegroups.com...
>
> news wrote:
> > Hi,
> > Anybody can point me to info or can state if there is a performance
> > improvement from running 5.0.6 versus 5.0.4. Application is database
> access
> > centered.
>
> I don't think you are going to get a useful answer.
>
> Let's assume that I could authoritatively say that 5.0.6 has
> performance related improvements over .4 in certain areas.  I can't
> recall if it does or doesn't, but the release notes would surely
> mention any.
>
> But so what?  What does that say about YOUR application?  Do we know
> where its performance issuees are now?  Nope.  We could assume it's
> probably disk bound, because that's a pretty safe assumption most any
> time, but even if true, what have you done for better or worse in that
> regard already?  Maybe this is an Oracle database and you have it
> running on a RAID 5 system.  As that's usually going to be a bad idea,
> you could gain nothing even if 5.0.6 did otherwise provide features
> that would otherwise improve your lot.  Maybe you have the whole thing
> improperly tuned.  Maybe you have it so perfectly tuned that an upgrade
> would make it worse because everything is so critically balanced to
> what you have now..
>
> There are plenty of good reasons to upgrade to 5.0.6/7.  If that's what
> you are lookimg for (a reason to sell the idea to a customer or a
> boss), just say so.  If it's performance, those who could comment would
> need more info than you provided.
>
> -- 
> Tony Lawrence
> http://aplawrence.com
>

It is performance. I have an Ingres 2.0 RDBMS running under SCO 5.0.4. I
have tried to tune Ingres but customer indicates very little improvement.
When system becomes busy users have to wait tens of seconds to save to
database. I am still looking in other areas of tuning Ingres.

Thanks for reply, it confirms what I thought.
Marian

In article <nv4Xd.287$g4.4851@tor-nn1.netcom.ca>,
news <marian.gutica@digital-dispatch.com> wrote:
>
>"Tony Lawrence" <pcunix@gmail.com> wrote in message
>news:1110229486.385837.132150@f14g2000cwb.googlegroups.com...
>>
>> news wrote:
>> > Hi,
>> > Anybody can point me to info or can state if there is a performance
>> > improvement from running 5.0.6 versus 5.0.4. Application is database
>> access
>> > centered.
>>
>> I don't think you are going to get a useful answer.
>>
>> Let's assume that I could authoritatively say that 5.0.6 has
>> performance related improvements over .4 in certain areas.  I can't
>> recall if it does or doesn't, but the release notes would surely
>> mention any.
>>
>> But so what?  What does that say about YOUR application?  Do we know
>> where its performance issuees are now?  Nope.  We could assume it's
>> probably disk bound, because that's a pretty safe assumption most any
>> time, but even if true, what have you done for better or worse in that
>> regard already?  Maybe this is an Oracle database and you have it
>> running on a RAID 5 system.  As that's usually going to be a bad idea,
>> you could gain nothing even if 5.0.6 did otherwise provide features
>> that would otherwise improve your lot.  Maybe you have the whole thing
>> improperly tuned.  Maybe you have it so perfectly tuned that an upgrade
>> would make it worse because everything is so critically balanced to
>> what you have now..
>>
>> There are plenty of good reasons to upgrade to 5.0.6/7.  If that's what
>> you are lookimg for (a reason to sell the idea to a customer or a
>> boss), just say so.  If it's performance, those who could comment would
>> need more info than you provided.
>>
>> -- 
>> Tony Lawrence
>> http://aplawrence.com

>It is performance. I have an Ingres 2.0 RDBMS running under SCO 5.0.4. I
>have tried to tune Ingres but customer indicates very little improvement.
>When system becomes busy users have to wait tens of seconds to save to
>database. I am still looking in other areas of tuning Ingres.

>Thanks for reply, it confirms what I thought.

Tuning the data base will not help if you are limited in other
areas.

When the system is busy and it slows down - run sar [which will
temporarily slow it down] with about 10 itterations at about 15
second intervals.  Less than 15 seconds will cause sar to impact
the ratings.

You also might want to get the sources for the original Iozone 2.1.

I normally run it on a fresh system and save the results and
compare it with results later.

It does file write and read and measures the overall performance
through the file system.  I feel this is more indicative of things
in the realworld than reading and/or writing using dd to the
device.   By using this you will be opening inodes, creating new
blocks, etc.

Sar will tell you if you are running out of CPU, memory, or are
I/O bound at the disk level.

The first thing to do when looking for perfomance improvement is
to find out exactly where the performance is falling down.

I've seen people add memory because they 'thought' it would help
and found it did nothing - because they had problems elsewhere.

I think most of us who have been using systems for quite awhile
have seen people make ill-informed guesses and spend and waste
money on things they didn't need, while not addressing the real
problems.

Bill
-- 
Bill Vermillion - bv @ wjv . com

"Bill Vermillion" <bv@wjv.com> wrote in message news:ID0AqJ.rxL@wjv.com...
> In article <nv4Xd.287$g4.4851@tor-nn1.netcom.ca>,
> news <marian.gutica@digital-dispatch.com> wrote:
> >
> >"Tony Lawrence" <pcunix@gmail.com> wrote in message
> >news:1110229486.385837.132150@f14g2000cwb.googlegroups.com...
> >>
> >> news wrote:
> >> > Hi,
> >> > Anybody can point me to info or can state if there is a performance
> >> > improvement from running 5.0.6 versus 5.0.4. Application is database
> >> access
> >> > centered.
> >>
> >> I don't think you are going to get a useful answer.
> >>
> >> Let's assume that I could authoritatively say that 5.0.6 has
> >> performance related improvements over .4 in certain areas.  I can't
> >> recall if it does or doesn't, but the release notes would surely
> >> mention any.
> >>
> >> But so what?  What does that say about YOUR application?  Do we know
> >> where its performance issuees are now?  Nope.  We could assume it's
> >> probably disk bound, because that's a pretty safe assumption most any
> >> time, but even if true, what have you done for better or worse in that
> >> regard already?  Maybe this is an Oracle database and you have it
> >> running on a RAID 5 system.  As that's usually going to be a bad idea,
> >> you could gain nothing even if 5.0.6 did otherwise provide features
> >> that would otherwise improve your lot.  Maybe you have the whole thing
> >> improperly tuned.  Maybe you have it so perfectly tuned that an upgrade
> >> would make it worse because everything is so critically balanced to
> >> what you have now..
> >>
> >> There are plenty of good reasons to upgrade to 5.0.6/7.  If that's what
> >> you are lookimg for (a reason to sell the idea to a customer or a
> >> boss), just say so.  If it's performance, those who could comment would
> >> need more info than you provided.
> >>
> >> -- 
> >> Tony Lawrence
> >> http://aplawrence.com
>
> >It is performance. I have an Ingres 2.0 RDBMS running under SCO 5.0.4. I
> >have tried to tune Ingres but customer indicates very little improvement.
> >When system becomes busy users have to wait tens of seconds to save to
> >database. I am still looking in other areas of tuning Ingres.
>
> >Thanks for reply, it confirms what I thought.
>
> Tuning the data base will not help if you are limited in other
> areas.
>
> When the system is busy and it slows down - run sar [which will
> temporarily slow it down] with about 10 itterations at about 15
> second intervals.  Less than 15 seconds will cause sar to impact
> the ratings.
>
> You also might want to get the sources for the original Iozone 2.1.
>
> I normally run it on a fresh system and save the results and
> compare it with results later.
>
> It does file write and read and measures the overall performance
> through the file system.  I feel this is more indicative of things
> in the realworld than reading and/or writing using dd to the
> device.   By using this you will be opening inodes, creating new
> blocks, etc.
>
> Sar will tell you if you are running out of CPU, memory, or are
> I/O bound at the disk level.
>
> The first thing to do when looking for perfomance improvement is
> to find out exactly where the performance is falling down.
>
> I've seen people add memory because they 'thought' it would help
> and found it did nothing - because they had problems elsewhere.
>
> I think most of us who have been using systems for quite awhile
> have seen people make ill-informed guesses and spend and waste
> money on things they didn't need, while not addressing the real
> problems.
>
> Bill
> -- 
> Bill Vermillion - bv @ wjv . com

Totally agree with you. In this case servers have plenty of memory ( 1GB). I
have ran sar and did not see a botleneck. Here is a sample from one of the
busy mornings:
dds209.root356> sar 15 10

SCO_SV dds209 3.2v5.0.4 i80386    03/08/2005

09:06:55    %usr    %sys    %wio   %idle (-u)
09:07:10      25       5       2      67
09:07:25      45      12       4      40
09:07:40      57       9       1      34
09:07:55      38      13       8      41
09:08:10      27       6       2      65
09:08:25      50      12       1      37
09:08:40      39       9       2      49
09:08:55      35       8       8      49
09:09:10      45      19       2      34
09:09:25      35      11       5      48

Average       40      10       4      46

Thanks a lot. I will look for Iozone 2.1.

Regards,
Marian

 (news)  07.03.05 in /comp/unix/sco/misc:

(+)


>>> Hi,
>>> Anybody can point me to info or can state if there is a performance
>>> improvement from running 5.0.6 versus 5.0.4. Application is
>>> database
>> access
>>> centered.
>>
>> I don't think you are going to get a useful answer.

ACK.


>It is performance. 
>I have an Ingres 2.0 RDBMS running under SCO 5.0.4.
>I have tried to tune Ingres but customer indicates very little
>improvement. 
>When system becomes busy users have to wait tens of
>seconds to save to database. 

"Save the database"?
What's that?

AFAIK a database stores it values on it's own.

Are you sure your application is using the right algorithm?


>I am still looking in other areas of tuning Ingres.

As Bill states:
Do some mesurement.

For example i was astonished that SCO 5.0.6 writes only with
1MB/s(!) using a RAID5.
Worse: it is blocking(!) one entire CPU only for writing.
If you have 4 CPUs that wouldn't matter. But i have only 2 and 
sometimes OSR 5.0.6 did not like to start the second CPU...
imagine how happy the users are then;-)

One problem maybe that "now adays" there are only an very limited
number of programmers who still know how to write efficent code.
"The application is too slow? By a faster CPU get more RAM!"
But with SCO OSR 5.0.6 you are stuck at 1GHz or a little more?
Too you will not find any(?) new hardware really tested with SCO OSR.
Say a 4GHz HT Pentium IV...


Attention:

Simply coping a file from one dir to an other is really fast!
Do a "sync"  before the copy
Start your stop watch
do the copy of 10 100MB
do again a "sync"
stop the stop watch!
Calculate the time...
Only that will give the true thuput, as OSR is very good in caching
for benschmarks.

Remember:
Modern cheap IDE drives can write with 25MB/s, sustained.
In an RAID5 they slow down too, but the RAID alogrithm wil be done
by the main CPU, not a "funny" obsolete slow i960 RISC proccessor...


One reason why upgraded to 5.06, was, it told,
that the informix 7.0.2 SE database would like to have 1GB of RAM to 
run "perfomant". But whenever start "top", is see 1,7GB of 2GB free
(the old box had 256MB RAM...). is "top" broken? or that Informix 
limited to 256MB?
Every sqlexec process i'm aware takes only max. "only"(*) 32MB of RAM

BTW:
More than 2GB RAM is not supported by OSR5.0.6 AFAIK (That "feature"
SCO made not easy to find...)
Too the files size is limited to 2GB.
You are going to bet on dead/dying horse IMHO!
How big is your data base?



Rainer



(*)
Now adays that's "only"!


(+)
Hm, maybe you can configure your real name?
That would be really nice and polite :-)

In article <76lXd.305$g4.5265@tor-nn1.netcom.ca>,
news <marian.gutica@digital-dispatch.com> wrote:
>
>"Bill Vermillion" <bv@wjv.com> wrote in message news:ID0AqJ.rxL@wjv.com...
>> In article <nv4Xd.287$g4.4851@tor-nn1.netcom.ca>,
>> news <marian.gutica@digital-dispatch.com> wrote:
>> >
>> >"Tony Lawrence" <pcunix@gmail.com> wrote in message
>> >news:1110229486.385837.132150@f14g2000cwb.googlegroups.com...
>> >>
>> >> news wrote:
>> >> > Hi,
>> >> > Anybody can point me to info or can state if there is a performance
>> >> > improvement from running 5.0.6 versus 5.0.4. Application is database
>> >> access
>> >> > centered.
>> >>
>> >> I don't think you are going to get a useful answer.
>> >>
>> >> Let's assume that I could authoritatively say that 5.0.6 has
>> >> performance related improvements over .4 in certain areas.  I can't
>> >> recall if it does or doesn't, but the release notes would surely
>> >> mention any.
>> >>
>> >> But so what?  What does that say about YOUR application?  Do we know
>> >> where its performance issuees are now?  Nope.  We could assume it's
>> >> probably disk bound, because that's a pretty safe assumption most any
>> >> time, but even if true, what have you done for better or worse in that
>> >> regard already?  Maybe this is an Oracle database and you have it
>> >> running on a RAID 5 system.  As that's usually going to be a bad idea,
>> >> you could gain nothing even if 5.0.6 did otherwise provide features
>> >> that would otherwise improve your lot.  Maybe you have the whole thing
>> >> improperly tuned.  Maybe you have it so perfectly tuned that an upgrade
>> >> would make it worse because everything is so critically balanced to
>> >> what you have now..
>> >>
>> >> There are plenty of good reasons to upgrade to 5.0.6/7.  If that's what
>> >> you are lookimg for (a reason to sell the idea to a customer or a
>> >> boss), just say so.  If it's performance, those who could comment would
>> >> need more info than you provided.
>> >>
>> >> -- 
>> >> Tony Lawrence
>> >> http://aplawrence.com
>>
>> >It is performance. I have an Ingres 2.0 RDBMS running under SCO 5.0.4. I
>> >have tried to tune Ingres but customer indicates very little improvement.
>> >When system becomes busy users have to wait tens of seconds to save to
>> >database. I am still looking in other areas of tuning Ingres.
>>
>> >Thanks for reply, it confirms what I thought.
>>
>> Tuning the data base will not help if you are limited in other
>> areas.
>>
>> When the system is busy and it slows down - run sar [which will
>> temporarily slow it down] with about 10 itterations at about 15
>> second intervals.  Less than 15 seconds will cause sar to impact
>> the ratings.
>>
>> You also might want to get the sources for the original Iozone 2.1.
>>
>> I normally run it on a fresh system and save the results and
>> compare it with results later.
>>
>> It does file write and read and measures the overall performance
>> through the file system.  I feel this is more indicative of things
>> in the realworld than reading and/or writing using dd to the
>> device.   By using this you will be opening inodes, creating new
>> blocks, etc.
>>
>> Sar will tell you if you are running out of CPU, memory, or are
>> I/O bound at the disk level.
>>
>> The first thing to do when looking for perfomance improvement is
>> to find out exactly where the performance is falling down.
>>
>> I've seen people add memory because they 'thought' it would help
>> and found it did nothing - because they had problems elsewhere.
>>
>> I think most of us who have been using systems for quite awhile
>> have seen people make ill-informed guesses and spend and waste
>> money on things they didn't need, while not addressing the real
>> problems.
>>
>> Bill
>> -- 
>> Bill Vermillion - bv @ wjv . com
>
>Totally agree with you. In this case servers have plenty of memory ( 1GB). I
>have ran sar and did not see a botleneck. Here is a sample from one of the
>busy mornings:
>dds209.root356> sar 15 10
>
>SCO_SV dds209 3.2v5.0.4 i80386    03/08/2005
>
>09:06:55    %usr    %sys    %wio   %idle (-u)
>09:07:10      25       5       2      67
>09:07:25      45      12       4      40
>09:07:40      57       9       1      34
>09:07:55      38      13       8      41
>09:08:10      27       6       2      65
>09:08:25      50      12       1      37
>09:08:40      39       9       2      49
>09:08:55      35       8       8      49
>09:09:10      45      19       2      34
>09:09:25      35      11       5      48
>
>Average       40      10       4      46
>
>Thanks a lot. I will look for Iozone 2.1.

That only shows you have enough CPU power. 

A Gig of RAM is good if someone has hasn't tuned it so it's not
being used properly.  I don't know about the current SCO version
but on older versions I'd see people putting far too much in
buffers thinking they would get more speed but wind up spending
more time flushing to disk than would presumed reasonable.

A full sar on everything will be helpful.

If it's too big you can email it to me if you'd like.

Bill

-- 
Bill Vermillion - bv @ wjv . com

In article <9SVpoOYbgjB@zocki.toppoint.de>,
Rainer Zocholl  <UseNet-Posting-Nospam-74308-@zocki.toppoint.de> wrote:
> (news)  07.03.05 in /comp/unix/sco/misc:
>
>(+)
>
>
>>>> Hi,
>>>> Anybody can point me to info or can state if there is a performance
>>>> improvement from running 5.0.6 versus 5.0.4. Application is
>>>> database
>>> access
>>>> centered.
>>>
>>> I don't think you are going to get a useful answer.
>
>ACK.
>
>
>>It is performance. 
>>I have an Ingres 2.0 RDBMS running under SCO 5.0.4.
>>I have tried to tune Ingres but customer indicates very little
>>improvement. 
>>When system becomes busy users have to wait tens of
>>seconds to save to database. 
>
>"Save the database"?
>What's that?
>
>AFAIK a database stores it values on it's own.
>
>Are you sure your application is using the right algorithm?
>
>
>>I am still looking in other areas of tuning Ingres.

>As Bill states:
>Do some mesurement.

>For example i was astonished that SCO 5.0.6 writes only with
>1MB/s(!) using a RAID5.

That is horrible.   Is that under load?  

I've found that the SCO file system is a bit slower than other
filesystem extant based on only systems I've worked around - but
I've not seen 1MB/second in about 15 years.

You neglected to say much about the RAID 5.  HW?  SW?  Drives?
I've seen some people implement RAID in IDE drives but since
only the newest handle command queing properly they really don't
work too well in a server environment.  And most of the SATA drives
are just PATA drives with an SATA converter - which gains you
absolutely nothing - but it looks good in the sales brochure.

>Simply coping a file from one dir to an other is really fast!
>Do a "sync"  before the copy
>Start your stop watch
>do the copy of 10 100MB
>do again a "sync"
>stop the stop watch!
>Calculate the time...
>Only that will give the true thuput, as OSR is very good in caching
>for benschmarks.

When I want to run speed tests I typically write 1GB files to make
sure I'm not having results skewed by any caching that may be in
the system - and there surely seems to be a lot anymore.

>Remember:
>Modern cheap IDE drives can write with 25MB/s, sustained.
>In an RAID5 they slow down too, but the RAID alogrithm wil be done
>by the main CPU, not a "funny" obsolete slow i960 RISC proccessor...

I've also seen 25MB as about the maxium writes with IDEs.  Then one
day I had a system get a bit slow [not SCO].  I checked the logs
and there had been a write/retry and the system had moved from
using DMA to PIO and cut the IO to 25% of normal.

Bill

-- 
Bill Vermillion - bv @ wjv . com

(Bill Vermillion)  08.03.05 in /comp/unix/sco/misc:


>>For example i was astonished that SCO 5.0.6 writes only with
>>1MB/s(!) using a RAID5.

>That is horrible.   Is that under load?

No, top said: Idle: 100% Or 99,5%

>I've found that the SCO file system is a bit slower than other
>filesystem extant based on only systems I've worked around - but
>I've not seen 1MB/second in about 15 years.

>You neglected to say much about the RAID 5.  HW?  SW?  Drives?

Sorry, all i know:
3200S DPT/Adaptek with 6(1 hot spare) 18GB SCSI-Seagate 10k drives
There are no write caches enabled.
Not in the drives nor in the RAID controler because the RAID
controler has not battery backup unit (the server is because of
a design flaw of the system "architect" connected to only 
one (big) UPS ignoring is has 2 hase power supplies(and all other
servers have 2 or 3 supplies too.. ;-( shit happens...maybe we can
rewire that crap some day when the UPS batteries need an update...)
Too OSR uses a journalling FS so (AFAIK) it's not wise to allow 
the disk file caching, as the FS assumes "written" when the drive
says "written"...


What makes me wonder:
Why does the write take so much CPU load that an entire CPU is blocked?


>>Simply coping a file from one dir to an other is really fast!
>>Do a "sync"  before the copy
>>Start your stop watch
>>do the copy of 10 100MB
>>do again a "sync"
>>stop the stop watch!
>>Calculate the time...
>>Only that will give the true thuput, as OSR is very good in caching
>>for benschmarks.

>When I want to run speed tests I typically write 1GB files to make
>sure I'm not having results skewed by any caching that may be in
>the system - and there surely seems to be a lot anymore.

ACK. But with 1MB/s you will have to wait 17 minutes for a result!
And in the above server config that would mean: no user can do anything!

In article <9SW9lOqMgjB@zocki.toppoint.de>,
Rainer Zocholl  <UseNet-Posting-Nospam-74308-@zocki.toppoint.de> wrote:
>(Bill Vermillion)  08.03.05 in /comp/unix/sco/misc:
>

>>>For example i was astonished that SCO 5.0.6 writes only with
>>>1MB/s(!) using a RAID5.

>>That is horrible.   Is that under load?

>No, top said: Idle: 100% Or 99,5%

Even worse.

>>I've found that the SCO file system is a bit slower than other
>>filesystem extant based on only systems I've worked around - but
>>I've not seen 1MB/second in about 15 years.

>>You neglected to say much about the RAID 5.  HW?  SW?  Drives?

>Sorry, all i know:
>3200S DPT/Adaptek with 6(1 hot spare) 18GB SCSI-Seagate 10k drives
>There are no write caches enabled.
>Not in the drives nor in the RAID controler because the RAID
>controler has not battery backup unit (the server is because of
>a design flaw of the system "architect" connected to only 
>one (big) UPS ignoring is has 2 hase power supplies(and all other
>servers have 2 or 3 supplies too.. ;-( shit happens...maybe we can
>rewire that crap some day when the UPS batteries need an update...)
>Too OSR uses a journalling FS so (AFAIK) it's not wise to allow 
>the disk file caching, as the FS assumes "written" when the drive
>says "written"...

That sounds truly stupid.  It's like buying a turbo-charged
V-12 import, disconnecting 10 spark plugs, turning off the turbo,
and towing a cement mixer.

I've never heard of anyone turning off drive cache.  He's taken 
a performance SCSI system and tuned it down to the effect of
an old ST506.

By turning off all the cache you lose all the SCSI advantages.
Instead of elevator seeking the heads will be going all over the
place instead of making a pass across the drive.  Having cache in
the drive means that you can have 'zero latency' writes.

What that means is that you can start writing as soon as the head
settle instead of waiting for first sector to come around.  The
saves an average of 1/2 a rev per write because the smarts in the
drive can write to the disk out of order.

Not using the cache on the controller means you slow the data
to the drive down to the actually write speed with no cache instead
of being able to dump data at bus speeds.

I suspect perfomance would increase if the RAID 5 were removed.
RAID 5 is the slowest anyway but this makes it slower.
Re-configuring to RAID 1 would be better.  

I've wondered why the SCSI controllers don't have battery backup
on them.  The last time I saw any were about 10 years ago.

You could have a power loss, and when the system power came back,
the data in the cache on the controller would be written to disk.

A few years ago IBM had drives that made sure the writes to the
disk from the on-board cache were flushed.

These were on 10K drives, and on power loss the drive was smart
enough to use the inertial engergy of the disk, and turn the
platter motor into a generator to give enough power to the drive
electronics to flush the cache to the platters.

That drive has since been discontinued.  I've wondered if part
of this was because of the way drives are changing that with the
smaller and lighter drives there is not enough intertia to do this
effectively.

The more robust things are the more they cost - and cost seems to
be the driving factor so often.

>
>What makes me wonder:
>Why does the write take so much CPU load that an entire CPU is blocked?

Because the CPU has to do all the work.  Normally the data goes
to the RAID cache and the disk cache at disk speed.  But all the
advantage of smart controllers are lost when they are disabled.
And if writes are going to be in the order they are received
instead of re-ordering the writes in both the controller cache and
the disk cache, you are probably wasting a lot of time in seeking
back and forth writing each segment individually.   That's my take
off the top of my head.   

I suspect you need an architect who understands how things work. 
It appears that person made assumptions.   That is just speculation
based on the little information you gave.

>>>Simply coping a file from one dir to an other is really fast!
>>>Do a "sync"  before the copy
>>>Start your stop watch
>>>do the copy of 10 100MB
>>>do again a "sync"
>>>stop the stop watch!
>>>Calculate the time...
>>>Only that will give the true thuput, as OSR is very good in caching
>>>for benschmarks.

>>When I want to run speed tests I typically write 1GB files to make
>>sure I'm not having results skewed by any caching that may be in
>>the system - and there surely seems to be a lot anymore.

>ACK. But with 1MB/s you will have to wait 17 minutes for a
>result! nd in the above server config that would mean: no user
>can do anything!

With 1MB writes I can see that.   I use the larger writes
to make sure that cache is not warping the values.  But since you
have no cache that doesn't enter into it.

On systems with decent memory and drive caches I can see great
performance with 20MB writes and when I got to 100, 500 or 1GB
I get a real value.

I just checked some saved Iozone values on a machine with
256MB, 650MHz PIII, Promise add-in ATA-133 controller, [UDMA 6]
Maxtor 120 GB drive. 

I get 20MB/sec writes and 45MB/sec reads.  FreeBSD UFS file system.
8MB of cache in the drive controller which is helping the reads.

And it's in a configuration that really doesn't fit the server
model.

Bill
-- 
Bill Vermillion - bv @ wjv . com