rbt@tous.uucp (Robert B. Tate) (05/15/91)
I am planning to install a DPT SmartCache (ESDI) disk controller with 4.5
megs of cache this weekend (with a PRIAM ID330-E (model 638) 338Meg
drive). The system is a Microport SysV.3.0e, Wyse 3216 16MHZ i386 and
10Meg of ram. After every thing has been working for a week or so, I will
install the Maxtor 330Meg 330 meg drive, which has been running on a
Adaptec ACB-2322 (B?) for the past 2 years.
Does anyone know _anything_ I sould know?
FYI:
Under MS-DOS, the disk & controller look VERY fast! (I hope it is as fast
under UNIX. When TOUS is baching up outgoing news, it takes for *ever*
for me to get anything done!)
Norten Ver. 4.5 SI, Disk Index = 30.2
CoreTest v2.7;
data transfer rate: 1539.1 KB/sec.
Average Seek time : 0.3 ms (1022 cyls)
Track-Track Seek : 0.3 ms ( '' )
Performance Index : 175.498
Transfer Block Size: 64K
--
rbt@tous.UUCP Robert B. Tate | A little knowledge is a dangerous
{ucf-cs,peora,uunet}!tarpit!tous!rbt | thing. Any less can kill you.cpcahil@virtech.uucp (Conor P. Cahill) (05/17/91)
rbt@tous.uucp (Robert B. Tate) writes: >I am planning to install a DPT SmartCache (ESDI) disk controller with 4.5 >megs of cache this weekend (with a PRIAM ID330-E (model 638) 338Meg >Does anyone know _anything_ I sould know? 1. Each disk drive must be formatted by the DPT formatter (even if you already formatted it with another formatter). 2. Since the controller is not a write thru cache (and that is why it is so fast), you should have an uninterruptible power supply. 3. When you reboot the machine, be sure to wait for the disks to quiet (after seeing the "press any key to reboot") before turning off the machine or pressing any key. If you don't wait, the last bunch of writes that were performed by the OS will not occur. NOTE that this restriction applies to any kind of reboot, including one caused by a panic. >FYI: >Under MS-DOS, the disk & controller look VERY fast! (I hope it is as fast >under UNIX. When TOUS is baching up outgoing news, it takes for *ever* It is very fast under unix also (until you fill up the cache, then it is about average). In other words, compiles or processing news screams, but a dd from /dev/rdsk/0s0 to /dev/null is actually slightly slower than the same command on a system with a WD1007 ESDI controller. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
art@pilikia.pegasus.com (Art Neilson) (05/18/91)
In article <1991May14.235110.18644@tous.uucp> rbt@tous.uucp (Robert B. Tate) writes: > >I am planning to install a DPT SmartCache (ESDI) disk controller with 4.5 >megs of cache this weekend (with a PRIAM ID330-E (model 638) 338Meg >drive). The system is a Microport SysV.3.0e, Wyse 3216 16MHZ i386 and >10Meg of ram. After every thing has been working for a week or so, I will >install the Maxtor 330Meg 330 meg drive, which has been running on a >Adaptec ACB-2322 (B?) for the past 2 years. > >Does anyone know _anything_ I sould know? I have a DPT Smartcache ESDI controller with only the 512K it comes with. It's performance is very good even though DPT recommends an additional 1MB at least, for UNIX based systems. I have 2 380MB ESDI drives connected to the controller, and previously was using a 2322B-8 same as you. I had to low level format both drives prior to the controller change out, I did try just swapping controllers first in the hopes that the DPT could read the Adaptec formatted drive but alas, no such luck. You will want to back your system up to tape or whatever removable media you have before the install, and the reformat must be done with DPT's DPTFMT DOS based utility. Using debug to low level (g=c800:5) like you do with the Adaptec and many other controllers will not work. Other than that, I've had 0 problems. The controller is fast and reliable, and configuration was really easy with DPTFMT utility and nice manual. -- Arthur W. Neilson III | INET: art@pilikia.pegasus.com Bank of Hawaii Tech Support | UUCP: uunet!ucsd!nosc!pilikia!art
jay@metran.UUCP (Jay Ts) (05/18/91)
In article <1991May17.131717.26942@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > rbt@tous.uucp (Robert B. Tate) writes: > > >I am planning to install a DPT SmartCache (ESDI) disk controller with 4.5 > >megs of cache this weekend (with a PRIAM ID330-E (model 638) 338Meg > >Does anyone know _anything_ I sould know? > > 1. Each disk drive must be formatted by the DPT formatter (even if you already > formatted it with another formatter). Am I correct in assuming that this is an MS-DOS utility that is shipped with the controller? > >FYI: > >Under MS-DOS, the disk & controller look VERY fast! (I hope it is as fast > >under UNIX. When TOUS is baching up outgoing news, it takes for *ever* > > It is very fast under unix also (until you fill up the cache, then it > is about average). In other words, compiles or processing news screams, > but a dd from /dev/rdsk/0s0 to /dev/null is actually slightly slower than > the same command on a system with a WD1007 ESDI controller. This is starting to sound interesting. Is this based on a single-user UNIX system, or does it apply to multi-user systems as well? I have been wondering under what conditions the DPT and other caching disk controllers are really effective enough to be worth the extra price and administration complexities. I have been under the impression that as long as the system is serving a number of users, and has a fair amount of main memory (8-16 Mb) for UNIX's disk buffers, the extra speed from the cache on the controller is only about 10-15%, even if it is maxed out at 4 Mb. My own interests are in systems with very fast processors (33 MHz 386, or 25 MHz or faster 486) and a large number of users to support, i.e., systems whose performance is limited not by the CPU but by disk throughput. Any comments? I would like to hear from those who have direct experience with the DPT or other caching controller, and have been able to compare against similar systems with no caching controller. I would really like some cold, hard numbers, but on usenet, I suppose that may be asking too much :-) Jay Ts, Director Metran Technology uunet!pdn!tscs!metran!jay
cpcahil@virtech.uucp (Conor P. Cahill) (05/19/91)
jay@metran.UUCP (Jay Ts) writes: [ about the DPT format utility ] >Am I correct in assuming that this is an MS-DOS utility that is shipped >with the controller? Yes. >This is starting to sound interesting. Is this based on a single-user >UNIX system, or does it apply to multi-user systems as well? The benefits of a caching controller apply to multi-users systems up to a limit (after which the benefits start to dwindle until you get down to performance equal to the non-caching controllers). >I have been wondering under what conditions the DPT and other caching disk >controllers are really effective enough to be worth the extra price and >administration complexities. I have been under the impression that as >long as the system is serving a number of users, and has a fair amount of >main memory (8-16 Mb) for UNIX's disk buffers, the extra speed from the >cache on the controller is only about 10-15%, even if it is maxed out at >4 Mb. This really varies depending upon the implementation of the controller. The two key factors in performance are: a) host-card data transfer interface. (Bus master DMA- best, programmed i/o - worst, shared mem - somewhere in between) b) write-thru-cache - this is definately a looser when you consider performance. >My own interests are in systems with very fast processors (33 MHz 386, or >25 MHz or faster 486) and a large number of users to support, i.e., systems >whose performance is limited not by the CPU but by disk throughput. In that case I would look at the DPT SCSI EISA cashing controller which *should* get you much better performance than the ESDI controller. This is because: 1. the EISA controller uses bus-mastering DMA for very fast bus transfers (the ISA controller uses programmed i/o) (this should be a very big win) 2. The SCSI controller can process multiple disk i/o operations to different drives simultaneously. 3. the SCSI i/o bus has a greater bandwidth than the ESDI one. Note: all this stuff on the EISA controller is heresay, I don't have one in house (although my mouth waters every time I think about getting one :-} One gauge of performance (and yes, I know it is not a hard number) is that while I have a 33MHZ 386 with 16MB of ram and a SCSI controller on my desktop, I do most of my work on the machine with the DPT because I like watching my compiles zoom. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
fr@compu.com (Fred Rump from home) (05/19/91)
jay@metran.UUCP (Jay Ts) writes: >Any comments? I would like to hear from those who have direct experience >with the DPT or other caching controller, and have been able to compare >against similar systems with no caching controller. I would really like >some cold, hard numbers, but on usenet, I suppose that may be asking too >much :-) You got it, no real numbers but lots of satisfaction. Whenever we feel (gut feel can work wonders with experience) that a client will be into heavy i/o, in comes the DPT. We use it ourselves on our internal support system that we do all of our mail and news etc on. Without the DPT 'everything' is slow. Now mail lists snap up and away as quickly as, well - a flash. Really, we are now waiting for the scsi II DPT cache controller to see what magic it will bring. As far as systems go we don't use anything except what you call fast systems. Mostly 33MhZ 486 boxes when the demand for heavy use is there. But an occasional 386 will sneak in there too. fred -- W. Fred Rump office: fred.COMPU.COM 26 Warren St. home: fred@icdi10.COMPU.COM Beverly, NJ. 08010 bang: ...{dsinc uunet}!cdin-1!icdi10!fred 609-386-6846 "Freude... Alle Menschen werden Brueder..." - The Ode
scf@statware.UUCP ( Steve Fullerton) (05/20/91)
In article <31@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >In article <1991May17.131717.26942@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: >... [extra deleted] >I have been wondering under what conditions the DPT and other caching disk >controllers are really effective enough to be worth the extra price and >administration complexities... >... [extra deleted] >Any comments? I would like to hear from those who have direct experience >with the DPT or other caching controller, and have been able to compare >against similar systems with no caching controller... I talked with a DPT representative at the Uniforum show in Dallas and asked him what type of performance increase I would get from tossing out my WD1007SE2 and getting a DPT controller for our 2 ESDI 760 MB Toshiba disks. We are running SCO UNIX 3.2 V2 with 32MB of memory and are trying to improve our database performance. He told me that switching to the DPT controller wouldn't result in a significant improvement. I didn't ask for any details, but thanked him for his honesty. Sorry, no hard numbers, but I hope this helps. -- Steve Fullerton Statware, Inc. scf%statware.uucp@cs.orst.edu 260 SW Madison Ave, Suite 109 orstcs!statware!scf Corvallis, OR 97333 503/753-5382
steve@nuchat.sccsi.com (Steve Nuchia) (05/22/91)
In article <31@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: >I have been wondering under what conditions the DPT and other caching disk >controllers are really effective enough to be worth the extra price and ... >cache on the controller is only about 10-15%, even if it is maxed out at In an ideal world (ie, one in which you have source) you can make certain trade-offs in software, where they belong, and hardware hacks like caching controllers become completely irrelevant. Without the ability to make those trade-offs in software, sometimes hardware is the only answer. In sysV there are a number of places where synchronous writes to the disk are forced. Number one on my personal list of pet peeves is unlink(2), for instance. Using a non-write-through caching controller will make rm -rf /usr/spool/news run as fast as it should instead of taking about 50 ms per article. If you wanted to make the trade-off of non-synchrounous inode updates for faster directory operations, and you don't have source, the only way to do it is in hardware. Depending on your jop mix it may be worth it. -- Steve Nuchia South Coast Computing Services (713) 964-2462 "Innocence is a splendid thing, only it has the misfortune not to keep very well and to be easily misled." --- Immanuel Kant, Groundwork of the Metaphysic of Morals
tmh@prosun.first.gmd.de (Thomas Hoberg) (05/24/91)
In article <1991May22.010734.15694@nuchat.sccsi.com>, steve@nuchat.sccsi.com (Steve Nuchia) writes: |> In article <31@metran.UUCP> jay@metran.UUCP (Jay Ts) writes: |> >I have been wondering under what conditions the DPT and other caching disk |> >controllers are really effective enough to be worth the extra price and |> ... |> >cache on the controller is only about 10-15%, even if it is maxed out at |> |> In an ideal world (ie, one in which you have source) you can make |> certain trade-offs in software, where they belong, and hardware hacks |> like caching controllers become completely irrelevant. Without the |> ability to make those trade-offs in software, sometimes hardware |> is the only answer. |> |> In sysV there are a number of places where synchronous writes to |> the disk are forced. Number one on my personal list of pet peeves |> is unlink(2), for instance. Using a non-write-through caching controller |> will make rm -rf /usr/spool/news run as fast as it should instead of |> taking about 50 ms per article. It's about time USL implemented a NEWS file system (e.g. mount -f dispensible /usr/news). |> |> If you wanted to make the trade-off of non-synchrounous inode updates |> for faster directory operations, and you don't have source, the only |> way to do it is in hardware. Depending on your jop mix it may be worth it. Does anybody do a [E]ISA board with a battery buffered write cache? |> -- |> Steve Nuchia South Coast Computing Services (713) 964-2462 |> "Innocence is a splendid thing, only it has the misfortune |> not to keep very well and to be easily misled." |> --- Immanuel Kant, Groundwork of the Metaphysic of Morals Does the file system hardening (the forced synchronous writes) actually work failsafe? I mean power can get lost at any time, even in the middle of a sector write. A power supply can usually supply DC current for a certain period of time after AC input is lost (right?). Does this always/usually suffice to finish the sector write? I think the power fail line of a PC power supply triggers an NMI on the motherboard. This should keep any further write requests from being started, right? Basically, what I am asking: Are sector writes atomic, or have I just been lucky? After all, if disk inode updates can be incomplete due to partially written sectors, doesn't that invalidate file system hardening? -- tom ---- Thomas M. Hoberg | UUCP: tmh@gmdtub.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET
bill@bilver.uucp (Bill Vermillion) (05/25/91)
In article <684@bigfoot.first.gmd.de> tmh@prosun.first.gmd.de (Thomas Hoberg) writes: >Does anybody do a [E]ISA board with a battery buffered write cache? Yes. Try FAST Technologies, Tempe, Arizona. I know nothing about the board except that is has battery backup for onboard SRAM. It is supposed to write to the disk after power comes back after a crash. Anybody out there using this one that could tell us more. -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP
Bill.Vermillion@sunbrk.FidoNet.Org (Bill Vermillion) (05/25/91)
In article <684@bigfoot.first.gmd.de> tmh@prosun.first.gmd.de (Thomas Hoberg) writes: >Does anybody do a [E]ISA board with a battery buffered write cache? Yes. Try FAST Technologies, Tempe, Arizona. I know nothing about the board except that is has battery backup for onboard SRAM. It is supposed to write to the disk after power comes back after a crash. Anybody out there using this one that could tell us more. -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)