[rescue] Re: Fast Ethernet vs. SS2

[Mike Hebel]

Greg A. Woods wrote:

>
> 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.

I'll concede lack of knowledge on this point - I'm sure I'm not 
understanding the technology well enough to argue the point further. 
I'll have to research it.

> 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.

A packet yes but I'm referring to whole data streams - after all there 
are very few files that can fit in one ethernet packet.

> 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.  :-)

Granted but isn't that was anal-retentive nutcase firewalls are for? ;-)

> 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.

Don't anyone take this the wrong way but I have a hard time believing 
that all the driver/kernel developers understand the hardware 
completely.  I think that if they did, most of the optimization would be 
easy to implement up-front during the design process.  I think they see 
with microscopes and forget the "whole" for the most part.  Again - only 
an opinion and IANASD.

> (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)

Yeah, well...a lot of time in this industry is spent re-inventing the 
wheel.  I've seen in the last two years an AS/400 app get installed that 
did exactly the same things as the old Vax app that they _were_ running 
on.  Minus a couple of small points that a custom programmer could whip 
up for a quarter of what the AS/400 and it's app cost.

Mike Hebel