Date: Thu, 31 Aug 1995 14:47:50 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: gibbs@freefall.FreeBSD.org (Justin T. Gibbs) Cc: FreeBSD-hackers@FreeBSD.Org (FreeBSD hackers) Subject: Re: 4GB Drives Message-ID: <199508312147.OAA12790@gndrsh.aac.dev.com> In-Reply-To: <199508311858.LAA16993@freefall.FreeBSD.org> from "Justin T. Gibbs" at Aug 31, 95 11:58:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
[I have trimmed the cc: all the way back to hackers] > >> > >> >Now, can you all leave me alone for 30 days so I can go get the stripes > >> >working, I have small bottleneck that needs fixed :-):-):-) And can > >> >anyone tell me what the mean and standard deviation of an I/O request to > >> >an aic7870 is before it hits the drive given 0 scsi bus contention? This > >> >seems to greatly effect rotation offset on stripe sets when pushed to > >> >the limits of data coming under the head just after the I/O hits the > >> >drive. > >> > >> Hmm. You'd have to come up with some way to benchmark it since its very > >> dependant on the sequencer code. I'd be interested to here what your > >> results were. :) > > > >:-). How much control do you have over the controller LED in the sequencer > >code? Would it be possible to wink it when an I/O CCB comes in from the > >host, and then double wink it when it goes out the scsi bus? Or am I > >going to have to find a 128 channel logic analyzer and pull my hair out > >for a week to try and capture this :-). > > You could do it in about four lines of total code change. First, you'd > have to leave the led in diagnostic mode: > > The two high bits of SBLKCTL control the led: > > #define DIAGLEDEN 0x80 > #define DIAGLEDON 0x40 > > They are initially cleared by the mask on line 1871 of -current's > aic7xxx.c. Just or back in the diaglen bit on line 1898. > > outb(SBLKCTL + iobase, sblkctl | DIAGLENEN); WAY COOL!! Just what I was looking for!! THANKS!! > Now as far as making it blink, either the kernel driver can manipulate > it via an outb, or you can use any of the or,xor,and sequencer instructions > to manipulate the led. Where to do the triggering depends on what exactly > you want to measure. If you want to time how long it takes for the > sequencer program to pull an entry off the queue, successfully arbitrate, > and go to data_phase (probably the most meaningful benchmark), I'd turn > the led on at line 291 in aic7xxx.seq, and turn off the led somewhere in > the p_dataout: and p_datain: cases. You hit the nail on the head for what I need to measure. > You may also want to double wink the > led if you get a reconnect so that you can differentiate the case when > you lose arbitration to a reconnecting target. As you can see, you > can do a lot with that little led. Don't need to, no one can reselect, there is only 1 disk on the scsi bus in the prototype 2 drive 2 controller base line. I did that to eliminate all contention situations while studing the rotation offset problem and zone size effects. I need to clearly see when each bus goes to data phase so I can understand how the I/O's get processed etc, etc. > >> So, are you planning on using a 3940W for this type of application? > > > >Possibly, prototypes are NCR 825 and aha2940W right now... > > Remeber that the 3940 allows up to 255 queued commands as oposed to > the 16 of the 2940W. As soon as we get better queuing code into > FreeBSD, this will make a difference. Actually I would like to turn off queued commands for the time being, is there an easy way to do that (I have not been delving into the aic code like I should be if I need to ask that one, but since I have your attention any way :-). I need to fully evaluate very simple systems to understand how things are going to behave, and complications like having the controller stacking up queued I/O's on me is going to confuse me looking at timing with respect to when the host releases the I/O in the driver (right now I have a bit to watch on the scope when the stripe layer drops the I/O to the driver layer and then watch the busy bit on the scsi bus, command queueing in the controller is screwing me correlationg the two events :-(). -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508312147.OAA12790>