Conference 7.286::fddi

If HP really works as you have been told, then it is designed wrong.

The standard says:

1. All stations must transmit a preamble of 16 or more symbols
2. All stations must receive frames that have at least 12 symbols of preamble
3. All stations must recognize tokens that have ast least 4 symbols of
   preamble
4. Any station may accept frames having shorter preamble than the minimum
   it is required to handle (but this is optional)

(I'm not positive about the limit of 4 in rule (3); it may be 2.  See the
standard.)

The reason for rule 2 is that the preamble can shrink as the packet passes
through other stations, due to the action of the elasticity buffer.  The
elasticity buffer and "smoother" design together are such that the preamble
will very rarely shrink below 14 symbols.  Thus rule (2) ensures that
conforming stations are very unlikely to lose packets when they were sent
correctly, Ebufs work correctly, and clock crystals are in spec.

The reason for rule (3) is that token loss is far more serious than
packet loss, therefore a lot more margin is designed in.  I'd argue
that the margin is overdesigned, but on the other hand the implementers
didn't seem to find it unacceptably hard to build, so...

So...

The conclusion depends on how the HP analyzer really works.  Again, if it
defines "short preamble" as anything shorter than 16, it is NFG.  The correct
definition for short preamble is anything shorter than 12.  Such packets
should still be received by a network analyzer (since its purpose is to
help analyze things that are NOT within spec, not just work when things
ARE in spec), but should be flagged.

If a ring with Cisco boxes causes short preamble (i.e., less than 12) then
there's something VERY seriously wrong with those devices.  It's not clear
to me how this could happen given that the FDDI chip implementers are
generally competent.  One possibility is the use of out-of-tolerance clock
crystals.  

	paul

    
    PAUL
    
    	Thanks for the response, I have at last managed to obtain a copy
    of the relivent pages in the specs and agrre with what you say in .1.
    
    	I have tried to bring this up with the customer again and the 
    urgency of the problem seems to have gone away. Since I last visited 
    them. "But they have had HP sales men in" and I think they have been
    doing some investigations regarding the AGS+counters and they seem to
    be playing down the problems. 
    
    	I wonder why???
    
    				Cheers 
    
    					Gary.

RE.0

What kind of FDDI interface is your customer using on HP4980? HP recentry 
relaesed new type of FDDI pizza card to support both MMF-PMD and  TP-PMD. 
If your customer use TP-PMD port on the pizza box then he may see short 
preamble frame due to implementation problem on the hardware. I had tested 
the proto type FDDI board for HP4980 as the field test. I have seen short 
preamble error only on TP-PMD but not on MMF-PMD. I'm still using the proto 
module because latest one I ordered is not available for me.

Hope this helps,
Naoki

I'd be very interested in more detail on that.  For one thing, it's a bit
surprising that an adapter could produce a valid preamble on one PMD and
an invalid one on another.  (The preamble generation is two layers
above the PMD...)

	paul

The errors I've seen are not only short preamble then. LCT failure has also
seen somtimes but it depended upon length of cat5 cable. HP told me that
the TP-PMD developed before final change on ANSI TP-PMD early in this year.

naoki 

    
    	I went to site on this one.
    
        All AGS cisco routers were incrementing input frameing
    	error counter.
    
    	We put a W&G FDDI analyser and the HP4980 in the ring between
    	a pair of the cisco router. The HP reported on some frames
    	that the previous frame was unreceivable due to short  preambles
    
    	The W&G reported no errors. Compareing the capture buffer on both,
    	the W&G had captured the same frames as the HP, it was just that
    	the HP was saying a frame between frame x and y could not be
    	received and the W&G just had frames x and y with no indication
    	there might have been something bad between x and y.
     
    	In fact, the W&G reported no errors at all.
    
    	Then a decbridge 620 was put on the ring upstream of the analysers.
    	Not only did the HP stop reporting unreceivable frames, the
    	downstream cisco stopped counting input frameing errors.
    
    	Conclusion: All the Cisco's are generating frames with too short a
    	preamble. The DECbridge is either removeing these frames from the 
    	ring or regenerating the preamble to a resonable length.
    
    	The HP reaches parts that the W&G cannot see!
    
    	
    Colin	 

Hm...  it sure would be nice to capture a preamble that shows unambiguously
what's going on here.  Unfortunately, that would probably require a logic
analyzer.  For cases like this, it's always risky to trust the test equipment.

The only explanation I can think of, if the short preambles are real, is a
rather large clock frequency error in one or more stations.  The trouble is
that it a significant error to cause the problem if the error is in only
one station.  Then again, we know from Ethernet experience that careless
engineers or manufacturers have been known to do this...

One argument in favor of this being real: it explains why our box makes the
problem go away.  Digital's FDDI chips have a significantly larger Elasticity
buffer than the standard requires, which means that they can tolerate -- and
correct -- preambles that are a LOT shorter than what the standard requires you
to be able to handle.

	paul

    
    	Paul, thanks for that. As far as we (digital) are concerned,
    	and the customer, the problem is back in Cisco's court :-)
    
    	Colin

Good.  There's where problems involving Cisco boxes generally belong!

	paul