Date: Tue, 9 Jan 1996 22:29:08 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> Cc: Dataradio sysadmin <root@vhf.dataradio.com>, hackers@freebsd.org Subject: Re: AHA 2940 lockup == 2740 lockup? Message-ID: <199601092129.AA15347@Sysiphos> In-Reply-To: "Amancio Hasty Jr." <hasty@rah.star-gate.com> "Re: AHA 2940 lockup == 2740 lockup?" (Jan 9, 12:19)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 9, 12:19, "Amancio Hasty Jr." wrote: } Subject: Re: AHA 2940 lockup == 2740 lockup? } Say, does anyone have a good answer to what the PCI Latency value should } be set to?? } } According to Jim Lowe, ASUS lowered the default PCI Latency value from } 80 to 32 on their new motherboards. Jim thinks that this may not be } a low enough value ... So what is scoop? The latency timer guarantees a certain number of PCI bus cycles to be avaible for each bus-master in turn, before it has to give up to another master. Since there is some start overhead (PCI multiplexes address and data over the same lines, there is one idle cycle to avoid different PCI drivers being active at a time, and there is the DRAM RAS overhead when going to a new RAM page), you need some 16 cycles minimum, or PCI will come out slower than ISA :-) If there is only one bus-master, then the latency timer value does not matter at all. It is different from a time slice in a multi tasking kernel in that it guarantees a MINimum time (and does not limit the MAXimum time) a PCI card may send data once it won bus arbitration. If there is some number of active cards (say 'N'), then the worst case delay to get access to the PCI bus is N * lat_timer PCI cycles (if round robin arbitration is used). In case of a 100baseT Ethernet card with say 64 bytes of FIFO, this must be at most 6.4 microseconds, or 211 PCI bus cycles. With 4 slots filled on the motherboard (and the CPU to PCI bridge and PCI to ISA bridge being another two potential bus masters), there are 6 masters, and thus a latency timer value of 32 (decimal) will be a save maximum. If all devices are active at a time, then there will be time slices of 32 PCI cycles each, of which some 10 will be startup overhead. You won't be able to get more than 70% theoretical PCI throughput this way. But since I haven't seen any PCI chip set which was capable of 1 PCI to DRAM transfer per PCI cycle, there will be some 10 DWORD transfers within those 32 PCI cycles, or 40MB/s ... Using a lat_timer value of 50 cycles (32 hex) there will be max. 20 DWORD transfered per burst, or some 50MB/s. (This is a little oversimplified. A PCI device must give up bus ownership if the latency imer expires and another master is requesting the bus. But it may take several PCI cycles to complete the last transfer. Accessing a ISA device from a PCI bus master may require more than a microsecond (= 33 PCI cycles) for the first byte ... ) The latency timer has to be set to such a value, that there are no FIFO overflows due to too long a delay after requesting the bus. This is a problem with network adapters, which can't easily suspend the sending device in case the FIFO fills. Just make sure that the number of bus masters times the value of the latency timer is less than the number of PCI cycles a FIFO in some PCI chip will be able to buffer its data. Don't choose too low a value, since this will reduce the sustained data rate unnecessarily, if there are competing PCI masters. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601092129.AA15347>