neese@adaptex.UUCP (09/10/90)
>>A few weeks back (late june, I think) there was a thread here on >>tuning the scsi driver for ISC Unix 2.2. I saved most of those >>articles since we were planning on installing 1542A's on some machines >>here. >>My tests seem to indicate that the default values for BUSON, BUSOFF >>and DMASPEED are the fastest. > >they are not. however this (partly) depends on the scsi devices you have. >you *will* experience higher throughput with disks that do read-ahead, caching >etc. provided you have taken care of various other things (read on). >it also depends on the other cards you have installed. by increasing a >cards buson time (and/or decreasing busoff) you are stealing bus cycles from >the other cards. this can cause problems with floppy controllers etc (you'll >get 'controller timeout error' etc.). you should ONLY do this if your bus >has enough total cycles, i.e. is running fast enough to have time for other >card's DMA. if your bus runs at 6/8MHz the adaptec tends to monopolize the bus >during heavy disk usage if you set DMASPEED and BUSON too high (and BUSOFF >too low). especially funny if you use ethernet cards... >you should configure your motherboards bus speed to 10 or 12 MHz, and, of >course, you must not set the adaptec's DMA speed to anything higher or equal >to the motherboards bus speed. The bus speed has nothing to do with the DMA rate. It more important to consider the memory bus rate, which is not driven by the bus clock speed. As the card is a bus master, it does ignore the bus clock speed and uses the programmed DMA rate to do all data transfers. The only signal that can effect the actual transfer rate is the IOCHRDY signal. The DMA speed is completely independent of the BUSON time. If anything, you would want to set the DMA speed as high as the machine will take it. I always recommend 6.7MBytes/sec for the DMA speed as this is much faster than the SCSI bus can run and will help to minimize any disconnects that may occur due to the adapter starving the deivce buffer it is connected to. >also note that no board until now groks 10 MB/s DMA (you can set the old >aha-1540 to that :-). therefor the max settable speed of the 1540A is >8 MB/s. This is onyl according to the jumpers. The programmable rate can be as high as 10MBytes/sec. >>I've installed the Sync option jumper on the controller. > >that jumper doesn't matter - it's setting is overridden by ISC's scsi >driver. Software cannot override this jumper. This jumper simply indicates who will attempt to negotiate for synchronous protocol. If the jumper is installed the AHA-154x board will negotiate for it, if the jumper is removed the adapter expects the device to negotiate for it. I would allow a device to do the negotiation as some devices will do the negotiation on each data transfer. If the 154x does the negotiation, it will only be done once. >>With BUSON 5, BUSOFF 9 and DMASPEED 0; the system seems to be >>performing just fine. > >sure, these are the 'works 100%' parameters. not the 'works 100% and >performs 100%' paramters. The system will perform with these paramters, but not they are not the optimum values. It actually takes some experimentation to find what is best for any given environment. The variables that come into play are the device(s) connected, the size of any given data request, and the actual speed data can be transfered across the AT bus. >>STUFF DELETED<< >>During these tests I've left the DMA speed selection header on the >>board open. This selects the default of 5 Mhz. I'm going to try >>other selections on the jumpers. Is there a reason why this is not a >>good idea? > >these jumper settings are also overridden by the software. Correct. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ uunet!swbatl! {nominil,merch,cpe,mlite}!adaptex!neese
neese@adaptex.UUCP (09/10/90)
>>>Here are the various setting for the DMASPEED: > >>>0 = 5.0 MBytes/sec >>>1 = 6.7 MBytes/sec >>>2 = 8.0 MBytes/sec >>>3 = 10.0 MBytes/sec >>>4 = 5.7 MBytes/sec > >>hmm. where did you get these values from? the 154[02]A manual is different. >>the 1540(without A) manual defines these. (not sure about the last one). > >i *think* i now know The Real Truth (tm :-) ! the above table should be >the one for the *software*. the *jumpers* on the board allow you to set >5, 5.7, 6.7 and 8 MB/sec in that order. am i correct ?! Correct. Also remember that software selection will override the jumpers for the DMA rate. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ uunet!swbatl! {nominil,merch,cpe,mlite}!adaptex!neese
neese@adaptex.UUCP (09/10/90)
>here at nstar, we are running with BUSSON of 9, BUSSOFF of 4 and DMASPEED >of 6.7mhz (using a 1542B, BUSS running at 12.5mhz) and have seen some >drastic improvements in throughput over that of the default configuration. > >Our drives are CDC Wrens IV's - and I assume the the default is that the >cache is enabled on the drives - This is not correct. The CDC Wren VI and later are the only ones to have the cache enabled by default. You need to enable it on all earlier Wren's. The Wren III does not have cache. Some OEM's have had CDC enable the read ahead by default, but in general it comes disabled on the Wren IV, and V. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ uunet!swbatl! {nominil,merch,cpe,mlite}!adaptex!neese
steve@altos86.Altos.COM (Steve Scherf) (09/13/90)
In article <77900002@adaptex> neese@adaptex.UUCP writes: > >... I would allow a device to do the >negotiation as some devices will do the negotiation on each data transfer. >If the 154x does the negotiation, it will only be done once. > Do you really mean this? It seems to me that you really only need to negotiate once, since the parameters of the synchronous transfer are not going to change. It also seems a waste of SCSI bus bandwidth, since going through the extended message sequence before the command phase on each data transfer would add to the overhead of the command. -- Steve Scherf steve@Altos.COM ...!{sun|sco|pyramid|amdahl|uunet}!altos!steve These opinions are solely mine, but others may share them if they like.
src@scuzzy.in-berlin.de (Heiko Blume) (09/16/90)
neese@adaptex.UUCP writes: >Software cannot override this jumper. This jumper simply indicates who will >attempt to negotiate for synchronous protocol. If the jumper is installed the >AHA-154x board will negotiate for it, if the jumper is removed the adapter >expects the device to negotiate for it. I would allow a device to do the >negotiation as some devices will do the negotiation on each data transfer. >If the 154x does the negotiation, it will only be done once. very interesting, someone from ISC posted, that with 2.0.2 the software switched the negotioation off... >>>With BUSON 5, BUSOFF 9 and DMASPEED 0; the system seems to be >>>performing just fine. >> >>sure, these are the 'works 100%' parameters. not the 'works 100% and >>performs 100%' paramters. >The system will perform with these paramters, but not they are not the >optimum values. It actually takes some experimentation to find what is >best for any given environment. The variables that come into play are >the device(s) connected, the size of any given data request, and the >actual speed data can be transfered across the AT bus. one should be *very* careful while experimenting! i have an informtech 386 33Mhz board and a 1542A. when i set DMASPEED to 1 (6.7MB/s) all ran fine, but not for long... after some time (several days) i got 'unexpected NMI in system mode' (of course during fdisk updating the partition table on my 600MB disk when i wanted to activate the DOS partition. it wiped out the fdisk table, VTOC etc...). after installing on other disks parity errors started to show up along with the NMIs ( always in the 5th MB). of course i can run ram tests forever without any errors. the NMIs are also not only popping up on my (personal) board, other people with that informtech board have the same problem. but now for the fun! my friends machine is *identical* to mine, and guess what? he runs at 6.7MB/s happily all the time. the difference is: he runs xenix and i run interactive... (all those people that told me, that they got NMIs too run interactive). looks like a software problem, doesn't it? (of course i ran the DMA test on the aha, no problems). for completeness the config is informtech 386DX 33MHz board with 4 MB 70ns rams on board 4 MB 70ns rams on 32bit ram card BUS speed set to 12 MHz (had to put in pins for jumpers, might that cause the problem? since you say that the DMA is independant of the bus speed i don't think so, and i *wont* try out....) adaptec aha-1542a (ST296N, pro80-s, 94181-702 drives) hercules mono with parralel port dumb 2 port serial card -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
larry@nstar.uucp (Larry Snyder) (09/16/90)
src@scuzzy.in-berlin.de (Heiko Blume) writes: >for completeness the config is >informtech 386DX 33MHz board with > 4 MB 70ns rams on board > 4 MB 70ns rams on 32bit ram card > BUS speed set to 12 MHz (had to put in pins for jumpers, > might that cause the problem? since you say that the DMA is independant > of the bus speed i don't think so, and i *wont* try out....) >adaptec aha-1542a (ST296N, pro80-s, 94181-702 drives) >hercules mono with parralel port >dumb 2 port serial card recently we obtained roy neese's utilities and changed some of the parameters in the drive having to do with the percentage of buffer full before accepting new data (the default was 4 and we changed it to 8). we also enabled the buffer on the drives (CDC shipped the drives with the buffer disabled). The combination of both of these changes resulted in a large increase in throughput. we are running with an 8 mhz DMA, buss on of 10 and off at 5. motherboard is a soyo 25 mhz '386 with 8 megs running 386ix 2.2 -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)