Re: Ethernet Error Correction

[Richard B. Johnson]

On Tue, 25 Sep 2001, Ben Greear wrote:

> "Richard B. Johnson" wrote:
> > 
> > On Tue, 25 Sep 2001, Karel Kulhavy wrote:
> > 
> > > What about implementing an Ethernet error correction in Linux kernel?
> > >
> > 
> > Ethernet uses hardware error detection. Only good packets get through.
> > Therefore there is nothing that a driver in the kernel could do to
> > recover an otherwise errored packet because the packet doesn't exist.
> > 
> 
> That's probably the default of most chipsets, but I wonder if you could
> tell it to send the busted packets up the stack anyway.  Then, the driver
> could make the decision in software whether or not to correct/foward, or
> discard the packet...  I assume that in order to detect a CRC error,
> the NIC already has the packet in it's buffers somewhere...
> 

The easiest thing is to not use an Ethernet SNIC. Instead use some
other serializer/deserializer for the IR link. Then you make a
serial driver with whatever error correction you want. You use PPP
with this serial driver.

FYI, you will probably find that fogged-in IR is not recoverable.
It has been my experience that you don't get "single-bit" errors,
instead, you get bursts of garbage as the PLL data-recovery circuit
goes out-of-lock.

When using a TAXI chip and Hewlett-Packard transceivers on a
fiber IR link, I don't use any error detection/correction at all.
TCP/IP has a checksum. The normal retry/retransmit mechanism works
fine.

Slowly pulling the fiber connector out of the socket, thus increasing
the attenuation (just like fog), produces no errors until a threshold
is reached. Then, all I get is errors --just junk, as the PLL loses
lock.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.