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
jbayer@ispi.UUCP (Jonathan Bayer) (12/05/89)
dpi@loft386.UUCP (Doug Ingraham) writes: >size. It runs under Dos 3.3 and Unix System V 386/3.2 (Bell Tech/Intel) >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 >Now for the bad news. [stuff deleted regarding slow writes] Is it possible that the extra two sectors/track was causing the problems? It is possible that the last one or two sectors were interfering with the drive being able to start reading a track, or trying to find the proper place to start writing. JB -- Jonathan Bayer Intelligent Software Products, Inc. (201) 245-5922 500 Oakwood Ave. jbayer@ispi.COM Roselle Park, NJ 07204