Conference 7.286::fddi

Sounds like bullshit to me.

Ed used to work here; I wonder what made him say this sort of thing.
Incidentally, there is no such thing as "JK line state".

Suggested answer:

	"There is no such thing as 'JK line state'.  The description
	doesn't say much, but it doesn't sound like any known bug.
	We believe that our products conform to the standard.
	Please provide more detail."

/paul

    All of DEC's FDDI products use Rev B of the FDDI ELM chip.  This is the
    only version that is qualified at DEC to be used in products.  Any
    other revision of chips are to be considered experimental prototypes
    until full qualification has been performed.  
    
    Products have been shipping for 2.5 years with REV B FDDI ELM chips.  
    They have been thoroughly tested and there is no reason the loss of 
    packets can be contributed to the DEC wiring concentrator.
    
    Bruce.

    	Did they run their tests with Ring Purger enable or disable ?
    I've already seen FDDI analyzer which can't follow the rate of
    void frames sent by the Ring Purger.
    
    	I know VOID frames are standardized frames but some hardware
    doesn't filter them at their level, so promiscuous mode is killing
    them.
    
    	Patrick
    

Certainly there are nodes that don't conform to the standard and don't handle
Void frames right -- thus run into trouble when the purger is working.

But that's not a bug in our products, and it does NOT cause ring 
reconfigurations.

	paul

    Hello Dave,
    
    Do you know where these tests were conducted? Also, who is failing? 
    The usual problem is that someone is swallowing void frames from our 
    purger, and having a problem. They should be ignoring the voids anyway, 
    so the problem needs to be explained with that error in mind. At this 
    point, most people are past that problem, so this might be someone new. 
    
    Was Interphase part of the tests? 
    
    Thanks,
    
    Bill

    Here are some more details from the customer. The test were at AMDs
    ANTC test site in sunnyvale. Thanks for the answer about the rev of the
    chipsets we are shipping.
    
Below are more details on the chipset problem, draw your own conclusions.
The info has come from Interphase in Dallas and their own action on this is
to stop shipping Rev C chips, which is serious enough.

What I am interested to know is the Rev level we have here. By inspection
we have not managed to identify much, the relevant chips just say 'made
in Japan' and have some numbers we cannot relate to any data books. I can
provide you with whatever you ask (serial numbers, etc.) to find out.


------ included message start

We did discover a problem with the Rev C ELM of the FDDI chip set. The Rev
B ELM does not have this problem so it is important to know which ELM you
have. I know that DEC fabricates their own chips and they also buy some of
their FDDI chips from Motorola. I would have no idea which chips are in
your concentrator so it would probably be best if you checked with your
local Digital rep to see which rev of ELM that you have.

If it is a Rev C ELM, then there is a problem. Motorola has acknowledged
the problem with the following errata report.

   LONE JK

   When the ELM's elasticity buffer is stretched it is possible for the ELM
   to misalign on an incoming JK pair, thus producing a shadow JK followed
   by the JK of the actual frame or token. The lone JK is usually removed
   by subsequent station's repeat filters and aligners; however, this
   errata violates the standard for minimum Idle pattern and a downstream
   station may not be able to affect alignment.

Put another way, instead of repeating a received frame exactly as it comes
in, the ELM will append a lone JK symbol pair followed by 8 or less idle
symbols to the start of the received frame. In other words, if you look at
the symbol stream, you will see JK, followed by 8 or less idle symbols,
followed by the frame. The 8 or less idle symbols violates the spec on the
minimum number of idle symbols. If this invalid symbol stream goes to a
Supernet I chip set, it may have a problem aligning on the valid frame
because of the small number of idle symbols. Subsequently, the Supernet I
chip set will not see the JK of the valid frame and will throw the valid
frame away. If it happened to be a token, the ring will go through a claim
process.

We mostly dealt with Motorola on this issue. However, it is my
understanding that DEC acknowledges this problem also.

------ included message end

    

    As stated in my earlier reply.  There are no REV C ELM chips in any DEC
    products.  It has not been qualified to be used in any DEC products.  I
    don't know how to make this any clearer.  We need to stop discussing
    this regarding our products because it keeps perpetuating the notion
    that we have problems with our chip set and products.  We don't!
    
    Bruce.

    Hi,
    
    A customer of mine is having problems with 3Com netbuilder routers
    running on DECconcentrator 500's. The only question he has is "Does the
    concentrator use Revision A of the AT&T chipset ?". 
    
    Is the same chipset that is being referred to as the ELM chipset ?
    
    Alan.

AT&T chipset?  I don't believe it uses an AT&T chipset at all.  What chip
specifically is this person referring to?

	paul