lkml.org 
[lkml]   [2001]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Ethernet Error Correction
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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:03    [W:0.081 / U:8.700 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site