davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/03/89)
Has anyone tried the caching ESDI controller from Compuadd? Especially with Xenix or UNIX. THis could be a cheap alternative to the DTP. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
akcs.larry@nstar.UUCP (Larry Snyder) (12/03/89)
> Has anyone tried the caching ESDI controller from Compuadd? Especially >with Xenix or UNIX. THis could be a cheap alternative to the DTP. I would like to know if they are marketing an OEM version of the DPT controller - or exactly who is making their controller. Maybe if there were some benchmarks on caching controllers?
dpi@loft386.UUCP (Doug Ingraham) (12/04/89)
In article <201@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > > Has anyone tried the caching ESDI controller from Compuadd? Especially > with Xenix or UNIX. THis could be a cheap alternative to the DTP. > -- > bill davidsen - sysop *IX BBS and Public Access UNIX > davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen > > "Getting old is bad, but it beats the hell out of the alternative" -anon First the good news! I got one of these babies last week. Its easy to install. The manual tells what all but one of the jumpers does. It comes with a special format program called FMT.exe which you must use. This is the best format program I have seen under DOS. It allows you to specify the # of sectors, heads, cylinders interleave, head skew and cylinder skew. The manual indicates that the factory bad track table will be accessed if found (mine had been overwritten so I don't know if this really works). The other program HCU.exe Hard Cache Utility allows you to look at statistics and to disable cacheing. Soft re-boot doesn't clear the statistics so you can boot up under dos and see how good a job the cache controller does. It comes with 1 256k x 9 bit 100ns simm installed. I happened to have 4 1mb x 9 80ns simms so I was able to test several combinations of cache size. It runs under Dos 3.3 and Unix System V 386/3.2 (Bell Tech/Intel) and SCO Xenix 386 2.3. I did all my testing on my CDC Wren III model 94216-106 which is 106 MB unformatted and has 1024 cylinders and 5 heads. The FMT program wanted it to have 36 sectors/track which comes out to 94,371,840 bytes. Using my old WD controller I was only able to get 34 sectors/track (but the drive looked perfect to Unix and DOS). With 34 sectors per track that was 89,128,960 bytes. Since this drive has 21 bad blocks on it and the Bell Tech does sector mapping this resulted in a loss of 10752 bytes. An overall increase of 5,232,128 bytes of usable space. On a Wren V 383 mb drive this would be about 20mb of additional usable space. Now for the bad news. There is something wrong with the way it schedules writes to the drive. As long as you are reading, it seems to work pretty well, although even there I was unable to do a copy of a 48k file to nul: and have the whole file reside in the cache (4mb of cache). Doing multiple chkdsk's would after 3 repetitions be completely from the cache. As soon as you start writing to the drive it becomes slow. Installing Unix from Streaming tape was agony as the tape would spin for a few seconds and then the disk would be slightly active for several minutes. It sounded like it might have been writing a sector and then going back to track 0 for some reason. After installing I ran a couple of simple tests to demonstrate the poor performance. You can try this at home! Hardware was a 16mhz 80386 with 80387 and 4mb of memory. Size of /unix = 439548 bytes. Unix System V/386 ver 3.2u with 256k disk buffers and a WD 1007 controller. time dd if=/unix of=/dev/null bs=256k # first trial real 3.8 user 0.0 sys 1.3 time dd if=/unix of=/dev/null bs=256k # second repetition results are similar real 3.7 user 0.0 sys 1.2 time dd if=/unix of=/tmp/junk bs=256k #first trial real 8.4 user 0.0 sys 2.1 time dd if=/unix of=/tmp/junk bs=256k #second repetition results are similar real 8.5 user 0.0 sys 2.1 Unix System V/386 ver 3.2u with 256k disk buffers and a Compuadd HardCache/ESDI version 1.02 with 256k on board. time dd if=/unix of=/dev/null bs=256k # first trial real 3.6 user 0.0 sys 1.1 time dd if=/unix of=/dev/null bs=256k # second repetition results are similar real 3.5 user 0.0 sys 1.1 time dd if=/unix of=/tmp/junk bs=256k #first trial real 1:08.7 user 0.0 sys 1.8 time dd if=/unix of=/tmp/junk bs=256k #second repetition results are worse! real 1:21.8 user 0.0 sys 1.9 Unix System V/386 ver 3.2u with 256k disk buffers and a Compuadd HardCache/ESDI version 1.02 with 1mb on board. time dd if=/unix of=/dev/null bs=256k # first trial real 3.2 user 0.0 sys 1.1 time dd if=/unix of=/dev/null bs=256k # second repetition cache is working! real 1.9 user 0.0 sys 1.0 time dd if=/unix of=/dev/null bs=256k # third repetition slightly faster real 1.5 user 0.0 sys 1.1 time dd if=/unix of=/dev/null bs=256k # fourth repetition results are similar real 1.5 user 0.0 sys 1.0 time dd if=/unix of=/tmp/junk bs=256k #first trial real 1:32.8 user 0.0 sys 1.7 time dd if=/unix of=/tmp/junk bs=256k #second repetition cache is working! real 1:17.1 user 0.0 sys 1.8 time dd if=/unix of=/tmp/junk bs=256k #third repetition results are similar real 1:16.9 user 0.0 sys 1.8 For those who want to use Xenix with this card, I couldn't get version 2.3.2 to install. It kept telling me to move the partition past the bad spot and I never found a place that was acceptable to it. I tried to use the whole drive for Xenix and then after that message I kept moving forward to keep it on a cylinder boundary so it wouldn't complain about that. The controller mapped this drive to 362 cylinders of 8 heads and 63 sectors. There was no reason top do any mapping for this drive. There is no way to specify the mapping either. If I had a choice I would have selected 1024 cylinders of 10 heads and 18 sectors. With this configuration some of the programs that expect less than 35 sectors/track would have been able to run. My old version of ATDISK failed with 63 sectors, but I knew about that. Conclusion: As things stand this controller seems to work OK for DOS. A cache program will give better performance for the money considering that $500 will buy 4mb of 1 meg simms + the cache program. SCO Xenix 2.3.2 wouldn't install (at least I couldn't get it installed and I have installed it many times before). Write performance was poor under Unix System V/386 ver 3.2 because the controller was probably doing a restore before every write. This wasn't a problem under DOS. The manual mentions Unix and Xenix and this is where this product would shine. Maybe I'll get another in a few months after they get the bugs out. Any questions? -- Doug Ingraham (SysAdmin) Lofty Pursuits (Public Access for Rapid City SD USA) uunet!loft386!dpi
BHB3@PSUVM.BITNET (12/04/89)
In article <201@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) says: > > Has anyone tried the caching ESDI controller from Compuadd? Especially >with Xenix or UNIX. THis could be a cheap alternative to the DTP. >-- > bill davidsen - sysop *IX BBS and Public Access UNIX >davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen > >"Getting old is bad, but it beats the hell out of the alternative" -anon There is a review of it in the December COmputer Shopper. A friend has recomme ded the 15 mbit /sec new Western Digital ESDI. It is cheaper than the COmpu Add by about $200.
pipkins@qmsseq.imagen.com (Jeff Pipkins) (12/05/89)
Like Mikey, I've tried it and I like it. I don't believe in fairy tales like benchmarks, so my test was to do a complete make (make -a all) on a commercial software product. With the cache on the ESDI controller disabled, it took 3 minutes (even without cache it's still a pretty fast ctrlr, w/1:1 interleave) With the cache enabled, it took 1 minute & 10 secs! So which is faster: 386/25 with ESDI cache, or 386/33 without? I have a 386/33 WITH @8-) (Not related to CompuAdd, my opinions are mine, std disclaimers, etc.)
erc@khijol.UUCP (Edwin R. Carp) (12/05/89)
In article <[257922a9:368.1]comp.sys.ibm.pc;1@nstar.UUCP> akcs.larry@nstar.UUCP (Larry Snyder) writes: >> Has anyone tried the caching ESDI controller from Compuadd? Especially >>with Xenix or UNIX. THis could be a cheap alternative to the DTP. > >I would like to know if they are marketing an OEM version of the DPT >controller - or exactly who is making their controller. Maybe if there >were some benchmarks on caching controllers? CompuAdd does publish the benchmarks on the ESDI caching controller - and the controller is made in-house. It works with SCO XENIX, ISC's UNIX, Bell Technologies UNIX, and Microport UNIX. At least those where the ones I worked on this last summer. I was responsible for making sure the controller worked on those products. We ran SCO, ISC, etc. for a week or so, running find, ps, greps, etc. on multiple windows - really loading the system down. I, along with Paul Tichler (Lord of Firmware :-) ), and the other gurus at CompuAdd, debugged the firmware so that it'd run on just about everybody's [XE|U]NIX. And there were some wierd ones, I'm here to tell you.... If I remember right, we ran better than the DPT controller - but I don't remember by how much. ----------------------------------- cut here ----------------------------------- Ed Carp N7EKG/5 (28.3-28.5) erc@puzzle!khijol Austin, Tx; (home) (512) 445-2044 Snail Mail: 1800 E. Stassney #1205 Austin, Tx 78744
psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (12/07/89)
In article <201@sixhub.UUCP>, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > Has anyone tried the caching ESDI controller from Compuadd? Especially > with Xenix or UNIX. THis could be a cheap alternative to the DTP. It was reviewed in the current (I don't know if that's December 1989 or January 1990) COMPUTER SHOPPER. They seemed to like it, and I think they tested it with the UNIX(R) operating system as well as MS-DOS. > bill davidsen, davidsen@sixhub.uucp, uunet!crdgw1!sixhub!davidsen Paul S. R. Chisholm, AT&T Bell Laboratories att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind. UNIX(R) is a registered trademark of AT&T.