davidsen@steinmetz.ge.com (William E. Davidsen Jr) (11/27/88)
When I installed a 1:1 Adaptek 2372 controller I expected the track
buffering to make the disk run a lot faster. Instead the transfer rate
in Xenix is down, while the DOS rate is way up.
There was some discussion in one of these groups indicating that xenix
is resetting the controller with every i/o, causing a full track read in
every case, and that there is a patch or option to fix the problem. Can
someone tell me how to do this? Also is it in the 2.3.1 release notes
where I've missed it, or is this yet another case of "fix it by voodoo"?
Thanks for any help available, I'll try SCO when they get back from
holiday, but I believe I saw the answer go by here already.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejack@turnkey.TCC.COM (Jack F. Vogel) (11/28/88)
In article <12676@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >When I installed a 1:1 Adaptek 2372 controller I expected the track >buffering to make the disk run a lot faster. Instead the transfer rate >in Xenix is down, while the DOS rate is way up. I am not entirely clear on exactly how the Adaptek hardware works but I can tell you that the 2372 does NOT have a full track buffer, it achieves its 1:1 ability in some other way. While I ran a 2372 on turnkey I did not notice the performance degradation you talk about, how are you measuring it, strictly empirically or via some hard test? Also how do you have the thing set up?? I found that with the onboard bios enabled and using their format routine that performance was down, the best performance under Xenix was to disable the board's bios and format the drives using WD's latest format utility. We no longer use the 2372, turnkey now is running a WD1006RAH which does have a full track buffer, however this was not due to any complaint with the 2372 but rather with a problem with a new mother- board. With either of these boards I would say performance is improved but not so much that it knocks your socks off or anything. If you have some repeatable test Bill send me some mail so we can compare performance. >There was some discussion in one of these groups indicating that xenix >is resetting the controller with every i/o, causing a full track read in >every case, and that there is a patch or option to fix the problem. Can >someone tell me how to do this? Also is it in the 2.3.1 release notes >where I've missed it, or is this yet another case of "fix it by voodoo"? As the board does not have a full track buffer the problem is not that the kernel is reading sectors when it doesn't have to (Oh, BTW, Adaptek themselves were who told me if doesn't have full track buffering), the problem lies elsewhere. This is just a guess and I would gladly be corrected by someone more knowledgable but I think it may have to do with badtrack determination, when the onboard bios is enabled it does its own badtracking, it uses your last cylinder for its data. My guess here is that this routine is still functioning under Xenix while the kernel driver is ALSO doing badtrack calculation. Again, this is only a guess and if you have the bios disabled it is proven incorrect, it is just that using the CORE test at one point I saw better performance with their firmware turned off. Under DOS you would probably see better performance since they are revectoring bios drive routines to their own. So turn off the bios, reformat the drive and see if things get better. Good luck, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...{nosc|uunet}!turnkey!jack Internet: jack@turnkey.TCC.COM