HDTenEightyP/NetNews huggingface dataset:
From: utterbac@husc9.harvard.edu (Margot Utterback)
Newsgroups: comp.dcom.lans.fddi
Subject: How many wires for level-5 CDDI?
Date: 27 Aug 92 03:00:08 GMT
Article-I.D.: husc3.1992Aug26.230009.15138
Organization: Harvard University Science Center

I am posting this for my husband, so please respond directly to him.

My company is moving to a new building and we are doing the wiring
planning now. 

We plan to put in Level-4 twisted pair cables because we cannot 
afford all level-5. However, just to hedge our bets, we thought to 
put in one cable to each office of level-5.  

However, I have seen things recently that indicate that FDDI requires
two cables to work.  Is this true of CDDI?  Is it just a waste to 
put in one cable of level-5? Or can I use 2 pairs of the cable for each
direction?  

Sorry if this is a simple question.

Brian Utterback
Mercury Computer Systems
blu@mc.com
Newsgroups: comp.dcom.lans.fddi
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: How many wires for level-5 CDDI?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 28 Aug 1992 10:20:38 GMT

utterbac@husc9.harvard.edu (Margot Utterback) writes:
+---------------
| We plan to put in Level-4 twisted pair cables because we cannot 
| afford all level-5. However, just to hedge our bets, we thought to 
| put in one cable to each office of level-5.  
| 
| However, I have seen things recently that indicate that FDDI requires
| two cables to work.  Is this true of CDDI?  Is it just a waste to 
| put in one cable of level-5? Or can I use 2 pairs of the cable for each
| direction?  
+---------------

You can use one cable for both directions of one station drop, but *only*
one "drop" per cable. Each drop needs two pairs, one for transmit and one
for receive. If you put in 3- or 4-pair cable for a CDDI drop, that's o.k.,
too, but you can't use the other pairs for anything. You'll use 2 pairs for
the CDDI and the other pair or two must be idle (unlike 10baseT).

(Why would anyone do that? Well, some people like to over-install all
cable plant, in case of expansion or change of use.)


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043

Newsgroups: comp.dcom.lans.fddi
From: koning@koning.enet.dec.com (Paul Koning)
Subject: Re: TTRT
Keywords: wrong
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture
Date: Mon, 31 Aug 1992 16:16:45 GMT


In article <p7lne2k@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|>...
|>Several FDDI vendors have decided to make all of their equipment have a
|>default T_Req of from 4 to 8 milliseconds.  Since the target token
|>rotation time is the smallest of all of the values CLAIM'ed by all
|>stations on the ring, many and perhaps most multi-vendor rings in the
|>world have TTRT's of just over 5 milliseconds.  (5 ms because that is
|>the value chosen by Raj Jain's employer.  Raj Jain's analysis is the
|>excuse people use for forcing their customers to use such low TTRT's.)
|>
|>Could someone remind me of why that does not waste as much as 30% of
|>the ring throughput?
|>...
|>Vernon Schryver,  vjs@sgi.com

You might try to get your facts right.  If you read the paper you will
find an answer to the question you posed... and you will also find that
5 ms is NOT the number Raj recommended.

For all of you interested in real information, here's a pointer to the paper:

	ACM SIGCOMM '90 Symposium of Communication Architectures
	and Protocols, Sept. 24-27 1990, Philadelphia, PA,
	page 264-275.
	"Performance analysis of FDDI token ring networks:
	effect of parameters and guidelines for setting TTRT"

/paul
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI over Twisted-Pair
Date: 27 Aug 92 01:58:28 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1309@bridge2.NSD.3Com.COM> div@NAD.3Com.COM writes:
+---------------
| Where can I get more details regarding the MLT-3 encoding scheme
| proposed by Cresendo Commn Corp.
+---------------

Does your company have an ANSI X3T9.5 representative? That's the group
that's been studying MLT-3 for FDDI. Your ".5" rep should have (or be
able to get a copy of) the current draft proposal.

+---------------
| Has this been adpoted by IEEE as the standard encoding scheme for FDDI
| over Cu ?
+---------------

Well, FDDI is not an IEEE standard, it's ANSI X3T9.5. But yes, the vote
was 41 to 1 (or something) two meetings ago to accept MLT-3 over NRZI
as the electrical encoding method.

Now they're discussing which scrambling method to use -- the self-synch-
ronizing code used currently by Crescendo & others versus a streaming
cipher proposed by Hamstra.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: srs@oasis.icl.co.uk (Steve Strong)
Newsgroups: comp.dcom.lans.fddi
Subject: Introductory text
Date: 28 Aug 92 10:45:31 GMT
Organization: ICL, Bracknell, Berkshire, RG12 4SN, UK
X-Newsreader: Tin 1.1 PL5

Does anyone know of an introductory text to FDDI? If so, could you
please email me a copy, or point me to an ftp site?

Cheers,

Steve
-- 
------------------------------------------------------------------------------
Steve Strong - email srs@oasis.icl.co.uk      | Wasn't me. I didn't say that.
               voice 44 344 424842 extn 2279  | Definitely got the wrong guy.
------------------------------------------------------------------------------
From: whiles@nswc.navy.mil (William Scott Hiles x1568)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI flow control in Layer 2 ????
Date: 27 Aug 92 20:09:42 GMT
Reply-To: whiles@nswc.navy.mil
Organization: Naval Surface Warfare Center, Dahlgren Division

In article p3u88c0@rhyolite.wpd.sgi.com, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>The whole idea is dumb, because it betrayes an ignorance of how the
>upper layers need and do flow control.  You don't want to slow down
>only after the receiver has started to drop packets!  Intead, you use
>something called a "window."  Unfortunately, most of the particpants in
>X3T9.5 think a window needs cleaning with Windex.  Of the minority of
>the X3T9.5 partiicpants who are technical contributors to their
>employers (i.e. not managers, marketing professionals, or professional
>standards representatives), most are hardware experts unaquainted with
>TCP, IP, TP4, FTP, slow start, leaky-bucket, ARP, encapsulation and so
>on.
>
>Vernon Schryver,  vjs@sgi.com

Why don't you attend a the X3T9.5 meetings and bring your vast knowledge of
all that is best to the world of the uneducated hardware experts.  Your 
comments about the problems with using the A and C bits are accurate but your
derogatory comments are unnecessary to get your point across.  There are
members of the X3T9.5 committee listning and I personally am offended that
you apply such a critical eye toward the work that was done for the standard.
Over the years of development of the FDDI standard a large number of companies
have worked and made sacrifices/compromises to produce a standard that is
acceptable and still useable.  Your comment implies a lack of knowledge on 
the committees part and I assure you that this is not the case.


---
Scott Hiles
whiles@relay.nswc.navy.mil

Standard disclaimer:
  The opinions expressed are those of my own and do not necessarily 
  reflect those of the DOD or the Navy.  I accept full responsibility.
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Trace initiation & propagation: UPSTREAM ?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 31 Aug 1992 14:52:53 GMT

In article <1992Aug31.102415.7220@tamsun.tamu.edu>, gagrawal@cs.tamu.edu (Gopal Agrawal) writes:
> ....
> In both these paragraphs they have used the word UPSTREAM 
> while I get the feeling that it should be DOWNSTREAM. I mean,
> it isn't possible to transmit upstream, is it?

Not on the same fiber.

>                                                 So does this 
> mean that they us the other counter-rotating ring to transmit 
> the HALT & QUIET symbols upstream ? 


Exactly.

Only dual attached stations need to worry about PC-Trace.  And dual
attached stations have an out-going fiber to both of their neighbors.

PC-Trace happens after the ring has been stuck in BEACON for many
seconds.

PC-Trace is "neat".  In other words, it is not one of the better parts
of the SMT standard.  It is often incompletely tested.  Based on what
I've seen at big networking shows, it sometimes does not work; some
systems (concentrators as well as hosts) propagate the trace signal the
onto the wrong ring.  That is not very worrisome, because the
circumstances requiring for a PC-Trace are rare and likely to both be
noticed by a human and to require human interaction to fix.

Another less than stellar part of the SMT standard is the directed
beacon that you are supposed send before starting PC-Trace.  Has anyone
anywhere ever had a directed beacon allert them to the location of a
problem in an FDDI ring?  Seriously, I'd like to hear of a case.

What should your station do if it receives the PC-Trace signal?  The
standard mentions leaving the ring and doing a self-test.  Is your
unattended station likely to discover that it is the cause of its
downstream neighbor being stuck in beacon?  In the likely case that the
self-test finds no problem, what should the station do, besides assume
the problem is in the neighbor and go back into the ring?  If the
problem is in your station, and you arrange to make your self-test take
a long time, perhaps the ring will be alive enough for high layer
messages to reach a human, who can come power cycle or otherwise fix
things.

Both of these features were a result of the Standards Process.  Someone
would figure out a way in which the ring could break, and then insist
on having their mechanism added to the standard, without regard to the
likelihood of the failure, the corrective action probably required, or
the probability of a failure of the mechanism itself causing the ring
to fail.  The rest of the group would either enthusiastically support
the additional mechanism (generally the non-implementors) or give up
and go along to avoid adding more months the years FDDI had already
taken.

Fortunately, judging from the rings I have seen, PC-Trace does not
itself cause many ring failures.  (I have seen rings sickened by broken
PC-Trace implementations at big network shows.)


Vernon Schryver,  vjs@sgi.com
From: jlin@hls.com
Newsgroups: comp.dcom.lans.fddi
Subject: What's difference between Scrub & Strip
Date: 2 Sep 92 23:39:38 GMT

Hi, there!

I am wondering that if any of you know how to do the frame stripping and
scrubbing.  Whenever a frame received by its source station, the frame will be
stripped and the beginning part of that frame becomes a truncated remnant frame
flowing on the ring.  Who will strip those remnant frames without using
scrubbing?  If whenever a station holds the token and sends out its frames, is
it necessary for this station to do the scrubbing until it receives its
frames coming back.  If yes, there's a overhead whenever a station wants to
send frames.  If not, the ring is going to be filled with the remnant frames
until a scrubbing request issues from CFM.  Is there any chips which will strip
the whole frame without producing the remnant frames?  Thank you for your
feedback in advance.

Jonathan Line
Xref: sparky comp.dcom.lans.fddi:592 comp.dcom.cell-relay:462
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FDDI flow control in Layer 2 ????
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 27 Aug 1992 22:30:11 GMT

In article <1992Aug27.200942.8232@relay.nswc.navy.mil>, whiles@nswc.navy.mil (William Scott Hiles x1568) writes:
> ...
> 
> Why don't you attend a the X3T9.5 meetings and bring your vast knowledge of
> all that is best to the world of the uneducated hardware experts.  Your 
> comments about the problems with using the A and C bits are accurate but your
> derogatory comments are unnecessary to get your point across.  There are
> members of the X3T9.5 committee listning and I personally am offended that
> you apply such a critical eye toward the work that was done for the standard.
> Over the years of development of the FDDI standard a large number of companies
> have worked and made sacrifices/compromises to produce a standard that is
> acceptable and still useable.  Your comment implies a lack of knowledge on 
> the committees part and I assure you that this is not the case.


I agree that everyone should attend a half dozen or more meetings of
X3T9 or any big standards organization to see for themselves the nature
of the beast.  One or two is not enough.  You must be around long enough
to develop a feeling for who does what and why.

When I was regularly attending X3T9.5, I met a lot of nice people and
some very knowledgable about all of the relevant technical issues.
Based on reports from the most recent meeting, I think that has not
changed.  It is still mostly filled with people more knowledgable about
ASIC's or Roberts Rules of Order than about compilers or virtual
circuits.  Many participants are more concerned with compromises that
will pass the plenary than with the best engineering choices.  A quick
reading of SMT 7.1 makes some of those compromises painfully evident.


Vernon Schryver,  vjs@sgi.com
From: div@NAD.3Com.COM (Dinesh Venkatachalam x5498)
Newsgroups: comp.dcom.lans.fddi
Subject: FDDI over Twisted-Pair
Date: 26 Aug 92 21:30:33 GMT
Reply-To: div@NAD.3Com.COM
Organization: 3Com Corp

Where can I get more details regarding the MLT-3 encoding scheme
proposed by Cresendo Commn Corp. I only have the sketchy details
about it ( from some Magazine ). I dont want to go and ask the
Marketing Folks in my company for this.

Has this been adpoted by IEEE as the standard encoding scheme for FDDI
over Cu ?

...Dinesh

Newsgroups: comp.dcom.lans.fddi
From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel 303-977-1480 jzwiebel@pgl-devsvr.den.mmc.com)
Subject: FAQ on SMT docs
Organization: PAGE @ Martin-Marietta
Date: Thu, 3 Sep 1992 14:07:34 GMT

Where can I get the latest SMT documents?

You know, As long as I've been reading News, I've never figured out how to get the FAQ if it hadn't been recently posted.

Thank you for your time
John Zwiebel
Xref: sparky comp.dcom.lans.fddi:594 comp.dcom.cell-relay:465
From: macomber@thoreau.nsc.com ( Robert Macomber)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FAQ on SMT docs
Date: 4 Sep 92 12:46:01 GMT
Reply-To: macomber@thoreau.nsc.com ( Robert Macomber)
Organization: National Semiconductor Corporation

In article <1992Sep3.140734.11966@den.mmc.com>,
jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel 303-977-1480 
> 
> Where can I get the latest SMT documents?

One source is ...

  Global Engineering
    (800) 854-7179
    (714) 261-1455

	- Robert

Robert L. Macomber MS 11-21   Advanced Communications
National Semiconductor Corp.  Internet: macomber@thoreau.NSC.COM
333 Western Avenue            UUCP: {sun|hplabs|decwrl}!nsc!thoreau!macomber
South Portland, Maine 04106   My opinions are my mine.
Newsgroups: comp.dcom.lans.fddi
From: gagrawal@cs.tamu.edu (Gopal Agrawal)
Subject: Trace initiation & propagation: UPSTREAM ?
Organization: Computer Science Dept., Texas A&M University
Date: Mon, 31 Aug 1992 10:24:15 GMT


I am attempting to go through the FDDI standards and 
there is a certain phrase in the TRACE INITIATION & 
TRACE PROPOGATION sections of the SMT standard (Rev. 6.2) 
that I do not understand. 

Trace Initiation: 
-----------------
....Upon initiation, the MAC sets a Trace-prop flag that 
indicates that the trace is to be propagated UPSTREAM 
					     ^^^^^^^^^
through the port that is feeding the MAC input. The ECM 
possesses the configuration information and propogates 
the trace to the appropriate port by issuing a PC-trace 
signal to the associated PCM.....


Trace propagation:
-------------------
When the PCM enters the Trace state, the PCM transmits 
alternating HALT & QUIET symbols. The port at the other 
end of the link will receive this as the MLS (master line 
state). The associated PCM with that port will set the 
Trace-prop flag to indicate that the trace is to be propogated 
UPSTREAM. 
^^^^^^^^^


In both these paragraphs they have used the word UPSTREAM 
while I get the feeling that it should be DOWNSTREAM. I mean,
it isn't possible to transmit upstream, is it?  So does this 
mean that they us the other counter-rotating ring to transmit 
the HALT & QUIET symbols upstream ? 


thanks,
--   
   ______ ______ ______ ______ __  |\/\/\/|
    ____/  __  /  __  /  __  /  /  |  \  /|   LIFE'S COMPLEX - IT HAS 
   / __   /   /  /   /  /   /  /   | (o)(o)   REAL & IMAGINARY PARTS  
  /   /  /   /   ___/  __  /  /    C      _) 
_____/ _____/ __/   __/ __/ ______/ | \___|  
E-mail - gagrawal@cs.tamu.edu       |   /   All Std. Disclaimers apply.
From: murakami@ntt-20.ntt.jp
Newsgroups: comp.dcom.lans.fddi
Subject: D.max and FDDI configuration
Date: 3 Sep 92 23:58:02 GMT
Reply-To: murakami@ntt-20.ntt.jp
Distribution: comp
Organization: NTT Basic Research Laboratories NUE Group
Posting-Front-End: TAO/ELIS Znews, Version 0.13, 9-May-91; Vanadium.NTT.JP

Hello,

I have a question about FDDI limits in its configuration. FDDI
spec assumes D_max(ring latency) is 1.617ms as a basis to define
various parameters. It allows up to 1000 physical links and 200km
fiber length. (200 * 5085ns + 1000 * 600ns) In the case of dual
ring, it allows up to 500 physical links and 100km.

So, here is my question. If we have a small number of nodes
compared to the assumed (1000 links), it seems we can have longer
distance than 2000km. Is it right? I'm confused by the relationship
between D_max and allowed variance of FDDI configuration.

Thanks in advance.

-Ken

Ken Murakami
NTT Laboratories
Tokyo, Japan
From: macomber@thoreau.nsc.com ( Robert Macomber)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Trace initiation & propagation: UPSTREAM ?
Date: 2 Sep 92 20:54:59 GMT
Reply-To: macomber@thoreau.nsc.com ( Robert Macomber)
Organization: National Semiconductor Corporation

In article <p8v3394@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com
(Vernon Schryver) writes:
> PC-Trace is "neat".  In other words, it is not one of the better parts
> of the SMT standard.  It is often incompletely tested.  Based on what
> I've seen at big networking shows, it sometimes does not work; some
> systems (concentrators as well as hosts) propagate the trace signal the
> onto the wrong ring.  That is not very worrisome, because the
> circumstances requiring for a PC-Trace are rare and likely to both be
> noticed by a human and to require human interaction to fix.
> 
> Another less than stellar part of the SMT standard is the directed
> beacon that you are supposed send before starting PC-Trace.  Has anyone
> anywhere ever had a directed beacon allert them to the location of a
> problem in an FDDI ring?  Seriously, I'd like to hear of a case.
> 

I'd been interested in hearing from anyone that has put directed beacons
to good use, too.  They're a bear to implement and knowing that some good
has come from the effort would be reassuring.

	- Robert


Robert L. Macomber MS 11-21   Advanced Communications
National Semiconductor Corp.  Internet: macomber@thoreau.NSC.COM
333 Western Avenue            UUCP: {sun|hplabs|decwrl}!nsc!thoreau!macomber
South Portland, Maine 04106   My opinions are my mine.
From: macomber@thoreau.nsc.com ( Robert Macomber)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Trace initiation & propagation: UPSTREAM ?
Date: 31 Aug 92 20:11:24 GMT
Reply-To: macomber@thoreau.nsc.com ( Robert Macomber)
Organization: National Semiconductor Corporation

In article <1992Aug31.102415.7220@tamsun.tamu.edu>, gagrawal@cs.tamu.edu
(Gopal Agrawal) writes:
>
> In both these paragraphs they have used the word UPSTREAM 
> while I get the feeling that it should be DOWNSTREAM. I mean,
> it isn't possible to transmit upstream, is it?  So does this 
> mean that they us the other counter-rotating ring to transmit 
> the HALT & QUIET symbols upstream ? 
>
 
Yes.  All legal FDDI Port-to-Port connections are full-duplex; even
though it is physically possible to construct simplex rings with three
or more Ports.  The term "upstream" means in the reverse direction from
the token path.

	- Robert



Robert L. Macomber MS 11-21   Advanced Communications
National Semiconductor Corp.  Internet: macomber@thoreau.NSC.COM
333 Western Avenue            UUCP: {sun|hplabs|decwrl}!nsc!thoreau!macomber
South Portland, Maine 04106   My opinions are my mine.
From: jzwiebel@pgl-devsvr.den.mmc.com (John Zwiebel 303-977-1480 jzwiebel@pgl-devsvr.den.mmc.com)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Introductory text
Date: 2 Sep 92 14:56:06 GMT
Organization: PAGE @ Martin-Marietta

There are books from three vendors that I have found very useful:

Fiber Distributed Data Interface Databook from National Semiconductor
The SUPERNET Family for FDDI from Advanced Micro Devices
A Primer to FDDI:... from Digital Equipment (DEC)
Digital Technical Journal also from DEC

Call your vendor rep and generally they are more than happy to mail you a copy.
From: tom@rsp.UUCP (Thomas Ruf)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: Trace initiation & propagation: UPSTREAM ?
Date: 1 Sep 92 18:50:36 GMT
Organization: RSP Datensysteme, W-Germany

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Only dual attached stations need to worry about PC-Trace.

Only dual attached stations need to worry about Trace-Propagation
and therefore PC-Trace. However, any station with at least one MAC
has to support Trace-Initiation and Trace-Termination.
A Trace is always initiated UPSTREAM.

Thomas
-- 
Thomas Ruf	tom@rsp.de	Schneider & Koch GmbH
{uunet,mcvax}!unido!rsp!tom	Germany
Newsgroups: comp.dcom.lans.fddi
From: zheng@z.eecs.umich.edu (Qin Zheng)
Subject: Re: TTRT
Organization: University of Michigan EECS Dept., Ann Arbor, MI
Date: Sun, 30 Aug 1992 21:27:13 GMT


vjs@rhyolite.wpd.sgi.com (Vernon Schryver) wrote:

>Several FDDI vendors have decided to make all of their equipment have a
>default T_Req of from 4 to 8 milliseconds.  Since the target token
>rotation time is the smallest of all of the values CLAIM'ed by all
>stations on the ring, many and perhaps most multi-vendor rings in the
>world have TTRT's of just over 5 milliseconds.  (5 ms because that is
>the value chosen by Raj Jain's employer.  Raj Jain's analysis is the
>excuse people use for forcing their customers to use such low TTRT's.)
>
>Could someone remind me of why that does not waste as much as 30% of
>the ring throughput?

  The waste could be less if more than one node is sending messages. But with
TTRT=5 ms and an 1 ms ring latency, the waste can never be less than 20%.
Doug Dykeman and Werner Bux's analysis said: "T_Opr should be at least 
five times the ring latency in order to maintain throughput levels above 
80 Mbits/s.". (IEEE Journal on Selected Areas in Communications, July 1988)

  Could someone tell me what is and where can I get Raj Jain's analysis?


Qin Zheng
Real-Time Computing Laboratory
The University of Michigan
zheng@eecs.umich.edu
Newsgroups: comp.dcom.lans.fddi