SCO Open Server 5.0.6 versus 5.0.4
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
marian.gutica
comp.unix.sco.misc
3925 articles. 
0 followers.
9 Replies
1236 Views
Similar Articlesnews 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
pcunix"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
bv25"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 :-)
UseNet-Posting-Nospam-74308-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