1:1 controllers and Xenix

[Jack F. Vogel]

In article <12676 at steinmetz.ge.com> davidsen at 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 at turnkey.TCC.COM