| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
Time once again for the post standards meeting update on the TP-PMD
committee. This is the group putting FDDI onto twisted pair cabling.
The committee is developing one standard for use with 150 ohm STP
cables and 100 ohm category 5 UTP cables.
The committee voted 40-1-13 (Yes-No-Abstain) to choose MLT-3 as the
encoding scheme for future work. This was the 3 level code originally
proposed by Crescendo, and endorsed by ATT, HP, and a few others. This
code is essentially a 3 level NRZI code, where a logical one is encoded
as a transition, and a logical zero is encoded as no transition. An
example waveform follows:
NRZ data | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 1 |
+---+ +-------+ +1 level
MLT-3 | | | |
+-------+ +---+ +---- mid level
| |
+---+ -1 level
Note that the encoding of ones follows a sequence from the mid level to
the +1 level, back to the mid level, then to the -1 level and back to
the mid level. This cuts the basic transmission frequency by a factor
of 4 to 125/4 = 31.25 MHz for a long string of NRZ data logical ones.
This helps to minimize the radiated emissions profile by placing most
of the signal energy in areas where it is not tested (radiated emissions
are tested above 30 MHz).
There is still MUCH work to be done to develop a standard. Choosing the
encoding scheme was the first of many steps, but it was important because
it gets the committee to focus on solving the remaining technical
problems. These include choosing a scrambling technique, developing the
complete channel model, specification of the equalization, and
specification of an installation environment to name four.
I will not attempt to predict when there will be a standard, but it
won't be much before 9 to 12 months from now if all goes well. One
thing to keep in mind is that the committee only chose the encoding
scheme, they did not choose anyone's product as a standard. If people
ask if Crescendo's product became the standard, the answer is no. There
is a long way to go before any standard compliant products will be
avaiilable.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 629.1 | MLT3 problems?? | NYOS01::HERENDEEN | Tom Herendeen @NYO, 352-2936 | Tue Dec 07 1993 11:02 | 16 |
hi all-
I am a consultant working on-site at JP Morgan in New York, and they
have been working on selecting vendors for EISA products. One of the
vendors was in the week of Thanksgiving and made the comment that
problems had been found with MLT3 and the standard would have to be
reworked. Since I wasn't at the meeting (I was dealing with a well
that had run dry), I can't relate the details of the problem. Anyway,
has anybody at Digital heard anything along these lines, and can they
give me a pointer to an individual who can address it.
Thanks
Tom Herendeen
NY PSC
outside: 212-235-9380
JPM E-mail: [email protected]
| |||||
| 629.2 | re: MLT3 problems? | ERLANG::HUTCHISON | Wed Dec 08 1993 19:22 | 34 | |
Tom -
Yes - we've heard quite a bit about this. Generally, this might be
called "base line wander" problem and it's currently a big
topic of discussion in the ANSI committee circles. The problem is
real but its not a fatal problem. In many respects, the problem is
hard to observe using the currently popular FDDI TP-PMD implementations.
There will probably be a change to the draft standard to control
the problem although consensus on a particular fix is still developing.
It seems certain a change to control the BLW problem will be included
in the TP-PMD document before it becomes a approved standard.
Right now, we're interoperable with the new designs they're considering.
Once the std is approved, DEC will adopt it and become conformant to
the std.
It's important to note that the changes being considered in committee to
control this problem result in a designs which are interoperable
with today's designs, which operate according to the current (draft)
TP-PMD document. So, this can be viewed as a performance enhancement
which will be phased in by early implementors (includes DEC and a bunch
of other companies).
Basic problem: some data patterns have been found which have a pretty
high likelyhood of being corrupted while transiting the ring, e.g.,
causing lost packets to occur. Fortunately, this affect is
somewhat unlikely unless one sets out to specifically cause it to happen.
In pratice, we've monitored small rings for weeks while sending
actual user data and not seen this affect even once. At the same
time, we can create it in the lab by setting up the right conditions...
It's felt, that in larger rings this affect can become noticable
although the analysis of when and how likely has never really been presented.
Jerry
| |||||