[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Behavior of retries
- To: Mailing List Recipients <firstname.lastname@example.org>
- Subject: RE: Behavior of retries
- From: David Cline <DavidC@motioneng.com>
- Date: Fri, 27 Mar 1998 09:13:25 -0800
- Resent-Date: Fri, 27 Mar 1998 09:38:38 -0800
- Resent-From: email@example.com
- Resent-Message-ID: <"ZnjVG.0.DE3.asz6r"@electra.znyx.com>
- Resent-Sender: firstname.lastname@example.org
In many systems, particularly data networking, most of the critical data
is handled by DMA transfers. In these systems, deterministic latency
for the bus turns out the be THE critical design issue. Data FIFOs and
all sorts of
other stuff depends on this.
PCI retries after some maximum number of clocks help these systems.
OK, if the target can provide data after 20 clocks but the spec says
retry at 16, we've given up some bus bandwidth.
But if a worst-case target cycle is more like 100 clocks
(ok this is remote but possible if you have multiple bridges
and a burst going somewhere) then we have a major improvement.
If nobody else is waiting, and the initiator continuously retries,
what's the harm?
The master has to wait anyway.
Yes, the above comments completely ignore latency effects of other
DMA devices in the system (that's a different conversation).
But very long target cycles were a common sin in older bus
and the PCI designers provided a quite reasonable solution.
Most PC applications share features that PCI may not shine at:
1) Performance is bound purely by the CPU
2) the CPU gets to resources via direct target access over PCI,
3) the CPU DOES NOT SUPPORT BURST TRANSFERs over PCI to targets.
(ok there are some exceptions to this but in general it is true for x86
Pretty funny for a bus architecture that depends on bursts for
performance, don't you think?
But if you follow it through, you will probably end up agreeing with the
who (although they may not say it explicitly) clearly believe that:
1) data that is critical to CPU performance belongs in the CPU's
LOCAL memory, NOT on the PCI bus
2) DMA and/or intelligent peripherals are needed to move the data
3) Peripherals become responsible for buffering and bursting
appropriate for their application.
4) CPUs should initiate PCI cycles to targets only rarely, for
or perhaps for minimal interrupt status.
And yes, this is not perfect either but welcome to the next level of
From: Mike Dini [SMTP:email@example.com]
Sent: Thursday, March 26, 1998 4:35 PM
To: Mailing List Recipients
Subject: Behavior of retries
>> No, there are not obvious answers here. We have found that
>> behavior of a slow device is to simply hold the bus until it
>> generate the data and ignore the disconnect requirement of
>Hmm, interesting philosophy: "We've noticed that under our
>situation that if we break PCI compliance then we work better,
>it is ok to break compliance."
No, reality. In embedded systems, sometimes the PCI spec is
therefore in order to get a system to work, it is necessary to
PCI specification. You imply that you have a problem with this
>> actually significantly *increases* the performance of a PCI
>> eliminating the retires which chew up most of the bandwidth
of the bus.
>Sometimes, yes reduceing retries would increase throughput.
>is highly dependant on the other devices on the bus, and under
>circumstances might severely restrict throughput.
>For example, suppose there is a bus segment with 4 devices on
>A only talks with B and Device C only talks with D. If device
B is slow
>and breaks the spec by holding on to the bus for long periods
>then it is interfering with the transfers that could happen
between C & D.
I agree, in this situation.
>> Further, if an initiator attempts a different data phase
>> the first, there is a chance that the target device does not
>> full retry address and returns the data from the first phase.
>> off-the-shelf controllers behave this way. Note that on
retries, a target
>> should decode the entire address, not just the BAR to
determine if the
> ^^^^^^ This should be "must"; it is requirement. PCI 2.1,
>188.8.131.52.2, page 51. The only exception is that reads from
>memory space may ignore the byte enables.
>If a device does not decode the entire address then it is
I agree, but not all off-the-shelf controllers and bridges
behave this way.
There are, therefore, hundreds of thousands of 'broken devices'
>> initiator is attempting to get the data that the target
>> responded to with a retry. I believe that an initiator
should be able to
>> do other stuff while it is waiting for the data, but in
>> I have not seen a system that will work if an initiator does
>> problem is compounded with multiple masters.
>Should devices be designed to the specification, or to work
The DEC bridges *DO NOT* fully meet the specification. This is
the not the
only example. Therefore is necessary in a real system to design
known broken devices, even if this means violating the spec.
PLX and AMCC
also have known problems which force compromise. Several SCSI
have unique behavior. Might I note that holding the bus for a
clocks is not a very serious *violation* of the spec?
The DINI Group
1010 Pearl Street, Suite #6
phone (619) 454-3419
FAX (619) 454-1728
cellular (619) 888-9173
home (619) 454-7983