Re: Real-world disconnects

[Gérard Roudier <groudier@club-internet.fr>]

On Fri, 3 Nov 2000, Marco Brambilla wrote:

> groudier@club-internet.fr wrote:
> 
> > > I think MWI is especially useful when you're a master and want to move
> > > data to host RAM without being interrupted.
> > 
> > Hmmm.... It may work like that with some target, but assuming so does not
> > seem sane to me.
> 
> Ok, let's reword:
> 
> MWI is especially useful when you want to tell to the system that you
> would like to not be interrupted (and you guarantee the number of data
> phases)

To be precise, you tell the target that you want to transfer at least an
entire cache-line and a integer number of cache lines with this
transaction and nothing more.

> > And this does not prevent it from accepting large WRITE transactions, in
> > theory. If aliasing MWI to MW makes it disconnect on each cache line, such
> > a memory controller can be stated as poor. 
> 
> If it does aliasing it can disconnect wherever it wants.

The master has no information about the target handling MWI and MW the
same way or in a different way. "It can disconnect whenever it wants" is 
the only thing the master must be careful about target behaviour.

> > In order to honour latency requirement on highly loaded systems, the right
> > trade-off should be to shorten transactions. A single master has no
> > knowledge about such requirement. I want to say that PCI chip designers
> > should be careful about not wasting PCI cycles when PCI transactions get
> > short due to disconnections or short latency timer having been configured,
> > (i.e. they should think about supporting fast back to back transactions
> > for example), instead of whining about being early disconnected by
> > targets.
> 
> 
> This is close to the contrary of what Intel is saying in an application
> note.
> They recommend using bursts as long as possible, using the advanced
> memory commands (MWI, MRL, MRM).

There is no contrary here. When you have numerous masters that want the
PCI to be granted at the same time, PCI transactions may have to be
shorten for latency requirement to be achieved. If PCI devices waste too
many cycles for starting/executing not large transactions, then
throughtput will be wasted. Obviously, the system must try to use
transactions as large as possible in order to get max possible throughput,
each time it is possible. About MWI, MRL, MRM, they are the only way in
PCI to give hints to the target and then allow them to optimize their
behaviour. The Intel application note should be just right, but probably
does not give any value added to the spec. which seem to me quite clear
about how to make a good use of the PCI BUS. When designing a PCI master
you must keep in mind that you may have to share the BUS with devices that
require low latency in order for them not to lose data. On a properly
configured system, the POST software will tell masters about low latency
requirement by configuring latency timers to a low value and will expect
master and target to follow all timing required by the specs. As a result,
you must be careful with handling the latency timer properly. If for
example, a PCI master requires a large latency timer because of some
errata, it can just disallow a PCI system that requires low latency to
work. Btw, there are too many existing PCI devices that require such kind
of show-stopper work-around, as we know...but user generally doesn't :-).

> So the trick is trying to use transactions as long as possible, because
> where you lose efficiency is the rearbitration / transaction setup.

Indeed for throughtput, but not for latency and a PCI master does not know
in what systems it will be used, and must allow a good trade-off to be
possible between latency and throughput on all PCI systems it may be used.
 
> > It is to be said, on the other hand, that this kind of problems will
> only be felt by high-throughput devices.
> 
> 
> In any case I was not complaining, whining or anything :)

My remark wasn't intended to anybpby in particular, but was general.:)

> I was just asking if anyone knows how ACTUAL chipsets (not generic
> targets) behave, but no one seems to have that particular information.

I didn't miss your point, I think.

  Gérard.

> Ciao, Marco.
> 
> -- 
> -------------------------------------------------------
>  Marco BRAMBILLA   
>             
>  STMicroelectronics
>  Via C. Olivetti, 2          
>  20041 Agrate Brianza (MI)        
>  ITALY                       
>  
>  TPA - Wireline Communications Division
>  tel   : +39 039 603.5797   (ST Agrate - TINA 050 5797)
>  mailto:marco-tpa.brambilla@st.com
> -------------------------------------------------------
>