Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Aug 1996 10:56:02 +0930 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        se@zpr.uni-koeln.de (Stefan Esser)
Cc:        hardware@freebsd.org
Subject:   Re: ASUS SC200 SCSI card?
Message-ID:  <199608240126.KAA24070@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199608232024.WAA22814@x14.mi.uni-koeln.de> from "Stefan Esser" at Aug 23, 96 10:24:26 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser stands accused of saying:
> 
> Michael Smith writes:
>  > Rodney W. Grimes stands accused of saying:
> 
>  > > >  2. PCI latency was set to 80... Michael Smith suggested it be lower than
>  > > >     32 to i've moved it to 20.
>  > > 
>  > > Set it to exactly 32, no more, no less.  ASUS and others have done
>  > > 100's of hours of testing and this was found to be the best setting.
>  > 
>  > Even with two 810's coming up for an opcode every us?  I'd have
>  > thought you'd want to allow for (max latency + one opcode fetch) < 1us
>  > so that the second one didn't starve...
> 
> This isn't how the latency timer works ...
> 
> The latency timer prevents a device with 
> a large internal buffer from sending long
> bursts, which else might cause overruns 
> in receive buffers of other devices.

... but this is (as far as I can tell) exactly what I was saying; the
latency timer defines how long another device can hog the bus.  If the
810 wants the bus every us (it may not, I'm just using this as an
example), then the latency must be set to 1us or less so that a device
that starts a burst just before the 810 requests the bus will stop
before the 810 starves.

If you add another 810, and assume that it comes up for a fetch just
after the first 810, which is held off by a burst from a device that
runs the full time allowed (128 bytes, not too long).  Then the first 810
gets the bus and fills its pipeline; has more than 1us expired? is
the second 810 starved?  Does it actually care?

These are the questions that would lead me to suggest backing the latency
timer down.  Practical experience (offered by RG and co.) suggest that I'm
wrong, but I guess I just don't understand why 8)

> Regards, STefan

Thanks for taking the time to explain...

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608240126.KAA24070>