Greetings and Proclamations!

>David Laight mentioned:

>> OK.  Ah, I see.  "Murphy's law" has the ethernet packet built
>> in such a way that the data and header fields won't *both* be
>> aligned the same way.  And, if you tweek the LANCE's DMAC to
>> align *one* of them, then the other ends up misaligned by a
>> "half word".  No win situation...  So, configure the DMAC
>> to align the *bulk* of the data and incur the cost of moving the
>> rest "by hand"...
>>
>> This, of course, assumes the SBUS will tolerate the misaligned
>> transfers (i.e. your point exactly)
>
>You need to get the system doing 4 word bursts on the sbus.  The cost
>of single 16-bit transfers is far too high!  The DMA+/DMA2 has 2 cache
>lines used to buffer the lance - memory traffic.  The way these are
>flushed, invalidated and read ahead is somewhat unusual and is based
>on explicit knowledge of the transfers that the lance will request.


Understood.

>> OK.  This also makes sense.  And, a rational tradeoff -- data
>> on the SCSI will still *be* there when you get around to it
>> a bit later; the network packet *won't*!
>
>Absolutely - unfortunately I came to the conclusion that the cpu is given
>priority over the sbus on accesses to main memory.  This will slightly
>improve SCSI benchmarks (the cpu will not stall on memory until it is


Huh?  Oh, if using the *onboard* SCSI!  Presumably, the advantage
disappears if the CPU has to talk to an SBUS SCSI...?

>looping waiting for the data), but has a serious, detremental effect on
>network traffic when the cpu is trying to use 100% of teh memory bandwidth.
>(I never did find out whether the relevant arbiter worked that way).
>>
>> Thanks!  A truly enlightening description of the problem!
>>
>> Does there exist any documentation describing the various
>> hardware in this sort of detail?  Or, is it only acquired
>> "through experience" (i.e. by being burned and then trying to
>> figure out "why")?
>
>Some of it is documented, but usually only in places you search while
>scratching your head trying to work out why the hell the system doesn't
>work on a customer site :-)

Of course!  And you always find something in the last place you look...
:>

>Unfortunately you need the errata documents for the chipsets these are
>particularly difficult to obtain!


I think that level of detail is more than I would care for.
I was more interested in the basic layout of the hardware,
functions embodied in each subsystem, etc.

E.g., learning that the "DMA chip" (?) has SCSI, etc.
built in did a lot to explaining some of the odd combinations
of features...

Thx,
--don