Re: CRC Errors on GigE.

nkarkhan <nkarkhan@xxxxxxxxx> wrote:
What equipment do i need and what testing do i need to do, to ensure
that my signal quality is pristine enough for the nic not to give me
errors.

I think that most of us are trying to say that despite your good
fortune thusfar, there is no "Ethernet" equipment out there you can
safely ass-u-me will not give you errors at all. Particularly if this
stuff is to go into what may not be all that pleasant an environment.

Should i look at S/N ratio in my setup? And if the S/N ratio is a
lot better than whats specified at the end of the link, i could
calculate the probablity and see if I can live with it? (Seems like
a resonable idea, let me run it by the EEs we have here)

The EE's signed-off on this? Almost sounds like something where you
could tell us what the kit will "really" be doing but then would have
to shoot us.

My current cisco is good enough, but how do i know that my next
batch of cisco switches i buy wont start giving me the same error?

You can't. You can only assume that they will be no worse than the
rated BER for Ethernet, and that if they _are_ they are defective.
Ethernet equiepment was neither spec'ed nor I suspect implemented for
what appear to be the rather tight tolerances your application appears
to have.

Ethernet is "best effort" it makes few if any guarantees and it looks
you need/want gurantees "Ethernet" specifications cannot give you.

If I were looking to maximize the reliability of my Ethernet network,
I'd probably want switches with ECC memory in them lest a single bit
error while frames were being forwarded either trigger a parity event
causing the switch to drop the frame, or something detected by the
final destination. I'd probably want the same thing in all the "data
paths" through the switch (busses etc). I'd probably want similar
things in my NICs if that were possible. Of course, being "best
effort" means that implementors of Ethernet kit can simply say "well,
all we need is parity to just detect it and drop the frame" or "we can
rely on the CRC to protect data integrity and have the frame dropped.
Again, because "Ethernet" is not specced for what you seem to want to
do.

If I could, I probably wouldn't _really_ run Ethernet at all but
perhaps something that at the data-link level looked remarkably _like_
Ethernet - with its header and all, but at the physical layer had
some, perhaps gastly, quantity of FEC - Forward Error Correction -
such that even if there were a single-bit error in a frame on the wire
or fibre the FEC could correct it. Something that went well above and
beyond anything in the current physical encodings. The idea is to
take a physical BER and have a much, Much, MUCH better "effective" BER
at the frame level. I would guess that the basic principles wouldn't
be all _that_ far off from what folks do when talking to
interplanetary space probes...

Barring the existence of that sort of thing, I might be convinced to
try to simulate that by telling my NIC to give me everything it sees,
regardless of the Ethernet CRC and us my own FEC in the frame. I
would still be at the mercy of a switch possibly detecting a parity or
ECC issue in its own memory or data paths and toasting some of my
frames though...

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.