pjd@inesc.UUCP (Paulo Jorge Delgado) (10/11/90)
We have installed the following configuration: DECstation 5000/200 (RISC) - ULTRIX 4.0 - Maxtor XT-8380S DECstation 2100 (RISC) - ULTRIX 4.0 - Maxtor LXT-200 The disks are rated at 14.5ms and 15ms typical seek time against 24ms for DEC's RZ55 disks, but I am getting very bad performance ratios for the Maxtor disks, using the DISKPERF benchmarks: ----------------------------------------------------------------------------- DEC 5000 with RZ55 File create/delete: create 19 files/sec, delete 60 files/sec Directory scan: 4083 entries/sec Seek/read test: 999 seek/reads per second r/w speed: buf 512 bytes, rd 983040 byte/sec, wr 434492 byte/sec r/w speed: buf 4096 bytes, rd 964947 byte/sec, wr 340815 byte/sec r/w speed: buf 8192 bytes, rd 995483 byte/sec, wr 342299 byte/sec r/w speed: buf 32768 bytes, rd 967916 byte/sec, wr 341926 byte/sec ----------------------------------------------------------------------------- DEC 5000 with Maxtor XT-8380S (installed as a RZ55) File create/delete: create 4 files/sec, delete 59 files/sec Directory scan: 4764 entries/sec Seek/read test: 503 seek/reads per second r/w speed: buf 512 bytes, rd 307801 byte/sec, wr 350303 byte/sec r/w speed: buf 4096 bytes, rd 327680 byte/sec, wr 281119 byte/sec r/w speed: buf 8192 bytes, rd 328364 byte/sec, wr 291541 byte/sec r/w speed: buf 32768 bytes, rd 299023 byte/sec, wr 291811 byte/sec ----------------------------------------------------------------------------- DEC 2100 with Maxtor LXT-200 (installed as a RZ55) File create/delete: create 18 files/sec, delete 59 files/sec Directory scan: 1282 entries/sec Seek/read test: 416 seek/reads per second r/w speed: buf 512 bytes, rd 298173 byte/sec, wr 343420 byte/sec r/w speed: buf 4096 bytes, rd 313007 byte/sec, wr 419990 byte/sec r/w speed: buf 8192 bytes, rd 313319 byte/sec, wr 418871 byte/sec r/w speed: buf 32768 bytes, rd 301026 byte/sec, wr 441196 byte/sec I believe this bad performance of the Maxtor disks is due to the kernel not being able to use all the features of this disks. There is no entry in the Ultrix tables (/sys/data/scsi_data.c , /etc/disktab) for the Maxtor disks, so I had to install them as RZ55 devices. I would like to know if there is any configuration procedure I could do (eg : recompiling the kernel with some changes), to improve the disks performance (I am mainly interested in improving the DEC 5000-Maxtor XT8380S pair performance). Many thanks. Paulo Jorge Delgado email: pjd@inesc.inesc.pt INESC - Lisboa - Portugal ...!mcsun!inesc!pjd INESC - Lisboa - Portugal PSI%(+0268)004010314::PJD
iglesias@draco.acs.uci.edu (Mike Iglesias) (10/12/90)
In article <768@inesc.UUCP> pjd@inesc.UUCP (Paulo Jorge Delgado) writes: > > We have installed the following configuration: > >DECstation 5000/200 (RISC) - ULTRIX 4.0 - Maxtor XT-8380S > >DECstation 2100 (RISC) - ULTRIX 4.0 - Maxtor LXT-200 > > The disks are rated at 14.5ms and 15ms typical seek time against 24ms >for DEC's RZ55 disks, but I am getting very bad performance ratios for the >Maxtor disks, using the DISKPERF benchmarks: > > [stuff deleted...] > > I believe this bad performance of the Maxtor disks is due to the kernel >not being able to use all the features of this disks. There is no entry in the >Ultrix tables (/sys/data/scsi_data.c , /etc/disktab) for the Maxtor disks, so I >had to install them as RZ55 devices. > I would like to know if there is any configuration procedure I could do >(eg : recompiling the kernel with some changes), to improve the disks >performance (I am mainly interested in improving the DEC 5000-Maxtor XT8380S >pair performance). You may need to turn on the readahead cache on the disk - we got some Maxtor XT8380s drives that had it turned off. You can do it with the rzdisk program: # rzdisk -c ask /dev/rrz0a Go down to page 8; it will ask you if you want to set the read cache disable bit. Answer "n". Keep going until it asks you if you want to save the info on the disk - answer "y". You should read the man page for rzdisk before you attempt this. Mike Iglesias University of California, Irvine Internet: iglesias@draco.acs.uci.edu BITNET: iglesias@uci uucp: ...!ucbvax!ucivax!iglesias
mjr@hussar.dco.dec.com (Marcus J. Ranum) (10/12/90)
In article <768@inesc.UUCP> pjd@inesc.UUCP (Paulo Jorge Delgado) writes: > We have installed the following configuration: > >DECstation 5000/200 (RISC) - ULTRIX 4.0 - Maxtor XT-8380S > >DECstation 2100 (RISC) - ULTRIX 4.0 - Maxtor LXT-200 > > The disks are rated at 14.5ms and 15ms typical seek time against 24ms >for DEC's RZ55 disks, but I am getting very bad performance ratios for the >Maxtor disks, using the DISKPERF benchmarks: Depending on the way you anticipate using your system, you might want to increase the size of your buffer cache, and change the write scheduling policy to delay scheduling dirty buffers for write. This is done by changing /sys/conf/mips/param.c from: int delay_wbuffers = 0; to int delay_wbuffers = 1; and running a kernel based on that. Bumping the size of the cache can be done in the system config file by putting a line like: bufcache 20 which causes the system to use 20% of its memory for cache. This can make a pretty big difference, **depending on your application**. You're in the land of trade-offs, and there's no such thing as a free lunch. I haven't tried tuning the rotational delay of Maxtors - you might want to play with that some, too. mjr. -- coffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffee
pavlov@canisius.UUCP (Greg Pavlov) (10/14/90)
In article <1990Oct11.211023.2207@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > Depending on the way you anticipate using your system, you might > want to increase the size of your buffer cache, and change the write > scheduling policy to delay scheduling dirty buffers for write..... > What is the downside of this ? Am I taking a bigger chance on ending up with a corrupted database, for instance ? What are potential performance downsides ? > I haven't tried tuning the rotational delay of Maxtors - you might want to > play with that some, too. I have played with the tunefs parameters many times - particularly rotat- ional delay. I have noticed that I do not see any difference (well, no more than 2-5% ) regardless of what I set them to and on what type/brand of disk (RA70's, RA90's, RDnn's, Fuji M2333k, various CDC and HP). - this has been the case ever since DEC introduced it's "own" filesystem - back at ULTRIX 2 (?). Am I missing something ? (yes, I dismount the rele- vant partititon...). greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
bni@modulex.dk (Bent Nielsen) (10/14/90)
iglesias@draco.acs.uci.edu (Mike Iglesias) writes: > # rzdisk -c ask /dev/rrz0a >Go down to page 8; it will ask you if you want to set the read cache disable >bit. Answer "n". Keep going until it asks you if you want to save >the info on the disk - answer "y". >You should read the man page for rzdisk before you attempt this. When I'm using # rzdisk -c ask /dev/rrz0a page 8 can't be shown, it jumps from page 4 to 37. I'm running Ultrix 4.0 on a DECsystem 3100. Any suggestions? -- Bent Nielsen <bni@modulex.dk> A/S MODULEX Phone: +45 44 53 30 11 Lyskaer 15 Telefax: +45 44 53 30 74 DK-2730 Herlev Denmark
mjr@hussar.dco.dec.com (Marcus J. Ranum) (10/15/90)
In article <2933@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: >In article <1990Oct11.211023.2207@decuac.dec.com>, I write: >> Depending on the way you anticipate using your system, you might >> want to increase the size of your buffer cache, and change the write >> scheduling policy to delay scheduling dirty buffers for write..... >> > What is the downside of this ? Am I taking a bigger chance on ending up > with a corrupted database, for instance ? What are potential performance > downsides ? The possible downside of the delayed write is a slightly better chance of losing something. Off the top of my head I can't think of a case where delaying scheduling dirty blocks for write would be a performance hit. Unless your machine is really unstable I wouldn't worry about losing a block or 2 every so often. :) Bumping the buffer cache can be a performance hit if it causes you to start running short of memory for jobs you may have running. If you increase the buffer cache to, say, 20% and notice that you're starting to swap where you weren't before, you're hurting your performance. If you have a machine, for example, that is set up as a file server - nobody logs in and starts running X-windows on it - then boosting the cache may make a lot of sense. If *all* you're doing is file service, you can steal a riff from Plan 9 and just use everything you can for cache. :) > I have played with the tunefs parameters many times - particularly rotat- > ional delay. I have noticed that I do not see any difference (well, no > more than 2-5%) regardless of what I set them to and on what type/brand of > disk (RA70's, RA90's, RDnn's, Fuji M2333k, various CDC and HP). Yep, I've never managed to squeeze the legendary Massive Benefits of tweaking rotational delay out of the disks, either. I did manage to make the disks on my 3100 measurably slower one afternoon, so I suppose I could say I reaped massive benefits by undoing the damage. mjr. -- coffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffee
frank@croton.enet.dec.com (Frank Wortner) (10/15/90)
> - this has been the case ever since DEC introduced it's "own" filesystem - > back at ULTRIX 2 (?). Could you clarify this a bit? My copy of the ULTRIX 4.0 Software Product Description says: "The ULTRIX Operating System is compatible with other software system implementations which include: 4th Berkeley Software Distribution (4BSD), Version 4.2 and Version 4.3: --- File system formats are interchangeable provided disk partitions are compatible." Frank
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (10/16/90)
In article <2714CFCC.8088@orion.oac.uci.edu> Mike Iglesias <iglesias@draco.acs.uci.edu> writes: >You may need to turn on the readahead cache on the disk - we got some >Maxtor XT8380s drives that had it turned off. You can do it with >the rzdisk program: > > # rzdisk -c ask /dev/rrz0a > Another problem is that the generic configuration doesn't use synchronous transfers on the SCSI bus for unknown devices. You have to change the scsi_data.c file (in /sys/data/) to inform the kernel about the drives capabilties. Regards, -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
pavlov@canisius.UUCP (Greg Pavlov) (10/18/90)
In article <1990Oct14.205157.27090@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > In article <2933@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: > > > I have played with the tunefs parameters many times - particularly rotat- > > ional delay. I have noticed that I do not see any difference ........ > > Yep, I've never managed to squeeze the legendary Massive Benefits > of tweaking rotational delay out of the disks, either. .......... > So what is the rationale for proposing it as a possible solution for the original Maxtor problem ? I still don't get it...... greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
pavlov@canisius.UUCP (Greg Pavlov) (10/18/90)
In article <1774@riscy.enet.dec.com>, frank@croton.enet.dec.com (Frank Wortner) writes: > > > - this has been the case ever since DEC introduced it's "own" filesystem - > > back at ULTRIX 2 (?). > > Could you clarify this a bit? My copy of the ULTRIX 4.0 Software Product > Description says: > "The ULTRIX Operating System is compatible with other software > system implementations which include: > Sorry, I was in a hurry and was sloppy. I even had the wrong version of ULTRIX (it was 3, not 2). What I WAS referring to was the introduction of GFS/ufs . I don't know how much of it was "concept", how much reality (we can't afford the source code). But lots of things did change. One was that, up to that point, monkeying with tunefs had an effect, whil e afterward it didn't. (We also had to replace our third party QBUS/SMD/MSCP controllers, but that's another story...) greg pavlov, fstrf, amherst, ny pavlov@stewart.fstrf.org
grr@cbmvax.commodore.com (George Robbins) (10/18/90)
In article <1774@riscy.enet.dec.com> frank@croton.enet.dec.com (Frank Wortner) writes: > > > - this has been the case ever since DEC introduced it's "own" filesystem - > > back at ULTRIX 2 (?). > > Could you clarify this a bit? My copy of the ULTRIX 4.0 Software Product > Description says: > > "The ULTRIX Operating System is compatible with other software > system implementations which include: Ultrix filesystems started to diverge from BSD a long time ago. Ultrix partition tables are not compatible with the 4.3 BSD equivalents, makeing "partitions are compatible" mean that the paritions are located at default ultrix compiled into the driver locations. The filesystem "clean bit" was orginally incompatible with the Berkeley definition, but this was fixed. It's not clear how compatible the new Ultrix 4.0 "clean" notions are with 4.3 BSD. Ultrix fsck violently objects to new superblock fields defined in 4.3 Tahoe and can't "fix" the superblock. It's not obvious whether you can build filesystems with the 4.3 Tahoe that Ultrix can't deal with, or that it tries to and dies an ulgy death... All in all, they are still highly compatible, but it would be nice if Ultrix upgraded their filesystem code to the 4.3 Tahoe level. Living with a frozen 4.2 BSD porting base must be soooo much fun for the Ultrix development group in the 90's... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)