> I am back with a bit more information. The counters which were not
> checked in this version can be grouped in two categories:
>
> - Error counters such as:
>
> u64 FrameCheckSequenceErrors;
> u64 AlignmentErrors;
> u64 FramesLostDueToIntMACXmitError;
> u64 CarrierSenseErrors;
> u64 FramesLostDueToIntMACRcvError;
> u64 InRangeLengthErrors;
> u64 OutOfRangeLengthField;
> u64 FrameTooLongErrors;
> u64 FramesAbortedDueToXSColls;
>
> I did extend the selftest with these ones so that we check them
> against zero. I ran the test hundreds of times and I did not see any
> problems.
Great.
>
> - Collision related counters (not really errors):
>
> u64 SingleCollisionFrames;
> u64 MultipleCollisionFrames;
> u64 FramesWithDeferredXmissions;
> u64 LateCollisions;
> u64 FramesWithExcessiveDeferral;
>
> With these I don't know what to do. Theoretically, they could be
> non-zero in half-duplex circumstances which means that checking for
> zero would not be entirely accurate.
How about, fail the test if any are greater than 1% of the number of
packets transmitted/received? My _guess_ is, if you have 1% packet
loss, networking is not going to be happy anyway. It probably means
you have one end doing Half duplex and the other Full. That is a
typical configuration error you see causing collisions. Not that i've
actually seen this for maybe a decade!
Failing the test, with a comment about checking duplex configuration,
seems sensible.
Andrew
