Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!gatech!howland.reston.ans.net!spool.mu.edu!uwm.edu!lll-winken.llnl.gov!uop!pacbell.com!amdahl.com!news.fujitsu.com!nntp-sc.barrnet.net!sony!col.hp.com!news.dtc.hp.com!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: 100Base-T Packet Losses Date: 15 Mar 1995 19:28:59 GMT Organization: HP Roseville Networks Division Lines: 632 Message-ID: <3k7f5r$t6m@hpchase.rose.hp.com> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] Hi. In the last IEEE 802.3 meeting in West Palm Beach, Florida; I presented some information regarding the MLT-3 signalling that is used by 100Base-T and its inherent flaw known as "Baseline Wander". Baseline Wander causes the MLT-3 reciever to drop packets, and on occasion generate false collisions, late collisions, etc. A number of people at the conference requested a copy of the PERFORM_3 files that were used to evaluate this problem since the vast majority of products currently being shipped as "100Base-T" contain this flaw. It seems that the easiest way to distribute this information is via the net as this will assist a broader audience. So, attached is a copy of a file that was sent to me by a software buddy of mine. If so inclined, you can use this file to determine the performance of your 100Base-T adapters and hubs. Dan ************************************************************************** Dan: Here are the shar uuencoded archive of the files we used: nasty.dat - is the full 1023 byte pattern nasty040.dat - is the first 40 bytes of the pattern replicated 512 times to make a 20480 byte file for use with PERFORM3 To use nasty040.dat with PERFORM3: 1) Run PERFORM3 on the master client with the following options: PERFORM3 file 30 20480 20480 2) Copy NASTY040.dat over PERFORM3.DAT in the same subdirectory as the master client: COPY nasty040.dat perform3.dat 3) Start any remaining PERFORM3 clients. 4) Press any key on the master client to start test. 5) Evaluate 100Base-TX performance. This method can be used to make PERFORM3 use any data pattern desired. Brian #---------------------------------- cut here ---------------------------------- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped on Tue Mar 14 13:50:12 1995 # # This archive contains: # nasty.dat nasty040.dat # # Error checking via wc(1) will be performed. # Error checking via sum(1) will be performed. LANG=""; export LANG PATH=/bin:/usr/bin:$PATH; export PATH if sum -r /dev/null 2>&1 then sumopt='-r' else sumopt='' fi rm -f /tmp/uud$$ (echo "begin 666 /tmp/uud$$\n#;VL*n#6%@x\n \nend" | uudecode) >/dev/null 2>&1 if [ X"`cat /tmp/uud$$ 2>&1`" = Xok ] then unpacker=uudecode else echo Compiling unpacker for non-ascii files pwd=`pwd`; cd /tmp cat >unpack$$.c <<'EOF' #include #define C (*p++ - ' ' & 077) main() { int n; char buf[128], *p, a,b; scanf("begin %o ", &n); gets(buf); if (freopen(buf, "w", stdout) == NULL) { perror(buf); exit(1); } while (gets(p=buf) && (n=C)) { while (n>0) { a = C; if (n-- > 0) putchar(a << 2 | (b=C) >> 4); if (n-- > 0) putchar(b << 4 | (a=C) >> 2); if (n-- > 0) putchar(a << 6 | C); } } exit(0); } EOF cc -o unpack$$ unpack$$.c rm unpack$$.c cd $pwd unpacker=/tmp/unpack$$ fi rm -f /tmp/uud$$ echo x - nasty.dat '[non-ascii]' $unpacker <<'@eof' begin 644 nasty.dat M(1N',70AC_$F%%/$Z^$;\S"VY+91NO X3AH7TU66JZ*V_%YZ-SM:]A7Y2AL3X MXKKB@/3A(V&8;M'6U-# K4VM9-9?ZR.&_R72BBR37GH'9-757H/@%0GV'24,X M;Y)IPBBT$JJU^B2:8I6UZW._LX%Z$7X5( A2B(XJ"E"?"HKUYZ=BWM7-%+ MX MA.L*@_8FVU6,]_(YH$BS,5EK61Y*IU':T< 1!8WLNQ_"I7@_4V3"%F%"2RH3X MLBK$(@G:RCKJIEQA0&FVX M_#LF)5*Z[*I#(@'90#;!L/@H%R'2!HHBN_?EO2R'$D@UP1RD=2+EYJ9Q%>9%X MJ7 6>KM"Z+(VJW*X_CL"68(V)@H*@%@/[R*&/"5W00 (@O;A?Z(X)P9MG>2BX M4^Q!JBI@&JRN6R-%BH I8!4Y)1"Y(($UY^01"I%V!6C#%J%C4)!@3" 2=N/IX MS^*Y-E11N*(DF[?Q_"J%.D.2:E:-]#80AD3S3358 _&J6GL9I7:]5"--B>JAX MQHUE24>1)T3B'%$06;N>^CIJ^Z.@M2C^&FM4E[&, 1LSL3N.(&P>NEI;E:NTX M[JRX(L8?H0]3,B6H3@9"E>AUU"&X'"YD/E0J5LSD4#I&IM/@BR^KTX:X MNR+YMSHA,U^1''&J.R$=S?4A4Y6K:\X[@@2&D9K[0AB_-##'&K(9UT8C'\*(X M+U\"017G,0O2R: Y9G0SM3CBI:BU4 F5Q_$AWT,I)4+H8\(4;TL5BO7G!94(X MCEMC6H*)9TH :8?Z,SK=5)8)X%G'0SYKDP#M+9QKV$(0H*HDLA$0F9M#0OXIX MB>]3\C -Q!4&Z3L2F/,Z# 24(6N?=2QF'+HW)T4G4IYBR!5R%9NCX M>##HI<7IP%EW2EP1%G5Y5Z-]%:8+D121F/\EV\\4IW7$ H#U2!^A;,I".M3BX MIK\Q0.DKA95)1X%X%&E8@/'DL."NL43AR?1HP#CNDB:0X MH+'U\^BGJQ\"GW6P>".!ZZ%TZIV=56E7$FC93Q$44;CR+YIQXN4 EG8*2X/JLN#-[51C5(#M'(%FS7PQX M,L#JA7D742H 1#3/>BN(XG 4IJFV7$%:6V^O>S7@J6;-%+ X X end @eof set `sum $sumopt >C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX M>C<[6O8A&X>C<[6O8A&X>C<[6O8A&XX %>C<[6O9Z X X end @eof set `sum $sumopt Date: 24 Mar 95 03:10:55 GMT References: <3kdb8d$np1@transfer.stratus.com> <3kkdn6$bbi@hpchase.rose.hp.com> Sender: news@bridge2.NSD.3Com.COM Organization: 3Com Corporation Lines: 20 Nntp-Posting-Host: saskatoon.nsd.3com.com In article <3kkdn6$bbi@hpchase.rose.hp.com> djdove@hprnd.rose.hp.com (Dan Dove) writes: >The reason I put (disadvantage) is that it contains a huge amount of >DC component which results in serious signal degradation when used in >transformer based systems like those used in UTP applications. Most of >the devices which use MLT-3 today do not operate properly due to this >low-frequency component (Baseline Wander) and will drop packets. See my >earlier post in .ethernet regarding "100Base-TX dropped packets" for more >details. This is classic VG FUD. I've been running over-the-weekend tests for months now connecting a 3Com 100Base-TX NIC in a PC to a Grand Junction FastSwitch to a 3Com 100Base-TX router module (and back), running at over 98 MBits/sec, with no dropped packets. Billions of packets. Trillions of bits. Which devices are "most devices"?? -- Chris Thomson cmt@3com.com Tel 408-764-5248 Fax 408-764-5002 3Com Corporation, 5400 Bayfront Plaza, Santa Clara, CA, USA 95052-8145 Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!gatech!udel!news.mathworks.com!news.kei.com!simtel!col.hp.com!news.dtc.hp.com!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Date: 24 Mar 1995 00:15:59 GMT Organization: HP Roseville Networks Division Lines: 88 Distribution: world Message-ID: <3kt2vv$ljj@hpchase.rose.hp.com> References: <3ko29t$48i@jupiter.WichitaKS.HMPD.COM> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] Chris Kurker (chrisk@FtCollins.NCR.COM) wrote: : djdove@hprnd.rose.hp.com (Dan Dove) writes: : |> Marc Sanfacon (sanfacon@blackpit.hw.stratus.com) wrote: : |> : |> : What is MLT-3? What does it stand for? What is it's purpose? : |> : How does it work? and What uses it now? : |> : |> Marginal Link Technology ??? :) : I wonder how many readers of this newsgroup realize the motivation of : the author of this and many other posts bashing both the 100BaseTX : and 100BaseT4 : standards ? It is quite an interesting story with a long history. I wonder if you have a clue. I think you are suggesting that there is more than a purely technical motivation. If so, you are wrong. I have in the past, (and will be happy to in the future) provided technical basis for my dissatisfaction with MLT-3. I worked in ANSI when MLT-3 was being evaluated. I saw people present bogus data. I tested MLT-3 and found numerous weaknesses with it. ANSI chose to proceed with MLT-3 for what I believe was pure marketing reasons... they didn't want to take the time to do it right. : An exhaustive analysis of the Baseline Wander issue in the CDDI and 100BaseTX : scheme was done by Motorola and presented to the ANSI committee in August 1993. The analysis : determined the worst case legal FDDI and Ethernet packets that would build up : the maximum possible baseline wander and sustain it for the longest period. : It was shown that the occurrence of this packet is quite rare, as a number of : circumstances have to coincide. What was not shown was that when you include tolerances for all of the various receive circuits, (and noise) there are a whole lot more possible patterns that will cause the reciever to fail. : |> There are much better codes than MLT-3. HP Labs presented one at the 802.12 : |> meeting in West Palm Beach that provides a DC null while maintaining the : |> low frequency bias of the spectral distribution. It is called RMI-3. : In fact, a similar proposal was made some time ago in the ANSI committee, : and there they called it MLT-3A, but the committee, in its wisdom, : decided to leave the problem of dealing with the baseline wander to the : receiver designers. Transmitting balanced data is much wiser because it reduces the number of circuits that have to be toleranced (and conribute to errors). : It turns out that this is not that difficult a problem, and for example : National : Semiconductor will be including this modification to the new revision of their : popular Twister transceiver. I think this is inaccurate. In fact, IC vendors have worked a long time and done at least a few rolls of their silicon without success. Sure it can be done, but it will be a marginal circuit when complete. Ask National for their REV C part. (The one with the BW circuit fix) Better yet, get a part that is claimed to work and inject noise into the receiver. Report back to us at what level it falls apart. : They presented a straightforward way of cancelling : baseline wander at the latest IEEE 802.3 meeting in March, which : presumably is what they implemented in silicon. Were you listening to the presentation? a) BER of 10e-12 was quoted on the reciever. When asked what the noise environment was during the test, it was stated that no noise was injected. How do you get Bit Errors without noise????? b) When I asked about the relative bandwidth of the BW feedback circuit to the equalizer (they can interact creating instabilities) I was told that the equalizer can be locked. This would result in a very weak system since UTP attenuation varies with temperature quite a bit. Later the designer tried to back out of the statement, but never did answer the question. It turns out that the bandwidth of these two loops are very close to each other and interaction is a problem that is not easily resolved. In summation, I don't think it is quite fair for you to imply that I have some alterior motivation for slamming MLT-3. In many posts I have presented valid technical arguments for my position. If you think MLT-3 is so great, why don't you post a noise-budget-analysis for it? I did so a while back and it isn't pretty. Maybe you can do a better job? Dan (waiting for noise-budget-analysis and some measurements) Dove Path: nntp-server.caltech.edu!netline-fddi.jpl.nasa.gov!news.byu.edu!news.mtholyoke.edu!uhog.mit.edu!news.mathworks.com!udel!news.sprintlink.net!cs.utexas.edu!swrinde!sdd.hp.com!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Date: 25 Mar 1995 04:12:51 GMT Organization: HP Roseville Networks Division Lines: 70 Message-ID: <3l0583$2i9@hpchase.rose.hp.com> References: <3550@bridge2.NSD.3Com.COM> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] Chris Thomson (cmt@ESD.3Com.COM) wrote: : This is classic VG FUD. : I've been running over-the-weekend tests for months now connecting a : 3Com 100Base-TX NIC in a PC to a Grand Junction FastSwitch to a 3Com : 100Base-TX router module (and back), running at over 98 MBits/sec, with : no dropped packets. Billions of packets. Trillions of bits. : Which devices are "most devices"?? Hi Chris, I have been doing some testing as well. My area of attention is in the Electromagnetic Compatibility side of things. This is an area that looks at how robust the system is with regard to external noise. At the last IEEE 802.3 meeting, I presented some preliminary information that I had discovered during some testing for a 2-UTP physical layer for 802.12. The testing is a normal part of physical layer design. First you determine the noise environment your system will be required to operate in, then you design a system which will operate reliably in that environment. In this testing, I discovered that the mapping of pins in the connector has a significant effect on noise immunity. The early data indicated that 100Base-TX would not meet 1996 European regulatory requirements for noise immunity because we had changed the ANSI CDDI pin mapping from a very quiet pair of wires to a very noisy pair. (12,78 ---> 12,36) The 36 pair is used by 10Base-T, but 10Base-T does not have an immunity problem because its frequency spectrum is less than 20Mhz. The noise problems occur around 60 - 80 Mhz where there are many sources like FM transmitters, Motors, etc. The noise on the 12,78 pairs that I have measured is less than 40mV, while the noise on the 36 pair is as great as 180mV. More than 4 times larger! From a theoretical perspective, 100Base-TX will not operate in this noise environment. To confirm my analysis, I attached some 100Base-TX devices to a cable that had it's wall-jack inserted in a 3 volt/meter field. Every 100Base-TX device I tested failed to operate with that noise environment. I have not mentioned vendor names in order to be reasonable. I hope you can appreciate that. I must add that 10Base-T and 100VG devices were tested in similar tests (only CAT-3 components were used) and they operated at field strengths 5 times greater. Actually, in the case of 10T and VG, I placed the products in the field as well. To ensure that there were no measurement errors, I have repeated my tests, and performed a broader set of measurements which provide substantiation of my tests, and some clues as to what mechanisms are allowing the noise into the system. I also informed EMC designers from Bay, 3-Com, and their associates of my procedures so that they are very likely to be confirming these results on their own. There are ways to fix 100Base-T. One could re-map the pins to 12,78 or they could eliminate wall jacks from the allowed wiring practices. Either way, it seems that some serious engineering is going to be required. A thorough noise-budget analysis combined with more noise environment testing is the minimum one would expect. Dan Path: nntp-server.caltech.edu!news.claremont.edu!bridge2!cmt From: cmt@ESD.3Com.COM (Chris Thomson) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Message-ID: <3560@bridge2.NSD.3Com.COM> Date: 1 Apr 95 02:54:11 GMT Sender: news@bridge2.NSD.3Com.COM Organization: 3Com Corporation Lines: 77 Nntp-Posting-Host: saskatoon.nsd.3com.com Dan Dove writes: >Attached is an MLT-3 noise budget that I posted a few months ago. > >The number at the bottom (for MLT-3 it's 49mV) is the amount of signal >available to overcome externally coupled noise. My recent measurements >show that in a 3V/m field, the noise coupled into the wiring components >may be as high as 150mV. 3 times greater than the signal. This is bad. > >Coding Scheme MLT-3/CAT-V QUARTET/CAT-V QUARTET/CAT-III >-------------- ----------- ------------- -------------- >Channel bandwidth 125Mhz 25Mhz 25Mhz >Min Txmit level .95V 2.2V 2.2V >Str Ret Loss 1.2dB 1.0dB 1.5dB >Cable attenuation @ Nyquist 17.0dB 8.0dB 12.0dB >X-connect loss .5dB .5dB .5dB >Crosstalk interference 4.5dB .5dB 4.5dB* >Equalization tolerance .5dB .5dB .5dB >DC imbalance .75dB .1dB .1dB >Threshold tolerance .75dB .1dB .1dB >PLL tolerance .5dB .5dB .75dB >---------------------------- ----------- ------------- --------------- >Resultant eye opening 49mV 657mV 380mV > (bundles) 226mV* > >Since MLT-3 uses five times the channel bandwidth, this means that noise >coupled from external sources (which increases with frequency) will be >much greater. > >Measurements presented to ANSI show that external fields of 3V/m can >induce up to 180mV of noise onto a CAT-V cable system which has CAT-III >cross connects. Clearly those systems will not work. While I have seen >no test reports of pure CAT-V cable plants to indicate a reasonable >margin might exist, it is clear that a customer wiring plant >*will not work* if it is not installed with absolute precision. Dan, Dan, Dan. So much FUD. I was sufficiently annoyed by the above to pass it along to the guy who designed our 100Base-TX and FX router cards. Here's his reply: Issue 1- Nyquist frequency is improperly applied. MLT-3 is a 3 level signalling scheme, not binary, and consequently the Nyquist frequency is (125mhz data rate) / (2 * log base 2 (3)) = 39.4mhz, not 62.5mhz as the author assumed. This reduces cable attenuation to 13db rather than 17db. Issue 2- Crosstalk attenuation is also wrong in his analysis due to the same issue Nyquist issue, but I don't know the correct number since I don't have tables handy for this parameter. probably about 1.5 db. Issue 3- 3v/m is a *HUGE* field. Some relative comparisons: FCC A limits: 35 microvolts/meter Relative sensitivity of a TV: 1milivolt/m Fields drop off linearly with distance, so at 3km your 3v/m source will be 1milivolt/m and will still interfere with other people's telelvisions and they will probably call the cops on you and you will go to jail. Many television stations operate in frequency ranges near to critical 100Base-TX frequencies. Incidentally, the FCC does NOT regulate emissions below 30mhz so you have no similar guarantees about 12.5mhz noise that would blow away a 100Base-VG network. The 100Base-TX network would be unaffected by noise at this frequency as it would not pass the receive filters. 4. Analysis does not factor in the fact that noise is attenuated along with the signal. So unless that noise source is right next to the receiving station, the analysis is invalid. If you generate the noise at the middle of the network, and apply the *correct* cable attenuation and crosstalk interference numbers, 100Base-TX is about the same as Cat-3 100Base-VG, though admittedly worse than CAT-5 VG. -- Chris Thomson cmt@3com.com Tel 408-764-5248 Fax 408-764-5002 3Com Corporation, 5400 Bayfront Plaza, Santa Clara, CA, USA 95052-8145 Newsgroups: comp.dcom.lans.ethernet Path: nntp-server.caltech.edu!netline-fddi.jpl.nasa.gov!elroy.jpl.nasa.gov!lll-winken.llnl.gov!enews.sgi.com!dataserv2.denver.sgi.com!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: MLT-3 Message-ID: Organization: Rhyolite Software Date: Sat, 1 Apr 1995 06:27:41 GMT References: <3l6vho$a95@hpchase.rose.hp.com> <3lf0qf$o0s@hpchase.rose.hp.com> Lines: 144 In article <3lf0qf$o0s@hpchase.rose.hp.com> djdove@hprnd.rose.hp.com (Dan Dove) writes: > ... >BTW, You did not "understate" the worst case delay. You "overstated" the >simplicity in calculating delay in a probabilistic system. You claimed >that it was simple math. I merely asked you to prove your case. > >Now you say the delay is "OK" without having shown the calculation. Look at Mart Molle's graphs. >:what he wrote a couple weeks ago about it being a major change to the >:802.3 MAC that was "forced" upon 802.3. > >BLAM is a well thought-out proposal to improve a system that has serious >problems supporting time-dependent applications. It only improves the >situation, it does not resolve it. If you disagree, please calculate >the delay in a BLAM system per my previous example. BLAM does not >resolve the topological problems with 100Base-T, nor does it solve the >noise immunity problems of 100Base-TX. A few articles ago, Mr. Dove wrote: ] T4 ] had to make serious changes to their delay specs to avoid "Capture" type ] effects in the most recent draft of the standard. Perhaps he has changed his opinion since then. >:Compare his claims that MLT-3 >:does not work and frequently loses user data with his most recent article >:that seemed to say that all that 100BASE-T needs is a change in connector >: pins. > >You mis-state my position. My position is that MLT-3 is poor technology >and the 100Base-T decision to switch pins makes it even worse. I have >not confirmed that merely re-mapping the pins will make it acceptable for >European requirements wrt noise immunity, only that it fails as currently >specified. Mr. Dove misremembers his words. The first we heard here about the evils of MLT-3 was when he wrote that MLT-3 causes user data corruption. He later denied saying so, but before his article had expired, and I was able to quote his words. No one thinks MLT-3 is the best possible choice that could be made today. It is too bad no one has a time machine to go back to the ANSI X3T9.5 FDDI meetings to tell them to use something else. However, only Mr. Dove seems to think MLT-3 is unusable. >:My prediction is that by Jan 1996, Mr. Dove will be selling something >:other than 100VG-AnyLAN. I also predict that by Dec 31, 1996, his >:employer will have sold more 100Mbps 802.3 interfaces than 100VG-AnyLAN. > >If I recall correctly, you were also predicting that FDDI-TP adapters >would be selling at/below 100Mbps Ethernet by now. I just returned from >Interop and must say that this is not happening. I've been wrong about the price (not cost) of FDDI-TP adapters. The parts cost in comparable quantities for the same buses with comparable system performence for all of 100VG-AnyLAN, 100BASE-T, and FDDI-TP is essentially the same. Two of those differ only in the MAC chip. One reason I've wrong about the price of FDDI-TP adapters is that the only way anyone is able to sell 100Mbps ethernet today is by giving it away. When people want 100Mbit/sec for production, they buy FDDI. When they want "proofs of concept" or "trials", they buy ATM. (Yes, and generally get much less than 100Mbps, but that's another sad story of salescritters, consultants, seminars, buzzwords, and the trade press). Giving away 100BASE-T is a great idea. It is why 100BASE-T has clobbered 100VG-AnyLAN, and why 100BASE-T will survive to compete effectively against FDDI. It is extremely effective to tell people "buy this $399.99 card for your power users. run it with your existing 10BASE-T switches now. someday replace your hub and you'll have 100Mbps painlessly." >:Speaking of demands for numbers, remember Mr. Dove's failure to provide >:performance data for 100VG-AnyLAN. > >I never offered to provide such numbers nor did I ever suggest that >adapter card performance is a factor in the 100T-100VG debate. Who's >100VG adapter should be compared to who's 100BT adapter? > >I just don't see the relevance to this discussion. Mr. Dove did talk about 100VG-AnyLAN measurements a few months ago. He thought 70Mbit/sec for a Novell server was good. Perhaps he lost interest when subsequent trade press tests found 100BASE-T cards faster than 100VG. (I've yet to see a trade press test of either flavor ethernet that was not bogus. Never mind that their bogus numbers are mostly consistent with my prejudices, that 100VG should be a little faster than 100BASE-T and both less than 80Mbps.) This discussion concerns Mr. Dove's statements about MLT-3 and 100BASE-T. Comparisons among 100BASE-T and 100VG-AnyLAN, and baselines from others including ATM and FDDI are relevant. If you cannot compare the speed 100VG-AnyLAN and 100T cards, how can you compare their packet loss rates? Bit error rates are no less affected by design choices than performance. Who cares about 100Mbps noise tolerance if it is not also fast? If Mr. Dove is right that MLT-3 is terrible, then the consequent packet losses (detected with the FDDI-TP or 100BASE-T CRC or TCP or other higher layer checksum) cause retransmissions. A noticable packet loss rate causes a noticable retransmission rate. Retransmissions destroy performance. Thus, performance measurements are directly relevant to Mr. Dove's statements about MLT-3. Mr. Dove raises a good point about finding comparable adapters. Another, reason that FDDI interfaces remain more expensive than either 100Mbps ethernet flavor is that at least some FDDI interfaces are built to move 80 or more Megabits/second indefinitely, while most 100 Mbps ethernet interfaces can do 100Mbps only if you don't want to move more than a dozen KBytes at a time. The big bucks in any 100Mbit/sec interface are not in the MAC, PHY, or PMD chips. The hardware that actually talks to the wires is fairly cheap and does not differ much among FDDI or Ethernets. With recent silicon, even ATM is not so different. The other machinery needed to move 100 MBytes within 10 seconds is where the big costs and design choices lie. Besides my prediction that by Dec 31, 1996, Mr. Dove's employer will have sold more 100Mbps 802.3 interfaces than 100VG-AnyLAN, and my wild guess that HP will have sold more FDDI interfaces than 100VG-AnyLAN and 100BASE-T interfaces combined, I predict that a lot of people now buying 100 Mbps ethernet (of both flavors) are going to be unhappy in a few years. People now talk about "#@$%#@*! cheap PC Ethernet cards that cannot go as fast as workstations". When they finally buy 100Mbps hubs, they'll find that their cheap 100Mbps PC cards are of familiar quality. The ever popular prescription "reduce rsize/wsize for cheap PC's" is going to make a return in a few years. Or course, eventually people will make 100Mbps ethernet interfaces with enough buffering and/or fast enough hosts to actually run at full speed, just as finally PC's are now able to staturate Ethernets, 8 or 9 years after more expensive systems. Vernon Schryver vjs@rhyolite.com Newsgroups: comp.dcom.lans.ethernet Path: nntp-server.caltech.edu!netline-fddi.jpl.nasa.gov!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!aswell From: aswell@netcom.com (Cecil Aswell) Subject: Re: MLT-3 Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <3560@bridge2.NSD.3Com.COM> Date: Sun, 2 Apr 1995 21:46:42 GMT Lines: 73 Sender: aswell@netcom16.netcom.com cmt@ESD.3Com.COM (Chris Thomson) writes: >Dan Dove writes: >>Attached is an MLT-3 noise budget that I posted a few months ago. >> >>The number at the bottom (for MLT-3 it's 49mV) is the amount of signal >>available to overcome externally coupled noise. My recent measurements >>show that in a 3V/m field, the noise coupled into the wiring components >>may be as high as 150mV. 3 times greater than the signal. This is bad. >> >>Coding Scheme MLT-3/CAT-V QUARTET/CAT-V QUARTET/CAT-III >>-------------- ----------- ------------- -------------- >>Channel bandwidth 125Mhz 25Mhz 25Mhz >>Min Txmit level .95V 2.2V 2.2V >>Str Ret Loss 1.2dB 1.0dB 1.5dB >>Cable attenuation @ Nyquist 17.0dB 8.0dB 12.0dB >>X-connect loss .5dB .5dB .5dB >>Crosstalk interference 4.5dB .5dB 4.5dB* >>Equalization tolerance .5dB .5dB .5dB >>DC imbalance .75dB .1dB .1dB >>Threshold tolerance .75dB .1dB .1dB >>PLL tolerance .5dB .5dB .75dB >>---------------------------- ----------- ------------- --------------- >>Resultant eye opening 49mV 657mV 380mV >> (bundles) 226mV* >> >>Since MLT-3 uses five times the channel bandwidth, this means that noise >>coupled from external sources (which increases with frequency) will be >>much greater. >> >>Measurements presented to ANSI show that external fields of 3V/m can >>induce up to 180mV of noise onto a CAT-V cable system which has CAT-III >>cross connects. Clearly those systems will not work. While I have seen >>no test reports of pure CAT-V cable plants to indicate a reasonable >>margin might exist, it is clear that a customer wiring plant >>*will not work* if it is not installed with absolute precision. >Dan, Dan, Dan. >So much FUD. I was sufficiently annoyed by the above to pass it along >to the guy who designed our 100Base-TX and FX router cards. Here's >his reply: >Issue 1- Nyquist frequency is improperly applied. MLT-3 is a 3 level >signalling scheme, not binary, and consequently the Nyquist frequency >is (125mhz data rate) / (2 * log base 2 (3)) = 39.4mhz, not 62.5mhz as the >author assumed. This reduces cable attenuation to 13db rather than >17db. >Issue 2- Crosstalk attenuation is also wrong in his analysis due to the >same issue Nyquist issue, but I don't know the correct number since I >don't have tables handy for this parameter. probably about 1.5 db. rest of post deleted ... I believe 62.5 MHz is the correct number for MLT-3. Nyquist frequency is half the baud (or symbol) rate. According to Nyquist a three level code _can_ convey 125 Mbits per second at a baud rate of 78.8 MBaud but this requires encoding (log base 2 (3)) bits per symbol as per the above equation. MLT-3 only encodes one bit per symbol. NEXT depends on the power spectral density of the transmitted signal as well as the receiver cutoff frequency (assuming crosstalk means NEXT here). Nyquist rate is relevant only for ideal systems when calculating NEXT. Since we deal in the real world I suggest the number to use in calculating NEXT bandwidth should be the cutoff freqency of the magnetics which as I recall is 85 MHz or higher. Cecil Aswell aswell@netcom.com Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!gatech!howland.reston.ans.net!swrinde!sdd.hp.com!hplabs!hplntx!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Date: 3 Apr 1995 17:10:23 GMT Organization: HP Roseville Networks Division Lines: 101 Message-ID: <3lpa5v$9h6@hpchase.rose.hp.com> References: <3560@bridge2.NSD.3Com.COM> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] Chris Thomson (cmt@ESD.3Com.COM) wrote: : Dan, Dan, Dan. : So much FUD. I was sufficiently annoyed by the above to pass it along : to the guy who designed our 100Base-TX and FX router cards. Here's : his reply: I wish you hadn't pre-defined your post with this statement, but I appreciate your effort to move into the TECHNICAL domain. : Issue 1- Nyquist frequency is improperly applied. MLT-3 is a 3 level : signalling scheme, not binary, and consequently the Nyquist frequency : is (125mhz data rate) / (2 * log base 2 (3)) = 39.4mhz, not 62.5mhz as the : author assumed. This reduces cable attenuation to 13db rather than : 17db. Wrong! Nyquist stated that in order to recover a signal, you must sample it at TWICE the maximum frequency of the information. If your friend's assertion was true, you could theoretically filter out all information above 39.4Mhz and still recover data. This is incorrect. The Nyquist frequency for MLT-3 is 62.5Mhz. You must allow AT LEAST this much bandwidth to operate, and most MLT-3 implementations will allow much more in order to minimize Inter-Symbol Interference. Now... Once we have firmly established that you must equalize to 62.5Mhz or higher, this means that a receive equalizer will have to increase the received signal (and noise) by 17dB in order to properly recover data. In addition, since we have excess bandwidth (to reduce ISI) this means our equalizer will continue increasing gain with frequency so that noise at 80Mhz will be even greater than when received. : Issue 2- Crosstalk attenuation is also wrong in his analysis due to the : same issue Nyquist issue, but I don't know the correct number since I : don't have tables handy for this parameter. probably about 1.5 db. See response to Issue 1. Nyquist frequency is 62.5Mhz. : Issue 3- 3v/m is a *HUGE* field. Some relative comparisons: : FCC A limits: 35 microvolts/meter : Relative sensitivity of a TV: 1milivolt/m Wrong! 3V/m is not a huge field in the realm of susceptibility. Yes, regarding emissions it is very large, but this is not my point. I am not saying MLT-3 is flawed for emissions, but for noise immunity. TV/Radio transmitters, generators, elevators, etc... generate large fields that can interfere with electronic equipment. : Fields drop off linearly with distance, so at 3km your 3v/m source will : be 1milivolt/m and will still interfere with other people's telelvisions and : they will probably call the cops on you and you will go to jail. Unless you are a licensed transmitter, or your energy is very transient in nature such that it does not impact TVs, Radios, etc.. but would be very disruptive to electronic equipment that relies on very low BERs. : Many : television stations operate in frequency ranges near to critical 100Base-TX : frequencies. Thank you for emphasizing my point. Actually they are IN the 100TX spectrum. More importantly, European Norms have been established which will require immunity in 3V/m fields to be proven in order to ship into EC countries in 1996. You can argue with them about whether their tests are important. : Incidentally, the FCC does NOT regulate emissions below 30mhz so you have : no similar guarantees about 12.5mhz noise that would blow away a 100Base-VG : network. Yes noise could exist which would harm 100VG signals. Of course, it would also harm 10Base-T signals. This is important. If you have 10Base-T and it works, 100VG will perform comparably wrt noise immunity. : The 100Base-TX network would be unaffected by noise at this frequency : as it would not pass the receive filters. Wrong! 100TX DOES have energy below 30Mhz. This is part of the problem, it has energy all the way to DC. However, I don't think noise in this frequency band represents a problem, even for 100TX. It is too low to be of concern. : 4. Analysis does not factor in the fact that noise is attenuated along : with the signal. So unless that noise source is right next to the : receiving station, the analysis is invalid. If you generate the noise : at the middle of the network, and apply the *correct* cable attenuation : and crosstalk interference numbers, 100Base-TX is about the same as : Cat-3 100Base-VG, though admittedly worse than CAT-5 VG. Thanks for the effort Chris. Other than accusing me of FUD when my facts are straight, your post was very good. It allows for the discussion of things that can be easily verified as fact or fiction. Dan Dove HP Roseville Networks Newsgroups: comp.dcom.lans.ethernet Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!newsxfer.itd.umich.edu!srvr1.flint.umich.edu!gmi!zombie.ncsc.mil!news.mathworks.com!usenet.eel.ufl.edu!spool.mu.edu!sdd.hp.com!hplabs!hplextra!hplb!anc From: anc@hplb.hpl.hp.com (Alistair Coles) Subject: Re: MLT-3 Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Message-ID: Date: Tue, 4 Apr 1995 14:28:41 GMT References: <3560@bridge2.NSD.3Com.COM> Nntp-Posting-Host: thelma.hpl.hp.com Organization: Hewlett-Packard Laboratories, Bristol, England X-Newsreader: TIN [version 1.2 PL0.7] Lines: 50 Chris Thomson wrote: : So much FUD. I was sufficiently annoyed by the above to pass it along : to the guy who designed our 100Base-TX and FX router cards. Here's : his reply: : Issue 1- Nyquist frequency is improperly applied. MLT-3 is a 3 level : signalling scheme, not binary, and consequently the Nyquist frequency : is (125mhz data rate) / (2 * log base 2 (3)) = 39.4mhz, not 62.5mhz as the : author assumed. This reduces cable attenuation to 13db rather than : 17db. This argument mistakenly assumes that because MLT3 uses 3 symbol levels then its output symbol rate is less than the input data rate. This is absolutely NOT the case. MLT3 belongs to the family of line codes known as "pseudoternary". The "pseudo" refers to the fact that whilst the code uses three symbol levels, it does not provide the symbol rate reduction theoretically possible with a true ternary code (1.58bits/symbol). In fact, an MLT-3 coder produces one ternary symbol for each binary symbol at its input (1bit/symbol). Your 100BASE-TX designer ought to be able to confirm that the ternary symbols are clocked out of the transceiver at the same rate as the binary data is clocked in i.e. 125MHz. Rather than reducing the symbol rate, the three levels provide redundancy in the code which is used to shape the spectrum (concentrating energy at low frequencies). So, the symbol rate of a 100-TX MLT3 system is 125Mbaud. The Nyquist criterion tells us that the minimum bandwidth in which this may be transmitted without severe distortion is half the symbol rate, i.e. 62.5MHz. This is what defines the Nyquist frequency, and Dan Dove has quoted the correct number. Other examples of pseudoternary line codes are AMI and HDB3. These also do not reduce the symbol rate from that of the binary system. You'll find a more detailed discussion of pseudoternary line codes and the Nyquist criterion in any student textbook in this field (e.g. "Digital Communications", Lee and Messerschmitt). : Issue 2- Crosstalk attenuation is also wrong in his analysis due to the : same issue Nyquist issue, but I don't know the correct number since I : don't have tables handy for this parameter. probably about 1.5 db. See above. Dan does have the correct Nyquist frequency. Hope this helps, Alistair Coles Newsgroups: comp.dcom.lans.ethernet Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!newsxfer.itd.umich.edu!srvr1.flint.umich.edu!gmi!zombie.ncsc.mil!news.mathworks.com!news.alpha.net!uwm.edu!cs.utexas.edu!swrinde!sdd.hp.com!hplabs!hplextra!hplb!sgm From: sgm@hplb.hpl.hp.com (Steve Methley) Subject: Re: MLT-3 Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Message-ID: Date: Tue, 4 Apr 1995 15:23:23 GMT References: <3560@bridge2.NSD.3Com.COM> Nntp-Posting-Host: methley2.hpl.hp.com Organization: Hewlett-Packard Laboratories, Bristol, England X-Newsreader: TIN [version 1.2 PL0.7] Lines: 36 Chris Thomson (cmt@ESD.3Com.COM) wrote: : Issue 3- 3v/m is a *HUGE* field. No, 3V/m is the medium grade field (Grade 2) for susceptibility testing. : FCC A limits: 35 microvolts/meter No, FCC A radiated limits are in 3 bands below 1GHz, starting with 40dBuV/m for 30-88MHz when working on a 10m site (other sites are different). On the whole I think you are perhaps understandably confused by the apparent plethora of international EMC regulations, particularly it seems in your case the difference between _Radiated Emissions_ and _Susceptibility_ measurements - they are quite seperate tests. There are published works on the subject of the limits and how to test for them, a very readable start being Henry Ott's "Noise Reduction Techniques in Electronic Systems". Be sure to get the latest limits from the relevant standards body however. : ......If you generate the noise at the middle of the network, and : apply the *correct* cable attenuation and crosstalk interference : numbers, 100Base-TX is about the same as Cat-3 100Base-VG, though : admittedly worse than CAT-5 VG. No, the whole cable plant is on the test site and subject to the standard field. Unsurprisingly the binary codes have higher immunity, just as Dan detailed in his earlier post. Hope this helps, -- Best Regards, Steve. Newsgroups: comp.dcom.lans.ethernet Path: nntp-server.caltech.edu!ferrari.mst6.lanl.gov!newshost.lanl.gov!ncar!newsxfer.itd.umich.edu!srvr1.flint.umich.edu!gmi!usenet.eel.ufl.edu!news.mathworks.com!news.alpha.net!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!ix.netcom.com!noc.netcom.net!netcomsv!uu3news.netcom.com!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: MLT-3 Message-ID: Organization: Rhyolite Software Date: Tue, 4 Apr 1995 13:59:16 GMT References: <3lq4nh$o1l@hpchase.rose.hp.com> Lines: 76 In article <3lq4nh$o1l@hpchase.rose.hp.com> djdove@hprnd.rose.hp.com (Dan Dove) writes: >Vernon Schryver (vjs@calcite.rhyolite.com) wrote: > >Dan Dove wrote :> > >:> ... >:>BTW, You did not "understate" the worst case delay. You "overstated" the >:>simplicity in calculating delay in a probabilistic system. You claimed >:>that it was simple math. I merely asked you to prove your case. >:> >:>Now you say the delay is "OK" without having shown the calculation. > >: Look at Mart Molle's graphs. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >I have. I have also read the words in between. Have you? > >When reading Mart Molle's BLAM paper, I found this statement on page 12; > >"It is interesting to note the extent to which the capture effect can >interfere with the stort-term fairness of the protocol; as the network >becomes completely saturated, each host in a 2-host system will on >_average_ transmit more than 100 frames in a row before allowing >the other to send anything." > >With 100Mbps data rates and 1500byte packets, this means that one >user could "capture" the LAN for 12ms. > >Therefore, a single "capture" event could render your multi-media >application broken if it required 4.2ms refresh rate as the problem >was defined. > >Dan Dove (What's wrong with this picture???) Sheesh. Do you suppose there was a reason why I wrote 30% instead of "saturated?" (I think it was "5%, 10%, or 30%", but it has expired). Even in the orignal text from last year I was not talking about a saturated Ethernet. I was specifically talking about the regime before the capture effect occurs. In my most recent words, I was referring to Mart Molle's fairly recent graphs of the delay distribution of packets at various loads. If you pick a reasonable load and discard packets that are delayed by more than your budget, then you have a lossy link with bounded delay (like a phone line but unlike Ethernet). Mr. Dove could make his case sound better if he would stop and think about applications. No reasonable application on reasonable-cost systems requires delay or jitter in delay less than 12 ms, not to mention 4.2 ms. 12 ms at the speed of light is only 2200 miles. A reasonable person will put far more than 12 ms of anti-jitter buffering in the receiver, if only because almost all operating systems schedule processes with jitter far worse than 12 ms. How many scheduler clocks run faster than 100 Hz? The last time we went around this merry-go-round, a year or two ago, Pat Thaler chimed in to say that the problems that demand priorities are trying to solve do not involve 3 ms total delays (I think Mr. Dove's number then was 3 ms). Instead, the concern was that after 30 or 50 ms of wide area network delay, they figured they had only a few ms of delay budget remaining for the LANs. That makes Demand Priorites sound reasonable, until you stop and consider what happens when you have lots of high priority traffic. (Those Netware tests make it seem as if only 70 Mbps a lot of traffic.) If your network is heavily loaded, then demand priorites are not a solution; you need something like a committed, guaranteed information rate as with ATM or sync. bandwidth on FDDI. When your network is loaded, you must have some kind of admission policy before committing to a new traffic source. If your LAN is not heavily loaded, you don't need to worry (you do not need demand priorities), because things will work fine. In other words, Demand Priorites are unneeded except when they are insufficient. Vernon Schryver vjs@rhyolite.com Path: nntp-server.caltech.edu!news.claremont.edu!bridge2!cmt From: cmt@ESD.3Com.COM (Chris Thomson) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Message-ID: <3575@bridge2.NSD.3Com.COM> Date: 6 Apr 95 20:37:00 GMT Sender: news@bridge2.NSD.3Com.COM Organization: 3Com Corporation Lines: 72 Nntp-Posting-Host: saskatoon.nsd.3com.com Earlier I posted, on behalf of one of our design engineers: >: Issue 1- Nyquist frequency is improperly applied. MLT-3 is a 3 level >: signalling scheme, not binary, and consequently the Nyquist frequency >: is (125mhz data rate) / (2 * log base 2 (3)) = 39.4mhz, not 62.5mhz as the >: author assumed. This reduces cable attenuation to 13db rather than >: 17db. Then Alistair Coles (and another person whose article has expired) responded: >This argument mistakenly assumes that because MLT3 uses 3 symbol levels then >its output symbol rate is less than the input data rate. This is absolutely >NOT the case. > > MLT3 belongs to the family of line codes known as "pseudoternary". The >"pseudo" refers to the fact that whilst the code uses three symbol levels, >it does not provide the symbol rate reduction theoretically possible with a >true ternary code (1.58bits/symbol). In fact, an MLT-3 coder produces one >ternary symbol for each binary symbol at its input (1bit/symbol). Your >100BASE-TX designer ought to be able to confirm that the ternary symbols are >clocked out of the transceiver at the same rate as the binary data is >clocked in i.e. 125MHz. Rather than reducing the symbol rate, the three >levels provide redundancy in the code which is used to shape the spectrum >(concentrating energy at low frequencies). > >So, the symbol rate of a 100-TX MLT3 system is 125Mbaud. The Nyquist >criterion tells us that the minimum bandwidth in which this may be >transmitted without severe distortion is half the symbol rate, i.e. 62.5MHz. >This is what defines the Nyquist frequency, and Dan Dove has quoted the >correct number. > >: Issue 2- Crosstalk attenuation is also wrong in his analysis due to the >: same issue Nyquist issue, but I don't know the correct number since I >: don't have tables handy for this parameter. probably about 1.5 db. > >See above. Dan does have the correct Nyquist frequency. The response from our engineer could be summarized as "oops!". Here's an e-mail he sent to me: |I'm afraid there is validity to these replies. Use of the Nyquist |frequency is just a (bad) benchmark because what you are really |interested in is, as one replier indicated, the spectral power density |of the signal. For both loss and crosstalk measurements, this is the |true measurement metric. Things get really complicated when you get to |analysis at this level, since you need to convolve the transmitted |power density with the line characteristics and receiver filtering |characteristics, not to mention the characteristics of the receiving |IC. In reality the characteristics of the receiving filter and IC are |probably the most important and most overlooked parts of the equation. | |I concede that the Nyquist theorem was improperly applied here to |analyze attenuation and crosstalk. MLT-3 does only encode one bit per |symbol, and the Nyquist frequency is not 39.5mhz as I indicated. As a |3 level encoding scheme MLT-3 does shift the spectral power density |towards the lower end of the spectrum however, although it doesn't show |up as a reduced Nyquist frequency since the Nyquist frequency doesn't |take into account spectral power density. | |However, I still maintain MLT-3 based systems are considerably more robust |than Dan was suggesting. | |Sorry for the confusion. Disclaimer: I'm just passing these messages back and forth; I know just enough about this topic to be able to pronounce the words correctly. What sets me to posting at all are Dan's shrill cries that 100Base-TX "*will not work*", when I'm running it all day every day in the lab next door. -- Chris Thomson cmt@3com.com Tel 408-764-5248 Fax 408-764-5002 3Com Corporation, 5400 Bayfront Plaza, Santa Clara, CA, USA 95052-8145 Path: nntp-server.caltech.edu!news.claremont.edu!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hplntx!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Date: 10 Apr 1995 17:04:40 GMT Organization: HP Roseville Networks Division Lines: 78 Message-ID: <3mbof8$2eq@hpchase.rose.hp.com> References: <3575@bridge2.NSD.3Com.COM> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] Chris Thomson (cmt@ESD.3Com.COM) wrote: Alistair Coles wrote : > : >See above. Dan does have the correct Nyquist frequency. : The response from our engineer could be summarized as "oops!". : Here's an e-mail he sent to me: : |I'm afraid there is validity to these replies. Use of the Nyquist : |frequency is just a (bad) benchmark because what you are really : |interested in is, as one replier indicated, the spectral power density : |of the signal. For both loss and crosstalk measurements, this is the : |true measurement metric. Things get really complicated when you get to : |analysis at this level, since you need to convolve the transmitted : |power density with the line characteristics and receiver filtering : |characteristics, not to mention the characteristics of the receiving : |IC. In reality the characteristics of the receiving filter and IC are : |probably the most important and most overlooked parts of the equation. I posted numbers to address the above issues in my original MLT-3 budget. : |I concede that the Nyquist theorem was improperly applied here to : |analyze attenuation and crosstalk. MLT-3 does only encode one bit per : |symbol, and the Nyquist frequency is not 39.5mhz as I indicated. As a : |3 level encoding scheme MLT-3 does shift the spectral power density : |towards the lower end of the spectrum however, although it doesn't show : |up as a reduced Nyquist frequency since the Nyquist frequency doesn't : |take into account spectral power density. In other words, YES we equalize well above 62.5Mhz in order to properly recover data in a noise-free environment. Of course, this means our system is more susceptible to high-frequency noise components. : |However, I still maintain MLT-3 based systems are considerably more robust : |than Dan was suggesting. On what TECHNICAL basis is this rationale supported? This is the basic problem that exists in the 100Base-TX design community. Someone brings up a technical problem WITH ANALYSIS to support it. The position is refuted with inaccurate or non-existant technical discussion. Then the ultimate position is assumed that "MLT-3 based systems are considerably more robust than Dan was suggesting". Excuse me for being unwilling to accept this as a reasonable technical debate. This is totally unacceptable. Show some valid technical data to support your position or it must be considered hogwash. : |Sorry for the confusion. The confusion appears to be endemic in the 100Base-TX design community. : Disclaimer: I'm just passing these messages back and forth; I know just : enough about this topic to be able to pronounce the words correctly. : What sets me to posting at all are Dan's shrill cries that 100Base-TX : "*will not work*", when I'm running it all day every day in the lab next door. 1) My claims are not shrill. They are only repetitious because the 100TX community (as you have demonstrated so well) has been incompetent at addressing them professionally. 2) I will bet that you are not testing your 100TX in a noise environment that truly tests the system. What is so damn hard to understand about the fact that you don't get Bit Errors in a noise free environment??? Put some noise on your cables and get back to me, OK? I've already done it (3 times now) and 100TX breaks with very small external fields applied to the CAT-5 cable components. Just as the analysis has predicted. Dan Dove Disclaimer: I have a low tolerance for people who accuse me of FUD when their position is either unsupported by any technical argument, or it is supported by erroneous technical argument. This may explain my terseness. Path: nntp-server.caltech.edu!news.claremont.edu!paris.ics.uci.edu!csulb.edu!nic-nac.CSU.net!newshub.sdsu.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!swrinde!sdd.hp.com!hplabs!hplntx!hpscit.sc.hp.com!icon!hpchase.rose.hp.com!djdove From: djdove@hprnd.rose.hp.com (Dan Dove) Newsgroups: comp.dcom.lans.ethernet Subject: Re: MLT-3 Date: 10 Apr 1995 18:32:29 GMT Organization: HP Roseville Networks Division Lines: 63 Message-ID: <3mbtjt$64h@hpchase.rose.hp.com> References: <3mbof8$2eq@hpchase.rose.hp.com> NNTP-Posting-Host: hprnd.rose.hp.com X-Newsreader: TIN [version 1.1 PL8.8] I am posting an additional note with (hopefully) a bit more composure. Earlier I wrote: : Chris Thomson (cmt@ESD.3Com.COM) wrote: CT> I'm afraid there is validity to these replies. Use of the Nyquist CT> frequency is just a (bad) benchmark because what you are really CT> interested in is, as one replier indicated, the spectral power density CT> of the signal. I disagree that Nyquist Frequency is a (bad) benchmark. It defines the minimum point at which your receive_based equalizer must respond. In practice, receive equalizers in MLT-3 systems have a much wider bandwidth. In order to have 50% excess bandwidth, you would require a cutoff frequency in your equalizer of 93.75Mhz. An excess bandwidth of 50% would be very minimal and result in a large amount of data dependent jitter. I expect that real implementations are operating with an equalizer cutoff frequency of 75% or greater. What this means to the casual observer, is that external noise is AMPLIFIED at frequencies above 62.5Mhz with greater and greater gain as frequency increases until the cutoff point. CT> For both loss and crosstalk measurements, this is the CT> true measurement metric. DD> (He is referring to PSD) Actually, for loss, the Nyquist Frequency is critical as it defines how much attenuation your equalizer must compensate for. An equalizer has to "equalize" the cable response, NOT the type of code being used. For crosstalk, it is questionable whether you can use PSD which is a long-term integration of the power spectral density to analyze the impact of short-term bit patterns which may have larger amplitudes at the higher frequencies than the PSD would indicate. CT> Things get really complicated when you get to CT> analysis at this level, since you need to convolve the transmitted CT> power density with the line characteristics and receiver filtering CT> characteristics, not to mention the characteristics of the receiving CT> IC. How does the convolution of PSD (a long term integral) involve the instaneous voltage on the wire for a particular bit sequence? CT> In reality the characteristics of the receiving filter and IC are CT> probably the most important and most overlooked parts of the equation. Please post these characteristics with an analysis that shows how your MLT-3 system is really more robust than I have shown. What is the cutoff frequency of your equalizer? How much noise (at what frequencies) can your system withstand? Dan Dove PS: My apologies to the net for losing my cool on that last post. I hope we can continue this discussion with real numbers rather than warm fuzzies, generalities, insults, etc.