rob@philabs.Philips.Com (Rob Robertson) (01/01/88)
A while back, I posted the following article asking for information on System Industries Disk Cache Processors 4.3 unix vaxen. A summary of the responses plus the responses in long hand follow. my original article: >We have a pair of Systems Industries Disk Cache Processors (DCPs) on >evaluation. They are hooked to our vaxen (an 8600 and a 785) running >4.3bsd. Since we've had them installed, we really haven't noticed any >real performance gains. However I really have no idea on how to tweak >the kernel to use them better.... > >Is there anyone out there using the DCP on a unix vax? > > Question 1 > Do they help at all? > Question 2 > If they do help how can I configure them to maximize > the performance increase. > >Just knowing someone else out there is using them under BSD would >hearten me. > >rob >-- > william robertson > rob@philabs.philips.com SUMMARY: The DCP's are basically a cache that sit at the controller level. The kernel/device driver don't actually see it. We're using SI 9900 controllers and no modifications have to be made to the driver to use the DCP. Basically everyone pretty much said that the DCP's will give you little or no speed up under BSD unix. The kernel already caches disk blocks in memory. While this is a bit slower than doing it in hardware (as in the DCP's), the kernel has a better understanding of what it will need next and when disk blocks are invalid, so things probably even out. After reading a huge chunk of Bache's "Design of the Unix Operating System", I feel confident in saying that DCP's buy you nothing under System V also. Under VMS, the DCP's are supposed to work out very well, giving a noticeable speed increase. I don't know, but I think that VMS has a way of turning off kernel disk caching. FLAME ON No one from SI ever told us this. Although the DCP manual has some configuration tips for Unix (ie enable write backs), it no where mentions that the performance gains would be minimal at best. Well anyway the DCP's are on their way back to SI. FLAME OFF My suggestion if you want to improve your disk-io performance, is buy more memory and increase your disk block buffers. It'll be cheaper than a DCP, and you'll probably even notice the results. The responses to my article follow. I'd like to thank the people who took the time to help me. From: rich@scgvaxd.SCG.HAC.COM (R. Loo) | |We had tested a beta version of SI's DCP 2 years ago on a VAX 11/785 |running 4.2 BSD and also noticed no performance difference. You didn't |mention what type of controller or disk drives you're using. I believe |we were testing the DCP with an SI 9900 controller and SI 9733 |winchesters. | |The DCP is a big win on VMS systems but basically has no effect on UNIX |systems. According to an SI sales rep, their engineers could never |get much of a performance increase out of UNIX using a DCP. In some |cases, it actually degraded performance. | |I think this is due to the fact that BSD UNIX attempts to do it's own |disk optimization with it's "fast" file system and buffer cache. You |have two strategies working against each other. On our VMS system |(a 11/785 with 9900 controllers and Eagles), the DCP made a significant |increase in performance (up to 80% in some cases) for i/o intensive jobs. |I don't know much about how VMS manages its disk resources so I can't |say much else (someone else did the testing on VMS). | |SI has a VMS tuning guide for the DCP, but nothing for UNIX. They |do have a neat DCP monitor/analyzer that hangs off the controller |that shows things like the DCP hit rate, block transfer size and count, |etc. If you didn't get one of those you should ask them for a loaner - |it really helps when you're trying to figure out what's going on. | |At the time, I came to the conclusion that the DCP would be useless for |our UNIX system. Of course this was 2 years ago, it might have changed |since then. I'd be interested in finding out the conclusion of your |evaluation or if you find out anything different. | |Richard Loo UUCP: {ihnp4, allegra}!scgvaxd!rich | DOMAIN: rich@scgvaxd.hac.com | |Hughes Aircraft Company |Space & Communications Group |Computing Technology Center From: hbb@mtx5d.att.com (Harlan Braude) | |Bill: | |The SI DCPs must be tuned using a special monitor they sell. They used to sell |the DCPs seperately from the monitors, but have since learned that the DCPs |without the monitors are pretty useless. | |The monitors have an EIA port to which an ASCII terminal is connected. Through |menues, the administrator can select which areas to optimize and turn the |processor on and off to compare results. The monitor itself has histogram-style |LEDs which show hit-rate and so forth. | |Harlan Braude |mtx5d!hbb From: Philip Poulos <phil@ecf.toronto.edu> | |We've been running with one for over a year now. |Noticable speed improvements are hard to come by, a 10-15% |speed up will usually not be noticed by an interactive user. |The most important value is the cache hit rate, every hit is |one less disk seek, bigggg improvement. An obvious |speed improvement comes when you are fscking the |disks. You get a huge hit rate ( close to 100%) on the 2nd or |3rd pass. We are using it on a system that file serves a bunch |of microvaxes. The hit rate is usually around 80%, which seems too |high. I guess our user population (predominately undergrads) are always |woking on the same files. We think that the passwd/group files are accessed |heavily from all the remote machines so the caching has helped here. |We are also planning on bumping up our main memory and creating a larger |buffer pool. | | Hope this helps | phil@ecf.toronto.edu |we are running 4.3 ( were running 4.2 ) |cache is on a SI9920 on a MicroVax II From: "Chris Johnston" <chris@gargoyle.uchicago.edu> | |My SI salesman told me that the DCP didn't improve performance on |unix machines. (He claimed the factory had done tests.) | |I always presumed this was because unix is already cacheing and |buffering disk I/O. (Same reason you need sync.) | |cj | |-- |* -- Chris Johnston -- * UChicago Computer Science Dept |* chris@gargoyle.uchicago.edu * 1100 East 58th Street |* ...ihnp4!gargoyle!chris * Chicago, IL 60637 |* johnston@uchicago.BITNET * 312-702-8440 From: "David Morton" <dave@ecrcvax> | |Well we thought about this a long time ago and SI didnt have a |driver and even said at that time they'd considered it but that |4.2/3 file allocation strategies would defeat the whole purpose |of the DCP so we never heard from them since. Sorry to sound so |pessimistic but I doubt it will buy you much. |-- | |Dave Morton |European Computer Industry Research Centre Tel. + (49) 89-92699-139 |Arabellastr 17, 8000 Muenchen 81. West Germany. |dave@ecrcvax.UUCP |mcvax!unido!ecrcvax!dave Again thanks to everyone who took time to respond. rob -- william robertson rob@philabs.philips.com
jfh@killer.UUCP (The Beach Bum) (01/05/88)
The previous poster wrote about the need for yet still more memory for disk buffers. I want to know what vendors are doing to use the memory my machine has to dynamically adjust the size of the disk cache? Why aren't all those pages sitting on the free list being used for block buffers? The one system I've seen which does that runs like a banshee. What gives? - John. -- John F. Haugh II (jfh@killer) | "There are really not many jobs that actually HECI Exploration Co. Inc. | require a penis or a vagina, and all other 11910 Greenville Ave, Suite 600 | occupations should be open to everyone." Dallas, TX. 75243 | - Gloria Steinem
paul@vixie.UUCP (Paul Vixie Esq) (01/06/88)
In article <2659@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: >I want to know what vendors are doing to use the memory my machine has >to dynamically adjust the size of the disk cache? Why aren't all those >pages sitting on the free list being used for block buffers? I asked that question of Erik Fair once, and he said: "beware of a sync(2)!" I guess it would work as a write-through cache, but that's not how the buffer system in UNIX(tm) works right now. Presently, the disk buffers are written out only when the sync(2) call is made or when a buffer needs to be reused. Imagine sync(2)'ing 16MB worth of disk data :-(. A write-through cache would be neat, but it would also be a hell of a lot of work. Does anyone know of a UNIX(tm)-type kernel than does this? -- Paul Vixie ucbvax!dual!ptsfa!vixie!paul