[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bandwidth concerns

It is hard to answer your question in a quantitative sense, since
there are so many variables involved.  In general, I see trouble
occurring when any one of the following rules are broken:

1. Do not rely on any more than getting more than 50% of
    the nominal bandwidth of the PCI bus for payload.  (I
    define that as clock rate times bus width.)

2. You must have a majority of data transfers occur in
    bursts of at least 8 PCI clocks.

3. Latency becomes a problem with other devices if you
    have more than 3 devices bursting on the bus in bursts
    greater than 32.

4. If you have to transition more than one bridge, PCI
    read operations are 10 times more expensive than you
    think they are.

As you probably know, you have a throughput vs. latency
tradeoff in setting the burst size.  If you can control
the runtime environment carefully, you can get a lot of
data through the PCI bus (we have achieved as much as
90% nominal on one embedded application) but if you are
designing for a GP operating system environment, you
have to be verrrry careful about what you are planning.

Good luck on your design...

>From: Sarath Madakasira <smadakas@purros.poly.edu>
>         1. Can the PCI bus support this rate of data transfers for long
>           durations(order of 10's of milliseconds) ?
>         2. How would this kind of latency affect the performance of other
>           bandwidth hungry devices on the bus like the Graphics(monitor)?
>         3. Are there any timeout values or priority bits to be set to use
>           the PCI bus for such long transfers?
>         4.Intel I960 is a I/O processor series which creates a secondary
>          PCI bus on which devices can be mounted. So if I choose to
>         use this processor, should I be putting all my existing devices on
>         the the secondary bus for optimal utilization of the existing
>         primary bus?
>         Any help regarding these issues is immensely useful to me.PLease
>send me in any suggestions you can make about this stuff. Thanks a lot for
>your time.
>                         bye,
>                                         Sarath.

ZNYX Networks - Alan.Deikman@znyx.com - 510 249 0800