Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Aug 1996 22:24:26 +0200 (MET DST)
From:      Stefan Esser <se@zpr.uni-koeln.de>
To:        Michael Smith <msmith@atrad.adelaide.edu.au>
Cc:        rgrimes@GndRsh.aac.dev.com (Rodney W. Grimes), pjchilds@imforei.apana.org.au, se@zpr.uni-koeln.de, freebsd-hardware@FreeBSD.ORG
Subject:   Re: ASUS SC200 SCSI card?
Message-ID:  <199608232024.WAA22814@x14.mi.uni-koeln.de>
In-Reply-To: <199608222359.JAA17181@genesis.atrad.adelaide.edu.au>
References:  <199608222347.QAA13093@GndRsh.aac.dev.com> <199608222359.JAA17181@genesis.atrad.adelaide.edu.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

The NCR53c810 got only a small FIFO anyway.
It will give up the PCI bus so fast that 
even the fastest latency timer setting (the
lowest value) has no effect at all.

But Rod is of course right: The default of
32 should be used except if you have a very
controlled environment that has only a few 
PCI bus-masters with extremely high data 
rates. In such a case a higher latency timer
value might allow for longer bursts and a
higher sustained PCI data rate. But you 
can't use a device that is unable to stop
its data source and that does not have a 
large FIFO in such a case. 
(Ie. a SCSI chip could just stop the sending
device and thus avoid a buffer overflow, while 
an Ethernet chip most probably can't :)

Regards, STefan



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