[rescue] Re: Fast Ethernet vs. SS2

[Greg A. Woods]

[ On Monday, November 11, 2002 at 23:33:01 (-0600), Mike Hebel wrote: ]
> Subject: Re: [rescue] Re: Fast Ethernet vs. SS2
>
> Greg A. Woods wrote:
> 
> > It also doesn't quite make sense.  Most drivers already send packets 
> > to the ethernet interface at bus speeds -- the IF then buffers them 
> > out tothe wire.
> 
> Exactly why having a faster output on the wire allows the card to not 
> tie up so many cycles.

Ah, no, that's not right.  At least not for semi-modern microcomputer
hardware like an SS2 with sbus.

I'm not familiar with the specifics of either the hme or be drivers, but
generally speaking what happens in DMA-capable buffered interfaces like
them is that the packet to be transmitted is copied by DMA (i.e. direct
from RAM to the card without the direct assistance of the CPU).  This
happens at the best DMA rate possible for the hardware.  Once the DMA
operation is started the CPU is free to go off and do other work and
normally its memory accesses are interleaved with the bus DMA operations
so there's little or no contention for the CPU.  The bus will be free
for another operation just as soon as the DMA is done (blink-of-an-eye).
Now the interface gets busy serializing the packet out onto the wire.
The bus and CPU go back to doing other operations.  Once the packet is
finished then the interface interrupts the CPU and the driver sets up
another DMA and around the cycle we go.  I.e. it doesn't matter if the
interface is transmitting at 100mbits, 10mbits, or 9600bps, it doesn't
change how much the CPU or bus are "tied up" for a given block of
transmission.

Same goes for receiving data.  The card does all the de-modulating and
bit-packing until the packet is completely received before the CPU
and/or bus get involved.

>  The faster the output - unless the whole amount 
> of data fits in the IF buffer - the faster the data moves off of the 
> bus.  Reduced bus-time means reduced CPU cycles handling those actions.

A whole Ethernet packet (at least for TCP/UDP/IP) should alway fit in
the interface buffer, even in the good old le on the SS2's motherboard, IIRC.

On the other hand the faster the interface the more often the CPU gets
interrupted to service it though and so if you ping-flood that SS2 with
100baseT and big ICMP packets then it's going to get too busy to do
anything else.  However if you ping-flood it with only 10base it'll
still be able to talk to its disks and run your other programs.  :-)

> Still, if it's not being done then why couldn't it?  By my understanding 
> it makes more sense to off-load as much as you can to other components 
> that can take the load so that the overall load is evened out over the 
> whole system.  Something in me is wondering if I'm not leaning a little 
> towards asychronous computing here but then I don't know enough about 
> that yet.

Yes, it does make sense to off-load as much as possible from the CPU and
the shared bus to the interface hardware.  That's why DMA is used in the
first place.  Fairly recently more and more of FreeBSD's and NetBSD's
drivers have been improved to take advantage of further capabilities in
some more advanced ethernet cards, such as hardware-assisted checksumming.

(it's nothing new for the mainframe world of course -- they've been
offloading such I/O processing from the main CPU for over thiry years)

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods at ieee.org>;           <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>