🚀 go-pugleaf

In article <40056@fibercom.COM>, mack@frugal.fibercom.com (Richard Mack) writes:
> In article <qt6j358@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> >
> >I've grumbled that this is not good for moving customer packets (e.g.
> >B might pass LCT but not be able to move data--I've seen real cases of
> >that), but people in X3T9.5 have told me that the more consistent ring
> >maps produced by the standard mandated behavior is more important.
> >
> >
> >Vernon Schryver,  vjs@sgi.com
> 
> This is a slightly disturbing comment.
> 
> Could you please post the situation where a port could pass LCT and not pass
> packets? The only thing I can envision would be if the PH_DATA.(request||data)
> lines in the concentrator are broken, but the station self-test should be
> able to find that.


First, please forget almost all you know about FDDI that you obtained
by reading the standards.  No hardware works that way.  Does anyone 
talk about ethernet using the Pascal in the 802.3 document?  Of course
not!  The standards are good for deciding if you've built the thing
right, to see if your system is the same from the outside as the silly,
abstract model in the standard.

I assume that people at Fibercom know about FDDI, but the the standards
talk is obfuscatory.  Why not use common words like "data path or bus
between the MAC and the PHY chips" instead of "PH_DATA.(request||data)
lines"?  The standards talk has obscured many other buses that the
informal phrase suggests, the buses among the MAC chip(s), local
memory, DMA controller(s), and main or host memory.

Some problems I've seen may be less likely on a concentrator, because
concentrators can be so simple.  I have seen stations that can pass LCT
(Link Confidence Test), but suffer excessively high error rates when
doing real work, from full fledged noise events or bad symbols to bad
CRCs.  LCT is commonly implemented by looping-back the data before it
gets to the MAC chip(s).  During LCT, the hardware is essentially idle
and quiet.  Compare that with real work, where you must pass the frames
through the MAC, to local buffer memory (if you have it), to main host
memory, and nearly at the same time do the same thing in reverse.  The
FDDI "node processor" (if you have one) may be fiddling with TCP/IP
headers.  You may also be computing various checksums.  DMA engines,
refresh controllers, and processors will be shouting at each other and
fighting for buses.

I know of no one who does the optional frame passing stuff later in
CMT, but even if they did, it would probably be trivial compared to
real work.

I have also seen many cases where the LCT is passed with much less then
perfection but also much better than the standard LEM (Link Error
Monitor) cutoffs, but data frames do not flow.  (Excessive CRC errors,
"lost" frames, etc.)  In these cases, reseating connectors has fixed
things.  (Yes, I'm convinced by synthetic errors LEM that is working to
specification.)  I don't know enough about the nature of FDDI media
errors to say much about this.

As always, it is between extremely difficult and impossible to write a
test that will decide if a board is good or bad, without simply copying
the real application.  A "diagnostic" intended to isolate a known
problem is hard enough.  I've been muttering for about 25 years that

    1. if the system fails the tests but runs the real application, the
	customer probably does not care about the tests.

    2. if the system passes the tests but does not run the application,
	the customer does not care about the tests.

    3. (2) is very common.

"Self-tests" and "confidence tests" are of very limited use.  The one
"test" that really matters is the application itself, whether that is a
stand alone Fortran program on a simple batch system of ages ago, or a
fancy multiprocessor network operating system with lots of simultaneous
programs today.

If you already know the system is broken because the application does
not work, the tests become useful as diagnostics.


Vernon Schryver,  vjs@sgi.com