From owner-freebsd-hackers Wed Apr 14 8:19:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id B10AF15266 for ; Wed, 14 Apr 1999 08:19:26 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id LAA11788; Wed, 14 Apr 1999 11:17:11 -0400 (EDT) Message-Id: <199904141517.LAA11788@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 14 Apr 1999 10:10:37 -0400 To: Mike Smith From: Dennis Subject: Re: PCI burst determination Cc: hackers@freebsd.org In-Reply-To: <199904132319.QAA01942@dingo.cdrom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 04:19 PM 4/13/99 -0700, you wrote: >> At 02:27 PM 4/13/99 -0700, Mike Smith wrote: >> >> >> >> Is there a way to determine the max burst of the PCI bridge on the >> >> MB for controller optimization? I dont see a fuction...is it stored >> >> somewhere? >> > >> >PCI is arbitrated with a latency timer, so there is no maximum burst >> >length per se. As for limitations in the bridge chipset, you're >> >probably going to want to look up the documentation for the individual >> >bridges. >> > >> >However, having said, that, as a general rule with PCI bursting "longer >> >is better". >> >> Well, mike, the goal of my question was to be able to dynamically determine >> the burst rate of the bridge installed to tune it at config time, allowing >> for automatic optimization. > >I fail to see any utility in this. Bursts are terminated either by the >initiator or the arbiter; it's irrelevant as to which does the >termination from a performance standpoint. > >As the designer of the initiator, you should just open up with a burst >when you have data, and keep going until you either run out of data or >you get arbited off the bus. > >There's no other behaviour model that makes any sense; why would you >want to try to second-guess the exact count at which the bridge (which >typically contains the arbiter) is going to cut you off? That's its >job, let it do it. You are being a bit short-sighted..... With a multi-channel controller you have several controllers sharing a single PCI dma fifo, and in order to maximize efficiency you need to maximize the emptying of the central fifo...if you fill it with exactly the burst of the bridge then you get maximum performance. If the central fifo doesnt empty on a burst it forces a hold-off of other controllers that may need servicing. Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message