Subject: Re: Hardware questions
To: David Laight <David.Laight@btinternet.com>
From: Don Yuniskis <auryn@gci-net.com>
List: port-sparc
Date: 11/26/2001 14:13:43
>David Laight wrote:

>> Are you stating that the network interface on the motherboard is
>> implemented in an inferior manner?  I.e. no DMA, etc.?
>
>No - it is 'identical' to the Sbus cards except that it has certain
>advantages (over the single port Sbus cards):
>
>1) The motherboard probably has the DMA+ chip (not the DMA one) this
>   means you can misalign receive buffers and still get data bursts
>   on the Sbus.  (It is necessary to align the rx buffer then do a
>   software copy to align' IP headers - which is on a 4n+2 boundary
>   within the frame.)
>   (wonder what netBSD does....)


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)

>2) Sbus slot 0 (the motherboard I/O) will (typically) have a higher
>   priority than any of the other Sbus slots, the ethernet interface
>   also has priority over the SCSI interface within the DMA+ silicon.
>   This means that the motherboard ethernet is unlikely to suffer
>   fifo underrun/overrun problems (on a single cpu system).


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*!

>The Sbus priority/latency issues are even worse for any 100M (ethernet
>or FDDI) cards that do not have on-board buffer storage.


Understood.  Again, counting on local silicon on the SBUS card
to deal with the peak transfer rates and then dragging the
data into the processor when the SBUS can support it.

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")?

--don