HDTenEightyP/NetNews huggingface dataset:
From: stan@casc.math.uh.edu (Stan Hanks)
Subject: Re: D.max and FDDI configuration
Organization: Center for Advanced Scientific Computation, Houston Tx.
Date: Wed, 9 Sep 1992 04:16:54 GMT

In article <pi69lek@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>35Mbit/sec won't get close to the 8 ms TTRT bandwidth limit.

Yup. Right again.

>There are several well established TCP/IP/FDDI implementations that can
>do > 35Mb/s in a single TCP stream.

Right. And even now, they get jammed down to ~35Mb/s. Like I said, its
an outside issue. I recognize that fixing this is IMPORTANT. I've always been
one of those "want-more-bandwidth-than-you-can-get" guys. But there are some
realities here, and one those is that if you're gonna try and do common-
carrier type things with off-the-shelf internetworking gear, you have
to give up something. Typically bandwidth. Bah. Humbug.

>It sounds to me as if you're situation will need a large TTRT when your
>forwarders start wanting to saturate the link.  It sounds as if any
>hopes based on the slowness of stations are not relevant, since it
>doesn't take many of even the slowest useful FDDI stations to hit 100
>Mb/s in aggregate.

Yes and no. If the demand set being served is lots of 10Mb/s end-to-end
links, then large (or "optimally efficient") TTRT is important to keep
any single node from saturating the net. On the other hand, using the
same basic gear to provide service for a single group of nodes which
need to communicate pair-wise at ~100Mb/s, I've got your problem in
spades. Worse, because I have this common-carrier problem to solve at
the same time.

In any case, multiple rings bridged or routed together will be required.
Which has its own interesting set of problems.

Clearly a case where something LOADS faster than FDDI would be nice....

--
Stanley P. Hanks      Principal Scientist,      Technology Transfer Associates
U.S. Snail:        P.O. Box 2087,   Bellaire    TX    77402-2087
FedEx/Shipping:    5303-F Glenmont, Houston     TX    77081
e-mail: stan@karazm.math.uh.edu   voice: (713) 661-2084     fax: (713) 661-0633
From: bazin@stna.dgac.fr (Sylvain Bazin STNA 7SO p8048 BD26)
Newsgroups: comp.dcom.lans.fddi
Subject: SMT FDDI on SUN servers
Date: 14 Sep 92 07:18:12 GMT
Organization: STNA 95 rue Henri Rochefort 91025 Evry Cedex 33(1)60.79.80.00

Hello there,

I'm testing the FDDI technology on SUN severs using the SUN FDDI board with 
a VME interface. I have problems with SMT layer of these servers ans I can't 
figure out whether. I did something wrong or the SUN's implementation is bugged.
Has anybody already met such problems and knows the solution ? I would be grateful for any help.
The following ones :

1 : No answer to a SMT ECHO NIF type frame is received when such a frame is sent 
on the network.

2 : Some thing with REQUEST type frames.

3 : When you cut the power for a bypass on a server, a beacon process is sent on the B ring and then (at physical level) ring A and ring B are at state "active" alternatively.

4 : No checking of the values of T_req, T_max and T_min is made when these values are modified with the fddi_eeprom command.

5 : The ring_map command is never ending (probably because of the lack of answers to "request" frames).

Thank you in advance for any comment.

Please, use the mail for to response.
 
--------------------------------------------------------------------------
BAZIN Sylvain			|  Service Technique Naviguation Aerienne |
tel : 33 1 60 79 80 48		|  95 rue Henri Rochefort		  |
fax : 33 1 60 79 80 01          |  91025 EVRY CEDEX FRANCE                |
bazin@stna7.stna.dgac.fr	|					  |
--------------------------------------------------------------------------
Newsgroups: comp.dcom.lans.fddi
From: koning@koning.enet.dec.com (Paul Koning)
Subject: Re: What's difference between Scrub & Strip
Reply-To: koning@koning.enet.dec.com
Organization: Digital Equipment Co., distributed systems architecture
Date: Fri, 11 Sep 1992 18:20:27 GMT


In article <pmb863c@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
|>...
|>Do you agree that no owner frames also consume no bandwidth?  That they
|>are only harmful if they have broadcast or multicast DA's or if you are
|>using MAC's in promiscuous mode?  (e.g. in bridges and ring analayzers;
|>DEC makes the former, SGI the latter)

That's what I said.

|>Has anyone seen throughput problems when purging is happening?
|>As in reducing TCP from 6MByte/sec to 2 MB/s?  I have one such report,
|>but have not been able to reproduce it, nor to figure out a way in
|>which it might happen.  I have seen 2-6% drops from 6MB/s by turning on
|>a purger on a ring with 50 usec latency and sub-millisecond average
|>token latency (even at 6.5MB/s), which I guess sounds benign and
|>reasonable, given that any jostling in timing hurts throughput, at
|>least for me.  I just can't see how the purger might reduce performance
|>by 60%.
|>
|>Vernon Schryver,  vjs@sgi.com

I saw that report too, and I can't explain it either.  Perhaps some data
will come in in the future.  It's good to hear that it doesn't show up
elsewhere.

	paul
From: vhalkka@klaava.Helsinki.FI (Vesa Halkka)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: D.max and FDDI configuration
Date: 9 Sep 92 21:54:47 GMT
Organization: University of Helsinki

In <1992Sep9.041654.13192@menudo.uh.edu> stan@casc.math.uh.edu (Stan Hanks) writes:

>Yes and no. If the demand set being served is lots of 10Mb/s end-to-end
>links, then large (or "optimally efficient") TTRT is important to keep
>any single node from saturating the net. On the other hand, using the
>same basic gear to provide service for a single group of nodes which
>need to communicate pair-wise at ~100Mb/s, I've got your problem in
>spades. Worse, because I have this common-carrier problem to solve at
>the same time.

I just retrieved Harvard test results for some ethernet/FDDI gear,
and *if the data is correct* the behaviour of existing FDDI 
equipment is, to be polite, peculiar. 

We were going to use FDDI to connect two wiring closets,
both having multiple ethernets. They are now connected
with one ethernet (some kilometers of fiber..), and it is
running out of steam.

FDDI seems not to be worth the money..

--
Vesa Halkka                       -O___/ 
University of Helsinki CC:         (  /   	 vhalkka@helsinki.fi 
Centre for scientific computing:  ~~~~~  	 vhalkka@csc.fi
Newsgroups: comp.dcom.lans.fddi
From: gagrawal@cs.tamu.edu (Gopal Agrawal)
Subject: who handles synchronous bandwidth ?
Organization: Computer Science Department, Texas A&M University
Date: Tue, 8 Sep 1992 22:47:44 GMT

While going through the data books of the AMD and National Semiconductor
chip sets for FDDI, I noticed that while AMD provides a register (TSYNC) 
in its MAC chip (for SAS) to represent the synchronous bandwidth, the N.S. 
chips don't. They just say that it is up to the user to assure that the 
synchronous frames queue does not take longer than the allocated bandwidth 
to transmit. Does the latest version of SMT say where exactly the 
synchronous bandwidth is to be handled. I mean, are there any registers 
or memory locations in the SMT or MAC or any other layer which are responsible 
to time the transmission of the synchronous frames ? 

How do the stations agree on the distribution of the bandwidth amongst 
themselves ?

regards,
--   
   ______ ______ ______ ______ __  |\/\/\/|
    ____/  __  /  __  /  __  /  /  |  \  /|   LIFE'S COMPLEX - IT HAS 
   / __   /   /  /   /  /   /  /   | (o)(o)   REAL & IMAGINARY PARTS  
  /   /  /   /   ___/  __  /  /    C      _) 
_____/ _____/ __/   __/ __/ ______/ | \___|  
E-mail - gagrawal@cs.tamu.edu       |   /   All Std. Disclaimers apply.

Newsgroups: comp.dcom.lans.fddi
From: xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC)
Subject: FDDI ring recovry time
Organization: Lund University
Distribution: world
Date: Sat, 12 Sep 1992 09:45:55 GMT


I was testing FDDI using a small ring with 4 nodes on it. When I rebooted
one node, the traffic between two other nodes was interrupted for
almost a second. This surprised me. I thought that with the high data rate,
short distances and few nodes it would be able to recreate a new token
in some tens of milliseconds (most of which would be to detect that it
is lost).

I've heard that the process in reality takes double the time you would
expect because first the ring is felt broken and will reconfigure itself 
into U-shape and start token regeneration, then immediately it will 
reconfigure itself as a ring and again start a new token regeneration.
So each regeneration was probably less than half a second, but that is
still a lot.

I would like to speed up the token regeneration process in a small
FDDI ring at least 10 times. Is there some parameters you can configure to
do that?

_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458, Telefax: +46 46 138225, Telex: 33533 LUNIVER S
E-mails: Jan.Engvald@ldc.lu.se,  xjeldc@seldc52,  psi%2403732202020::xjeldc
Newsgroups: comp.dcom.lans.fddi
From: stan@casc.math.uh.edu (Stan Hanks)
Subject: Re: D.max and FDDI configuration
Organization: Center for Advanced Scientific Computation, Houston Tx.
Distribution: comp
Date: Sun, 6 Sep 1992 21:14:09 GMT

In article <48073410@Vanadium.NTT.JP> murakami@ntt-20.ntt.jp writes:
>Hello,
>
>I have a question about FDDI limits in its configuration. ...
>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? 

Been there. Done it. 

See my paper from Winter '92 USENIX. We've run FDDI rings that are *BIG* --
right at 80 miles long with only 5 nodes. 

I wish more people read the standards this closely....

--
Stanley P. Hanks      Principal Scientist,      Technology Transfer Associates
U.S. Snail:        P.O. Box 2087,   Bellaire    TX    77402-2087
FedEx/Shipping:    5303-F Glenmont, Houston     TX    77081
e-mail: stan@karazm.math.uh.edu   voice: (713) 661-2084     fax: (713) 661-0633
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: D.max and FDDI configuration
Date: 10 Sep 92 15:44:06 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Sep9.215447.13867@klaava.Helsinki.FI>, vhalkka@klaava.Helsinki.FI (Vesa Halkka) writes:
> ....
> I just retrieved Harvard test results for some ethernet/FDDI gear,
> and *if the data is correct* the behaviour of existing FDDI 
> equipment is, to be polite, peculiar. 
> 
> We were going to use FDDI to connect two wiring closets,
> both having multiple ethernets. They are now connected
> with one ethernet (some kilometers of fiber..), and it is
> running out of steam.
> 
> FDDI seems not to be worth the money..


Which numbers do you think are "peculiar"?

What kind of performance would be worth how much money?  In which kinds
of applications (e.g. workstation-to-workstation or campus backbones)?

(I intend those as serious questions from someone at an FDDI vendor to
a thoughtful customer.)


Vernon Schryver,  vjs@sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: What's difference between Scrub & Strip
Date: 10 Sep 92 18:27:24 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Sep10.152047.641@nntpd.lkg.dec.com>, koning@koning.enet.dec.com (Paul Koning) writes:
> 
> Unfortunately, there are a number of similar-sounding terms around to 
> describe very different functions.  You were caught by one of them.
> 
> What the Motorola chipset can do is "ring purging".  This function -- usually
> enabled in Digital products -- indeed removes fragments left by the Strip
> function.  Its main purpose, though, is to remove "no owner" frames, which
> are things that can cause real trouble.  You can find more information about
> the ring purger in the following paper:
> 
> 	Proceedings of 16th Conf on LCN, Oct 14-17, 1991, 
> 	"A Ring Purger for the FDDI Token Ring", by Henry Yang and KK
> 	Ramakrishnan, page 503-514.
> 
> Fragments are harmless things, since they consume no ring bandwidth....


Do you agree that no owner frames also consume no bandwidth?  That they
are only harmful if they have broadcast or multicast DA's or if you are
using MAC's in promiscuous mode?  (e.g. in bridges and ring analayzers;
DEC makes the former, SGI the latter)


Has anyone seen throughput problems when purging is happening?
As in reducing TCP from 6MByte/sec to 2 MB/s?  I have one such report,
but have not been able to reproduce it, nor to figure out a way in
which it might happen.  I have seen 2-6% drops from 6MB/s by turning on
a purger on a ring with 50 usec latency and sub-millisecond average
token latency (even at 6.5MB/s), which I guess sounds benign and
reasonable, given that any jostling in timing hurts throughput, at
least for me.  I just can't see how the purger might reduce performance
by 60%.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi
From: stan@casc.math.uh.edu (Stan Hanks)
Subject: Re: D.max and FDDI configuration
Organization: Center for Advanced Scientific Computation, Houston Tx.
Date: Mon, 7 Sep 1992 03:33:22 GMT

In article <phc8hcg@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>In article <1992Sep6.211409.16525@menudo.uh.edu>, stan@casc.math.uh.edu (Stan Hanks) writes:
>> See my paper from Winter '92 USENIX. We've run FDDI rings that are *BIG* --
>> right at 80 miles long with only 5 nodes. 

>What TTRT do you use?

The Evil 8 ms. (enter egg-on-face-mode) It's the one value I didn't screw 
with. Maybe next time I do testing. (enter normal-mode)

>What is the aggregate ring bandwidth that you use?  (in other words,
>(microseconds while some station is transmitting data) / 1000000)

Calculate from the above, plus ring latency. Should be a smidge under 80 Mb/s.

>What is the maximum TCP/IP speed you can do between any pair of
>stations?
>
>I wouldn't be surprised if no or few of your 5 stations do TCP/IP on
>their own behalf, so maybe this is the better question;
>what is the maximum forwarding rate (either bridging or routing) in
>Bytes/sec between any pair of stations?

Correct. These stations are packaging LAN traffic into closed user groups
built out of TCP/IP streams. Their transmission  rates are limited by input 
rates into them. I'm (supposedly) going to have an opportunity to test this 
stuff in a multi-VAX environment running LAVC over FDDI (plus some other 
stuff) Real Soon. Until then, I won't have any real "fully loaded testing"
info. The best I've seen to date is ~35 Mb/s end-to-end, and I know
that's a function of how the data is getting into the FDDI node (i.e.
the bottleneck is *known* to be elsewhere in the system).

I'll try to remember to let you know what I find out. If nothing else,
look me up at InterOp in/near the MFS Datanet booth.

--
Stanley P. Hanks      Principal Scientist,      Technology Transfer Associates
U.S. Snail:        P.O. Box 2087,   Bellaire    TX    77402-2087
FedEx/Shipping:    5303-F Glenmont, Houston     TX    77081
e-mail: stan@karazm.math.uh.edu   voice: (713) 661-2084     fax: (713) 661-0633
Newsgroups: comp.dcom.lans.fddi
From: ronf@panther3.panther.mot.com (Ron Feigen)
Subject: Hardware from Protocol Engines Inc.
Organization: Motorola Panther Project, Chandler, AZ
Distribution: WOLRD
Date: Wed, 9 Sep 1992 18:19:32 GMT

Hi,

  I hope someone in Netland has the info I need.

  I heard there is an outfit called Protocol Engines that makes  a H/W based
protocol processing device.  How do I get a hold of them?  Are there any other
outfits that make a similar product?

  Please e-mail repsonses I am not a regular to many of these threads.

  Thanks in advance,


-- 

>
Ron Feigen
ronf@panther.mot.com
Newsgroups: comp.dcom.lans.fddi
Subject: Bellcore documents
From: mat@coral.math.arizona.edu (Mathew D. Watson)
Date: 15 Sep 92 12:27:02 GMT
Reply-To: mat@zeus.opt-sci.arizona.edu
Organization: The Vacuum

I'm interested in information on the physical layer for some of the
popular fiber nets such as FDDI, SONET, and ATM.  Specifically I need
to determine requirements for testing rise time, jitter, and BER.  I
have a Bellcore catalog, but I can't figure out which of the hundreds
of documents contain information that I am interested in.  If you know
of a good place for me to go for this info, then please tell me.

Is there another newsgroup that deals with the physical layer of
optical nets?

--Mat
Newsgroups: comp.dcom.lans.fddi
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: FDDI ring recovry time
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 13 Sep 1992 17:29:28 GMT

In article <xjeldc.39.716291157@lustorfs.ldc.lu.se>, xjeldc@lustorfs.ldc.lu.se (Jan Engvald LDC) writes:
> 
> I was testing FDDI using a small ring with 4 nodes on it. When I rebooted
> one node, the traffic between two other nodes was interrupted for
> almost a second. This surprised me. I thought that with the high data rate,
> short distances and few nodes it would be able to recreate a new token
> in some tens of milliseconds (most of which would be to detect that it
> is lost).
> 
> I've heard that the process in reality takes double the time you would
> expect because first the ring is felt broken and will reconfigure itself 
> into U-shape and start token regeneration, then immediately it will 
> reconfigure itself as a ring and again start a new token regeneration.
> So each regeneration was probably less than half a second, but that is
> still a lot.
> 
> I would like to speed up the token regeneration process in a small
> FDDI ring at least 10 times. Is there some parameters you can configure to
> do that?


Something is broken.  (I hope you're not using any SGI stations.)
    -"Ring recovery" is a matter of milliseconds.
    -Noticing that a neighbor is shut down (i.e. sending QLS or 
	"dark fiber") is a matter if microseconds
    -if you have optical bypass switches, they are required to switch
	in or out in less then dozens of milliseconds.

Obvious ways things might be broken:
    -"rebooting one node" does not reset the FDDI hardware in that
	station, and the FDDI hardware "went off into to the weeds"
    -two, not one station was rebooted, and on opposite sides of the ring.

A non-standard kludge I'm insufferably proud of in SGI products, that
I think everyone should implement, is in a dual-attached station to
arrange to make your PHY's into a repeater when your station is
"rebooting" or otherwise kaput but powered up.  If the station does not
have an optical bypass, this will keep the ring healthier.  On the
other hand, it's easy to make such a "repeater" that does more harm
than good (the polite will not ask how I know) and it seems the obvious
way to wire up at least a couple of the commercial chip sets requires a
real, often expensive "node processor" to defeat "repeat filters" in
MACs and PHYs.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.dcom.lans.fddi
From: mike@vulcan.webo.dg.com (Mike Fugere)
Subject: Re: What's difference between Scrub & Strip
Date: Wed, 9 Sep 92 16:22:40 GMT
Reply-To: mike@vulcan.webo.dg.com
Organization: Data General Corp., ASD/NSDD

I am reasonably sure that the new FDDI chipset offering from
Motorola can be set to automatically perform frame scrubbing.
This feature can also be disabled.  If I am wrong, perhaps
someone can correct me on this.... It would then be up to
the hardware and firmware guys designing the FDDI network
adaptor to utilize this feature in their products or not.

Mike Fugere
Design Engineer/Aviion Systems Development
Data General Corporation
Westborough, MA
"Of course, my employer has absolutely nothing to do with anything I say..."
From: turner@ctron.com (David Turner)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: fiber budgets
Date: 15 Sep 92 19:27:18 GMT
Reply-To: turner@olympus.ctron.com (David Turner)
Organization: Cabletron Systems INc.

In article <1992Sep14.152831.11360@alw.nih.gov> merike@alw.nih.gov (Merike Kaeo) writes:
>In designing an FDDI net we used to use the following design specs:
>1dB max loss per mated ST connector pair and .5dB max loss per splice.
>I'm beginning to wonder if this is ultra-conservative and am toying
>with the idea of changing that to .5dB max per mated connector pair
>and .2dB max loss per splice (mechanical).  I figure a 2dB margin in
>the budget will take care of any slop.  We do a tight QA on all
>installations and from what I've seen in terms of connector loss the
>.5dB max is reasonable.
>
>What are other folks doing?  Comments?
>


I use to make up fiber and FDDI connections.  I have installed several
FDDI LAN's including AMD's ANTC.  Typical connector loss should not exceed
.7dB.  I was able to achieve a loss of less then .3dB at the connector on
most of my work.

Regards,

Dave Turner

-- 
-------------------------------------------------------------------------------
David P. Turner         Internet: turner@ctron.com
Cabletron Systems Inc.  Compuserve: 76702,1733
Voice: (603) 335-9400   E-mail Cabletron Support Internet - support@ctron.com
Newsgroups: comp.dcom.lans.fddi
From: merike@alw.nih.gov (Merike Kaeo)
Subject: fiber budgets 
Organization: National Inst. of Health, DCRT, CSL
Date: Mon, 14 Sep 1992 15:28:31 GMT

In designing an FDDI net we used to use the following design specs:
1dB max loss per mated ST connector pair and .5dB max loss per splice.
I'm beginning to wonder if this is ultra-conservative and am toying
with the idea of changing that to .5dB max per mated connector pair
and .2dB max loss per splice (mechanical).  I figure a 2dB margin in
the budget will take care of any slop.  We do a tight QA on all
installations and from what I've seen in terms of connector loss the
.5dB max is reasonable.

What are other folks doing?  Comments?
 
-- 

Merike Kaeo			merike@alw.nih.gov
National Institutes of Health	(301) 402-1548 


                          o
                            \
                          \0/
       ||==================|=====||
       ||-+-+-+-+-+-+-+-+-/\+-+-+||
       ||=================\=\====||
       ||                        ||
       ||                        ||
       ||                        ||

    ......kill or be killed.....



Newsgroups: comp.dcom.lans.fddi