Conference 7.286::fddi

    Hi Mark,
    
    .....while I don't have the ANSI specs with me at the moment....the
    time it takes an FDDI ring to recover from an insertion/deletion from
    the ring is definitely small fractions of a second.  The size of the
    ring (stations + cable) has some effect on it.
    
    Spanning tree wants to take around 45 seconds before it will start the
    forwarding process after any change in the bridged network.......it can
    take a lot longer if the spanning tree topology is especially complex
    and/or large.
    
    I always find it amusing to see what kind of FUD is generated by those
    vendors who cannot quite get FDDI to work.  This of course means that
    no one else can either!
    
    -Jeff

Re .2: Did you mean that to be a new note?

Re .0, .1: I concur with the view that this is typical FUD from a company that
has no FDDI competence.  Actually, the statement itself condemns them as
utterly ignorant.

The FDDI recovery time for loss of token is well below 10 MILLISECONDS.  
In fact, the entire station insertion process, which includes "scrubbing"
as well as reinitialization, takes less than 10 milliseconds.

There exists NO FDDI process that requires two minutes.  None.  Never was.
Anyone with even elementary competence in FDDI knows that.  (Please feel free
to quote me on that.)

You might point the customer to the new "FDDI Handbook" by Raj Jain (Addison-
Wesley).  For that matter, get one for yourself!

As for spanning tree transition, that doesn't take two minutes either.  The
numbers in .1 sound right AS THE DEFAULT.  You can lower them substantially
if you have a need to do so.  Note that this only affects how long it takes
for a backup connection to take over, or for the first connection to come
up after powerup.  Such events as FDDI token loss are completely invisible
to the bridge spanning tree process.

Bottom line: I believe Kalpana is scared by the 900 MX; its combination of
price, performance, and compact hub-mount package is hard to beat...

	paul

    Thank you very much for confirming my suspicions.  I believe we have an
    opportunity here to put more pressure on manufacturing to deliver th
    DB900 MX in quantity sooner!
    
    I am not complaining here on the lead times for the DEChub 900 modules. 
    Believe me, this is a much better problem than we've had the past few
    years when we were behind the technology curve.
    
    Regards,
    
    Mark
    

    paul,
    
    yup, it was suppose to be a new note. I'll move it.
    
    Brad
    

Re .4: I think manufacturing got the message quite a while ago.  Personally,
I much prefer this problem over the opposite one....

	paul

    Paul,
    
    ....I assume (!) that the time for an FDDI ring to go through a scrub
    and re-init is dependent upon the number of stations and the total
    length of cable in the ring......
    
    Is there a way to calculate this time based on specific ring
    configurations?
    
    -tnx,
    	Jeff

It depends on both; more precisely, it depends on the ring latency, i.e., the
total time it takes to travel the circumference of the ring.  That time is
limited to 1.6 milliseconds (roughly; the standard calls it D_Max).  Apart
from that, the station count is not an issue in practice.  (It does add some
in theory; you can create a ring topology where initialization takes a bit
longer, if you arrange the station addresses, T_Req values, and timer 
expirations exactly right.)

Basically, claim takes one trip around the ring to resolve, and then the token
has to go around twice before the ring is fully operational.  So the limit
is 3*D_Max, and the actual is 3*D_actual.

That's just for reinit, it excludes scrub.  Scrub is done for a fixed time,
chosen to be well in excess of the normal values for TVX.

	paul

    
    ...makes sense.  So if we assume the default values from the
    ANSI specs, we are taling about:
    
    total time = scrub_time + re-init_time
    	       = T_Scrub + 3*D_Max
    	       = 3.5ms + 3*1.773ms
    	       = 8.819ms
    
    			(my copy of the specs show D_Max = 1.773ms?)
    
    So this would be the time that would be "lost" from an application's
    point of view when using FDDI....?
    
    -tnx!
    
    	Jeff

The specific value of D_Max isn't consistent in the specs, due to the
fact that they were approved at different times.  But that number is close
enough...

Yes, this interruption is how much additional wait time the application
will see.  Probably it won't notice...  

	paul

    
    ....great!  Thanks for the sanity check.
    
    -Jeff

    I picked up Raj Jain's book and have checked out the section on
    calculating ring initialization time......everything makes sense
    except that I do not see where "scrub time" is accounted for.
    
    This is what I got from the book:
    
    Ring init time = time to react to the change + time to recover
    		   = T_React + T_Resp
    
    T_React = MI_Max + D_Max + TVX_value + A_Max
    
    			MI_Max = media interruption time
    			D_Max  = max ring latency
    			TVX_value = time for transmission timer to expire
    			A_Max  = signal acquisition time
    
    T_Resp = (3*D_Max) + (2*M_Max*Claim_Fr) + (S_Min)
    
    			M_Max  = maximum number of MACs
    			Claim_Fr = time to transmit the Claim frame
    			S_Min  = minimum safety timing allowance
    
    
    ...so where is the scrub time accounted for?
    
    
    -tnx!
    
    	Jeff

Scrub time isn't shown there; Raj is describing the time it takes to notice
and recover from such things as a lost token.

Scrub interrupts the flow of data around the ring, so the detection time
starts at the time scrub starts.  But the reinit doesn't make progress
until scrub ends.  So the formual would work out to:

	max(T_Scrub, T_React) + T_Resp

which, given the standard values for T_Scrub, amounts to T_Scrub+T_React.

	paul

    
    ...hmmm, T_Scrub defaults to 3.5ms and T_React defaults to something
    like 23.2 ms........?
    
    So the default ends up being T_React?
    
    (I'm a little confused!)
    
    Also, is the time to reconfigure/recover as in above in the case where
    a station is inserted into the ring?  ..or is this an instance where
    the time to react is essentially non-existent?
    
    -tnx
    	Jeff

Oops.  Where is this description?

I  think MI_Max may be where the scrub time goes, since scrub is a media
interruption.

	paul

    
    ...it's in the section that (also) deals with FDDI-II.  I can get you
    the specific page number (the book is at home right now).
    
    -tnx,
    	Jeff

I found it.

MI_Max relates to optical bypass relays.  The reinit time in the scrub case
is obtained by replacing MI_Max by T_Scrub.

Raj describes what's in the MAC-2 spec, but I think that the spec is not
quite correct.  The recovery cannot make progress until the interruption is
over, but some of the other contributions (e.g., TVX) overlap that time.
So I think that

	max(MI_Max, D_Max+TVX_Value+A_Max)

is probably more accurate, though it may not be quite right either.  I don't
really want to spend the time analyzing all the pieces.  Certainly if you
use the formula Raj gave you will end up with a valid upper bound; but it
probably isn't a TIGHT upper bound.

	paul

    
    ...that seems to make much more sense.  I'll use that "approach" when
    working numbers like these for the customer.
    
    tnx, Paul!!
    
    -Jeff