Article 8047 of comp.unix.admin: Xref: intelhf comp.periphs.scsi:8098 comp.unix.sysv386:25766 comp.unix.admin:8047 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!maxed!ed From: ed@maxed.amg.com (Ed Whittemore) Subject: Re: DPT Caching Controller Message-ID: Keywords: DPT Caching SCSI Organization: American Micro Group, Ft. Lee NJ References: <1992Sep25.171613.22442@acuson.com> Date: Sun, 27 Sep 1992 15:49:54 GMT Lines: 43 In article cpcahil@virtech.uucp (Conor P. Cahill) writes: >root@maxed.amg.com (0000-Admin(0000)) writes: > >>But that's just not true; it really isn't so fast, I wish it were. But >>our non-cacheing boards benchmark better every time. > >We have had a DPT card with 2.5MB of memory for the past 3 years in one >system or another. When we have benchmarked the throughput it has come up >slower than the WD1007a wrt sustained throughput. > >However, with that card in the system, the system feels noticably faster, >compiles run faster, etc, etc. I think the performance gain is due to the >fact that the caching controller caches inode writes (which are usually ... > >Another solution to the disk i/o problem is to use a SCSI system with >several small disks that are striped. This setup will give you the best >of all worlds. I mean to talk SCSI here, not ESDI, and our benchmarks show worse performance for the DPT cacheing cards, than the non-cacheing cards from BusTek and Adaptec for EISA, or for ISA. This is true for large or small file reads and writes, for sequential reads and writes with different block and record sizes, and for multiple processes doing disk io. Our experience is that you improve performance by increasing buffer size (V3-NBUF and NHBUF, V4-BUFHWM) and not by adding a cacheing SCSI board. As for ESDI, and IDE, since they depend on the host CPU to do transfers, they benchmark comparatively poorly under multitasking, and we do not use them. For higher performance than SLED (Single Large Expensive Disk), RAID, with Disk Striping is definitely a help. -- Ed Whittemore uunet!maxed!ed ed@maxed.amg.com American Micro Group, Inc. 201-944-3293 From intelhf!ichips!iWarp.intel.com|uunet!maxed!ed Wed Sep 23 00:41:55 PDT 1992 Article: 7975 of comp.unix.admin Xref: intelhf comp.periphs.scsi:8023 comp.unix.sysv386:25563 comp.unix.admin:7975 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!maxed!ed From: ed@amg.com (Ed Whittemore) Subject: Re: DPT Caching Controller Message-ID: Sender: ed@maxed.amg.com (Ed Whittemore) Organization: American Micro Group, Inc., Ft. Lee NJ X-Newsreader: TIN [version 1.1 PL6] References: <1992Sep21.075509.17396@ipars.cts.com> Date: Tue, 22 Sep 1992 20:35:52 GMT Lines: 40 Scott O'Connell (scotto@ipars.cts.com) wrote: : In article <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: : >Currently I have a Esix system with a Adaptec 1542BK controller, and : >performance is abysmal. In a best case scenario, I can get up to : >300K/second throughput. When in the past I ran SCO, I could regularly : >get 800-1200K/second. : > : >It appears that the SCSI driver provided by AT&T leaves a lot to be desired. : >My understanding is that the MFM driver however works fine. What I want to : >do is get a DPT controller and set it up to emulate a WD1003 MFM controller. : > : >Has anyone tried this? : : Just a plug for the DPT controller -- I installed one in a 486/50 EISA : box and have been very happy with the performance. I'm using SCO 3.2.4 : with their drivers for this controller. : : Can't say much about the emulation mode but I highly recommend the controller. : : -- : : Scott O'Connell - N6ZEK UUCP: {nosc, ucsd}!crash!ipars!scotto : Spectrum Data Services ARPA: crash!ipars!scotto@nosc.mil : Carlsbad, CA INET: scotto@ipars.cts.com Our experience is that cacheing controllers are a waste of money on Unix systems, in that the same or better performance can be had from a non-cacheing controller of the same type, i.e., EISA FAST SCSI vs. EISA FAST SCSI cacheing. Perhaps this is due to the overhead of writing thru Unix' buffers. In any case we have benchmarked the DPT, DTC, and AMI cacheing controllers under ISC 3.01, ODT 2.0 with the Byte Unix benchmarks, iozone, etc., and find their numbers generally not quite as good as those from an Adaptec 174(x) or BusTek 74(x) non-cacheing board. What have others found? -- Ed Whittemore uunet!maxed!ed ed@maxed.amg.com American Micro Group, Inc. 201-944-3293 From intelhf!ichips!iWarp.intel.com|ogicse!uwm.edu!wupost!uunet!rde!gator!larry Wed Sep 23 01:24:47 PDT 1992 Article: 25458 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:7982 comp.unix.sysv386:25458 comp.unix.admin:7933 Path: intelhf!ichips!iWarp.intel.com|ogicse!uwm.edu!wupost!uunet!rde!gator!larry From: larry@gator.rn.com (Larry Snyder) Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Subject: Re: DPT Caching Controller Keywords: DPT Caching SCSI Message-ID: Date: 19 Sep 92 22:50:57 GMT Article-I.D.: gator.BuuKsx.5Mz References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Organization: The Gator Public Access Unix Site - 219-289-3745 Lines: 20 ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: >Currently I have a Esix system with a Adaptec 1542BK controller, and >performance is abysmal. In a best case scenario, I can get up to >300K/second throughput. When in the past I ran SCO, I could regularly >get 800-1200K/second. >It appears that the SCSI driver provided by AT&T leaves a lot to be desired. >My understanding is that the MFM driver however works fine. What I want to >do is get a DPT controller and set it up to emulate a WD1003 MFM controller. >Has anyone tried this? No. What release of ESIX are you using? If their SVR4 product, make sure you are using the ufs file system. We have found the ufs file system with SVR4 4.0 (Dell) to be very fast.. -- Larry Snyder internet: larry@gator.rn.com keeper of the Gator uucp: uunet!gator!larry From intelhf!ichips!iWarp.intel.com|ogicse!uwm.edu!spool.mu.edu!uunet!maxed!ed Wed Sep 23 01:26:52 PDT 1992 Article: 25489 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:7995 comp.unix.sysv386:25489 comp.unix.admin:7939 Path: intelhf!ichips!iWarp.intel.com|ogicse!uwm.edu!spool.mu.edu!uunet!maxed!ed From: ed@maxed.amg.com (Ed Whittemore) Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Subject: Re: DPT Caching Controller Keywords: DPT Caching SCSI Message-ID: Date: 21 Sep 92 00:28:44 GMT Article-I.D.: maxed.BuwJzx.B7s References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Organization: American Micro Group, Ft. Lee NJ Lines: 117 In article larry@gator.rn.com (Larry Snyder) writes: >ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: > >>Currently I have a Esix system with a Adaptec 1542BK controller, and >>performance is abysmal. In a best case scenario, I can get up to >>300K/second throughput. When in the past I ran SCO, I could regularly >>get 800-1200K/second. > >>It appears that the SCSI driver provided by AT&T leaves a lot to be desired. >>My understanding is that the MFM driver however works fine. What I want to >>do is get a DPT controller and set it up to emulate a WD1003 MFM controller. > >>Has anyone tried this? > >No. What release of ESIX are you using? If their SVR4 product, make >sure you are using the ufs file system. We have found the ufs file system >with SVR4 4.0 (Dell) to be very fast.. > >-- >Larry Snyder internet: larry@gator.rn.com >keeper of the Gator uucp: uunet!gator!larry I'd be interested to see a dump of `iozone auto` for your Dell system, along with some hardware info. Here follows such a report for SunSoft ISC 3.01 on a Micronics 486-50 EISA machine with a 256k cache, 64 MB, a BT 742A (old model-5 MHz SCSI bus), and a Maxtor P0-12S SCSI-2 drive, with about 8 MB of static buffers: ALL s5 1k file systems. IOZONE: Performance Test of Sequential File I/O -- V1.15 (5/1/92) By Bill Norcott Operating System: Interactive UNIX System V/386 IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 2383127 1872457 1 1024 3382503 2496609 1 2048 3276800 2833989 1 4096 4032984 2759410 1 8192 4032984 3084047 2 512 2356350 1823610 2 1024 340446 2438548 2 2048 3813003 2654622 2 4096 3956890 2872810 2 8192 4032984 2912711 4 512 566032 1807889 4 1024 3495253 2396745 4 2048 600903 2621439 4 4096 3919910 2796202 4 8192 596629 2853268 8 512 812849 864804 8 1024 1013116 335544 8 2048 3368918 1379705 8 4096 3328812 1290555 8 8192 3410003 983424 16 512 1028645 689569 16 1024 781790 481136 16 2048 637674 607210 16 4096 1378571 802353 16 8192 1303590 717895 Completed series of tests real 6:01.52 user 1.64 sys 1:59.18 For a custom 50 MHz EISA machine with 32 MB mem., a BT 747S, an HP CP 2247 SCSI-2F, and 4 MB static buffer: IOZONE: Performance Test of Sequential File I/O -- V1.15 (5/1/92) By Bill Norcott Operating System: Interactive UNIX System V/386 IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 2438548 2279513 1 1024 3495253 2995931 1 2048 3744914 3495253 1 4096 427990 2995931 1 8192 3883614 3883614 2 512 2496609 2097152 2 1024 757094 2953735 2 2048 3883614 3130077 2 4096 762600 3328812 2 8192 4112062 3554494 4 512 1056499 871996 4 1024 2184533 797396 4 2048 3302601 1582756 4 4096 3615779 1607013 4 8192 3524625 1553445 8 512 1331525 871091 8 1024 1536375 1201806 8 2048 1860001 1048576 8 4096 1514189 1222829 8 8192 1919589 1057832 16 512 1005828 1131302 16 1024 1056499 1532165 16 2048 1042710 1022377 16 4096 1022377 1603940 16 8192 1036270 1026129 Completed series of tests real 4:33.55 user 1.48 sys 1:44.03 -- Ed Whittemore uunet!maxed!ed ed@maxed.amg.com American Micro Group, Inc. 201-944-3293 From intelhf!ichips!iWarp.intel.com|uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!ncr-sd!crash!ipars!scotto Wed Sep 23 01:27:51 PDT 1992 Article: 25502 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:8000 comp.unix.sysv386:25502 comp.unix.admin:7942 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!ncr-sd!crash!ipars!scotto From: scotto@ipars.cts.com (Scott O'Connell) Subject: Re: DPT Caching Controller Organization: Spectrum Data Services, Carlsbad, CA Date: Mon, 21 Sep 1992 07:55:09 GMT Message-ID: <1992Sep21.075509.17396@ipars.cts.com> Summary: nice controller Keywords: DPT Caching SCSI References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Lines: 23 In article <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: >Currently I have a Esix system with a Adaptec 1542BK controller, and >performance is abysmal. In a best case scenario, I can get up to >300K/second throughput. When in the past I ran SCO, I could regularly >get 800-1200K/second. > >It appears that the SCSI driver provided by AT&T leaves a lot to be desired. >My understanding is that the MFM driver however works fine. What I want to >do is get a DPT controller and set it up to emulate a WD1003 MFM controller. > >Has anyone tried this? Just a plug for the DPT controller -- I installed one in a 486/50 EISA box and have been very happy with the performance. I'm using SCO 3.2.4 with their drivers for this controller. Can't say much about the emulation mode but I highly recommend the controller. -- Scott O'Connell - N6ZEK UUCP: {nosc, ucsd}!crash!ipars!scotto Spectrum Data Services ARPA: crash!ipars!scotto@nosc.mil Carlsbad, CA INET: scotto@ipars.cts.com From intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!spool.mu.edu!caen!uakari.primate.wisc.edu!crdgw1!rdsunx.crd.ge.com!ariel!davidsen Wed Sep 23 01:29:28 PDT 1992 Article: 25516 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:8006 comp.unix.sysv386:25516 comp.unix.admin:7950 Path: intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!spool.mu.edu!caen!uakari.primate.wisc.edu!crdgw1!rdsunx.crd.ge.com!ariel!davidsen From: davidsen@ariel.crd.GE.COM (william E Davidsen) Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Subject: Re: DPT Caching Controller Keywords: DPT Caching SCSI Message-ID: <1992Sep21.192748.16039@crd.ge.com> Date: 21 Sep 92 19:27:48 GMT References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Sender: usenet@crd.ge.com (Required for NNTP) Reply-To: davidsen@crd.ge.com (bill davidsen) Organization: GE Corporate R&D Center, Schenectady NY Lines: 22 Nntp-Posting-Host: ariel.crd.ge.com In article <1992Sep19.022904.1152@iunet.ann-arbor.mi.us>, ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: | Currently I have a Esix system with a Adaptec 1542BK controller, and | performance is abysmal. In a best case scenario, I can get up to | 300K/second throughput. When in the past I ran SCO, I could regularly | get 800-1200K/second. | | It appears that the SCSI driver provided by AT&T leaves a lot to be desired. | My understanding is that the MFM driver however works fine. What I want to | do is get a DPT controller and set it up to emulate a WD1003 MFM controller. I would think about this one a bit before replace hardware. I haven't tried timing on the ESIX drivers, but the Dell SCSI is certainly brisk, and I'm not sure they changed the drivers. I see 800k+ with ESDI on Dell, and the SCSI is faster (also offline so I can't say how much). I would at least wait and see what other people are getting with ESIX, you may have some other simple problem like 1542 setup (on/off time, whatever) which is hurting your throughput. -- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345 I admit that when I was in school I wrote COBOL. But I didn't compile. From intelhf!ichips!iWarp.intel.com|uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!ddsw1!karl Wed Sep 23 01:30:29 PDT 1992 Article: 25529 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:8012 comp.unix.sysv386:25529 comp.unix.admin:7955 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!ddsw1!karl From: karl@ddsw1.mcs.com (Karl Denninger) Subject: Re: DPT Caching Controller Summary: Dump of info Message-ID: Date: Tue, 22 Sep 1992 02:17:09 GMT References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Organization: Macro Computer Solutions, Inc., Chicago, IL Keywords: DPT Caching SCSI Lines: 83 In article ed@maxed.amg.com (Ed Whittemore) writes: >In article larry@gator.rn.com (Larry Snyder) writes: >>ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: >> >>>Currently I have a Esix system with a Adaptec 1542BK controller, and >>>performance is abysmal. In a best case scenario, I can get up to >>>300K/second throughput. When in the past I ran SCO, I could regularly >>>get 800-1200K/second. >> >>>It appears that the SCSI driver provided by AT&T leaves a lot to be desired. >>>My understanding is that the MFM driver however works fine. What I want to >>>do is get a DPT controller and set it up to emulate a WD1003 MFM controller. >> >>>Has anyone tried this? >> >>No. What release of ESIX are you using? If their SVR4 product, make >>sure you are using the ufs file system. We have found the ufs file system >>with SVR4 4.0 (Dell) to be very fast.. >> >>-- >>Larry Snyder internet: larry@gator.rn.com >>keeper of the Gator uucp: uunet!gator!larry > >I'd be interested to see a dump of `iozone auto` for your Dell system, >along with some hardware info. Here follows such a report for >SunSoft ISC 3.01 on a Micronics 486-50 EISA machine with a 256k cache, >64 MB, a BT 742A (old model-5 MHz SCSI bus), and a Maxtor P0-12S SCSI-2 >drive, with about 8 MB of static buffers: > >ALL s5 1k file systems. Here's my info: OS: Dell SVR4 Issue 2.2 HW: 80486/33 cache system (64kb); 16MB Real Memory Adapter: Adaptec 1542B, 5.7Mhz transfer, sync enabled Drives: MAXTOR 8760S SCSI-I, read-ahead buffer enabled Environment: In multi-user mode, light load present The results aren't bad at all for SCSI-I disk drives rotating at 3600 rpm and 54 sectors/track. Maximum theoretical transfer rate of these disks is 1.658MB/sec from the media. IOZONE: Performance Test of Sequential File I/O -- V1.14 (1/23/92) By Bill Norcott Operating System: POSIX 1003.1-1988 IOZONE: auto-test mode MB reclen bytes/sec written bytes/sec read 1 512 782519 2139951 1 1024 1059167 3382503 1 2048 1398101 4993219 1 4096 1718977 6553600 1 8192 1839607 6990506 2 512 806596 2184533 2 1024 1069975 3495253 2 2048 1398101 5242880 2 4096 1807889 6553600 2 8192 1240918 3130077 4 512 225864 1831573 4 1024 1109604 3495253 4 2048 1402777 3919910 4 4096 1726051 6355006 4 8192 1950839 7108989 8 512 602629 539807 8 1024 717588 444783 8 2048 900065 1992543 8 4096 1250165 3226387 8 8192 1267161 3647220 16 512 682833 482103 16 1024 947330 539633 16 2048 1015569 474066 16 4096 1014955 522980 16 8192 1076843 539113 Completed series of tests -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T Request file: /u/public/sources/DIRECTORY/README for instructions From intelhf!ichips!iWarp.intel.com|uunet!maxed!ed Wed Sep 23 01:34:58 PDT 1992 Article: 25563 of comp.unix.sysv386 Xref: intelhf comp.periphs.scsi:8023 comp.unix.sysv386:25563 comp.unix.admin:7975 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!maxed!ed From: ed@amg.com (Ed Whittemore) Subject: Re: DPT Caching Controller Message-ID: Sender: ed@maxed.amg.com (Ed Whittemore) Organization: American Micro Group, Inc., Ft. Lee NJ X-Newsreader: TIN [version 1.1 PL6] References: <1992Sep21.075509.17396@ipars.cts.com> Date: Tue, 22 Sep 1992 20:35:52 GMT Lines: 40 Scott O'Connell (scotto@ipars.cts.com) wrote: : In article <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) writes: : >Currently I have a Esix system with a Adaptec 1542BK controller, and : >performance is abysmal. In a best case scenario, I can get up to : >300K/second throughput. When in the past I ran SCO, I could regularly : >get 800-1200K/second. : > : >It appears that the SCSI driver provided by AT&T leaves a lot to be desired. : >My understanding is that the MFM driver however works fine. What I want to : >do is get a DPT controller and set it up to emulate a WD1003 MFM controller. : > : >Has anyone tried this? : : Just a plug for the DPT controller -- I installed one in a 486/50 EISA : box and have been very happy with the performance. I'm using SCO 3.2.4 : with their drivers for this controller. : : Can't say much about the emulation mode but I highly recommend the controller. : : -- : : Scott O'Connell - N6ZEK UUCP: {nosc, ucsd}!crash!ipars!scotto : Spectrum Data Services ARPA: crash!ipars!scotto@nosc.mil : Carlsbad, CA INET: scotto@ipars.cts.com Our experience is that cacheing controllers are a waste of money on Unix systems, in that the same or better performance can be had from a non-cacheing controller of the same type, i.e., EISA FAST SCSI vs. EISA FAST SCSI cacheing. Perhaps this is due to the overhead of writing thru Unix' buffers. In any case we have benchmarked the DPT, DTC, and AMI cacheing controllers under ISC 3.01, ODT 2.0 with the Byte Unix benchmarks, iozone, etc., and find their numbers generally not quite as good as those from an Adaptec 174(x) or BusTek 74(x) non-cacheing board. What have others found? -- Ed Whittemore uunet!maxed!ed ed@maxed.amg.com American Micro Group, Inc. 201-944-3293 From intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!rdsunx.crd.ge.com!ariel!davidsen Thu Sep 24 12:29:49 PDT 1992 Article: 7988 of comp.unix.admin Xref: intelhf comp.periphs.scsi:8041 comp.unix.sysv386:25626 comp.unix.admin:7988 Path: intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!crdgw1!rdsunx.crd.ge.com!ariel!davidsen From: davidsen@ariel.crd.GE.COM (william E Davidsen) Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Subject: Re: DPT Caching Controller Message-ID: <1992Sep23.175329.26579@crd.ge.com> Date: 23 Sep 92 17:53:29 GMT References: <1992Sep21.075509.17396@ipars.cts.com> Sender: usenet@crd.ge.com (Required for NNTP) Reply-To: davidsen@crd.ge.com (bill davidsen) Organization: GE Corporate R&D Center, Schenectady NY Lines: 21 Nntp-Posting-Host: ariel.crd.ge.com In article , ed@amg.com (Ed Whittemore) writes: | Our experience is that cacheing controllers are a waste of money on | Unix systems, in that the same or better performance can be had from | a non-cacheing controller of the same type, i.e., EISA FAST SCSI vs. | EISA FAST SCSI cacheing. Perhaps this is due to the overhead of writing | thru Unix' buffers. We tested the Ultrastor caching ESDI controller and found that it took about 30% off the real time to do a medium size make (about 1800 sec CPU) using the writeback option. If you don't use writeback you gain very little. As in "put the memory on the system instead." The possible disadvantages of using writeback have been beaten to death before, please no flamewar, this is just a report of what results we saw. Most systems in my group are running just SCSI now because of size limitations with ESDI. -- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345 Keyboard controller has been disabled, press F1 to continue. From intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!ames!purdue!news.cs.indiana.edu!att!att!drutx!druwa!ddc Thu Sep 24 12:32:02 PDT 1992 Article: 8002 of comp.unix.admin Xref: intelhf comp.unix.sysv386:25646 comp.periphs.scsi:8048 comp.unix.admin:8002 Path: intelhf!ichips!iWarp.intel.com|eff!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!ames!purdue!news.cs.indiana.edu!att!att!drutx!druwa!ddc From: ddc@druwa.ATT.COM (CusterDD) Newsgroups: comp.unix.sysv386,comp.periphs.scsi,comp.unix.admin Subject: Re: DPT Caching Controller Keywords: DPT SCSI Cache Message-ID: <20665@drutx.ATT.COM> Date: 23 Sep 92 14:29:38 GMT References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> Sender: news@drutx.ATT.COM Distribution: comp Lines: 42 in article <1992Sep19.022904.1152@iunet.ann-arbor.mi.us>, ivars@iunet.ann-arbor.mi.us (Ivars Upatnieks) says: > Xref: drutx comp.periphs.scsi:7559 comp.unix.sysv386:25197 comp.unix.admin:7665 > > Currently I have a Esix system with a Adaptec 1542BK controller, and > performance is abysmal. In a best case scenario, I can get up to > 300K/second throughput. When in the past I ran SCO, I could regularly > get 800-1200K/second. > > It appears that the SCSI driver provided by AT&T leaves a lot to be desired. > My understanding is that the MFM driver however works fine. What I want to > do is get a DPT controller and set it up to emulate a WD1003 MFM controller. We have two ESIX 4.0.4 systems w/Adaptek 1540 or 1542 controllers. Both show transfer rates > 880 K bits/sec to a ExaByte 8mm tape using Gnu tar. It is not unusual to see twice this throughput, depending on a lot of other variables. The file system is ufs. (IMHO ufs is superior to S5. I have used both.) Has the kernel been reconfigured to use the native aha controller? Other possibilities include the ROM version, and the SCSI parameters, etc., etc. We had a DPT SCSI EISA controller which we removed in favor of the Adaptec (ISA). We wanted to switch between DOS and UNIX by changing the active partition. It turned out that the DPT would support the SCSI tape (ExaByte) only in native mode, but if the DPT was configured for non-emulation mode, it wouldn't boot DOS. Too bad, it was marginally quicker than the 1540s which I attribute to the EISA bus (no cache in the DPT). If it had had cache, I imagine it would have been much quicker. But we needed both DOS and ExaByte, so we use old reliable. The point of the previous discussion is that the DPT controllers without cache have about the same performance as the 1540s, assuming the same bus. This from an eyeball (not timed) perspective. IMHO if the performance difference isn't perceptable, it isn't worth the extra bucks. Dave Custer ======================================================================== The opionions expressed here are probably not the same as my employer's. From intelhf!ichips!iWarp.intel.com|uunet!virtech!cpcahil Tue Sep 29 00:13:10 PDT 1992 Article: 8046 of comp.unix.admin Xref: intelhf comp.periphs.scsi:8095 comp.unix.sysv386:25763 comp.unix.admin:8046 Newsgroups: comp.periphs.scsi,comp.unix.sysv386,comp.unix.admin Path: intelhf!ichips!iWarp.intel.com|uunet!virtech!cpcahil From: cpcahil@virtech.uucp (Conor P. Cahill) Subject: Re: DPT Caching Controller Message-ID: Keywords: DPT Caching SCSI Organization: Virtual Technologies Inc. References: <1992Sep19.022904.1152@iunet.ann-arbor.mi.us> <1992Sep24.010116.19544@ncsu.edu> <1992Sep25.171613.22442@acuson.com> Date: Sun, 27 Sep 1992 11:59:16 GMT Lines: 36 root@maxed.amg.com (0000-Admin(0000)) writes: >But that's just not true; it really isn't so fast, I wish it were. But >our non-cacheing boards benchmark better every time. We have had a DPT card with 2.5MB of memory for the past 3 years in one system or another. When we have benchmarked the throughput it has come up slower than the WD1007a wrt sustained throughput. However, with that card in the system, the system feels noticably faster, compiles run faster, etc, etc. I think the performance gain is due to the fact that the caching controller caches inode writes (which are usually sync'd by the kernel as part of the file system hardening). Yes, this could result in a problem if we lost power (doesn't matter since we have a UPS). The performance gains were somewhere in the arena of 20 percent, but I don't have the figures lying around to show it. I guess the way to put is is that if you are designing a system that is going to have an average amount of disk access, the caching controller is probably going to help. However, if you are designing a system that is going to need to attain a sustained high level of throughtput to the disks which exceeds the capacity of the cache, I would say that you don't need or want the cacheing controller. Another solution to the disk i/o problem is to use a SCSI system with several small disks that are striped. This setup will give you the best of all worlds. -- *** SENTINEL(tm) The ultimate Debugging Environment - email for more info *** Conor P. Cahill (703)430-9247 cpcahil@virtech.vti.com Virtual Technologies, Inc. 46030 Manekin Plaza Dulles, VA 20166