T.R | Title | User | Personal Name | Date | Lines |
---|
303.1 | It can vary | JUMP4::JOY | Get a life! | Fri Jul 19 1991 11:22 | 10 |
| From a conversation I had with Paul Konig, this time can vary,
depending on vendor implementations, ie roving MAC, etc. If "roving"
MACs are used the reconfig time might vary from 2 to 16 microseconds.
Using the standard insertion/removal method that we and many other
vendors use, I believe its pretty consistent around 8 microseconds.
Paul, please correct me if I got this wrong.
Debbie
|
303.2 | | KONING::KONING | Eesti vabaks! | Mon Jul 22 1991 11:57 | 8 |
| Not quite... that should read milliseconds, not microseconds!
Also, for the roving MAC case we're really guessing, since there IS no
standard for what those do (see discussions earlier in this file). One
plausible set of guesses gives reconfiguration times as long as
165 milliseconds. Compare that with what the standard gives you...
paul
|
303.3 | what is a plausible value ? | BRSSWS::VANDENBERGHE | | Fri Aug 09 1991 10:35 | 16 |
| Hi,
Some questions about the figures:
A reconfiguration will depends of different problems and parameters.
Error detection, wrapping, scrub and claim processes will take some
time.
Does this plausible reconfiguration time of 165 milliseconds embrace
all the processes or is it a part of it.
Regards,
Robert
|
303.4 | | KONING::KONING | Eesti vabaks! | Fri Aug 09 1991 13:19 | 12 |
| Those numbers are for the whole process except for error detection. In other
words, I start counting at the moment that the node decides there is an error,
or other reason for reconfiguring. The delay from the beginning of a problem
to the detection of that problem varies a lot. It depends on the type of
error and its severity. (For example, cut cable -- "no light" -- is detected
in much less than a millisecond. Excessive error rates -- LEM reject -- are
detected very rapidly if the error rate is way over the limit, but it can
take multiple seconds if the error rate is only slightly over the limit.
Of course in the latter case the detection delay is not a major problem, since
the network doesn't suffer a whole lot in the meantime.)
paul
|