HDTenEightyP/NetNews huggingface dataset:
From: turner@olympus.ctron.com
Newsgroups: comp.dcom.lans.misc
Subject: Fiber Connectors
Date: 24 Jul 92 17:45:29 GMT
Reply-To: turner@olympus.ctron.com ()
Organization: Cabletron Systems INc.
Originator: turner@olympus

Hi World,

I know that ST fiber connector is a trade mark of AT&T.  Can someone tell
me what the "ST" stands for?  How about the "SMA" fiber connector?

Thanks,

Dave Turenr Cabletron Systems Inc.   Internet Turner@ctron.com
 


-- 
David P. Turner         Interne: turner@ctron.com |
Cabletron Systems Inc.  Compuserve: 76702,1733    |
Voice: (603) 335-9400                             |
From: bob@comlab.gatech.edu
Newsgroups: comp.dcom.lans.misc
Subject: Beta LanMan OS/2 2.0 redirector now available
Date: 21 Jul 92 14:40:50 GMT
Reply-To: bob@comlab.gatech.edu ()
Organization: Georgia Institute of Technology

Microsoft has just released the beta version of the LAN Manager redirector
for OS/2 2.0.  It is known to have some compatibility problems with some
adapters so be sure to check the README file.  I also understand for now
it only works with LAN Manager 2.1 and not 2.0.  I only have 2.0.  8-( 
From what I hear I'm pretty sure other versions of LanMan will be
supported when the final release happens.

The new redirector can be gotten from "comlab.gatech.edu".  The file is
"lmos22.zip" in the "/pub/lanman" directory.

Bob
--
Bob Baggerman                         !  bob.baggerman@gtri.gatech.edu
Communications Laboratory             !  bob@comlab.gatech.edu
Georgia Tech Research Institute       !  qseclrb@prism.gatech.edu
Atlanta, GA  30332  USA               !  404-894-3525
From: jonathan@mentor.cc.purdue.edu (Virtual Me)
Newsgroups: comp.dcom.lans.misc
Subject: Wireless Nodes
Date: 31 Jul 92 08:45:10 GMT
Distribution: usa
Organization: Purdue University

A friend's company is wanting to extend their Novell netork across the street
to another building.  They've been thinking of stringing a wire across the
street, but it seems to us that setting up a wireless link would be the way
to go.

So what are the options?  Would IR be better than RF for such a short
distance?  Is one vendor's product superior to another's?


Any help will be much appreciated.

Thanks in advance,
Jonathan


___ |Jonathan      |Internet:jonathan@mentor.cc.purdue.edu|Whom computers
|__||Neuenschwander|NeXTmail:buzz@symphony.cc.purdue.edu  |would destroy, they
|   |              |America Online:Buzz Lee               |must first drive mad
From: jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
Newsgroups: comp.dcom.lans.misc
Subject: Is my transceiver connected?
Date: 30 Jul 92 14:34:09 GMT
Organization: NASA/MSFC

I have had a heck of a time getting repair service for some Ethernet
drops which were provided a long time ago without any equipment to plug
them into.  Now the computers start showing up, and about a fourth of
the drops are dead, mostly because the stupid transceiver cables have
pulled loose from the transceivers.

I'm under strict orders not to go messing around where the transceivers
are, primarily because of a recent on-the-job injury I sustained doing
something similar.  (You *don't* want to know about it.)  Also, our
repair guys are scum (there, I've said it) and won't come over unless I
issue paperwork calling for a new installation.

I'd like to not have to pay these crooks for reinstallation of what
they didn't do right the first time, but as I have no choice, it would
be good to know which drops are going to work and which aren't.

Is there any simple way I can test to see if a transceiver cable is
connected to a transceiver from the computer end of the cable?  Some
sort of ohmmeter check, maybe?  I don't have a computer I can roll
around to every location, unfortunately.

A few of these drops come from Cabletron MT-800 8-to-1 multiport
transceivers.  I need to take this into account, too, because I don't
know which drop goes to which type of transceiver.  The individual
transceivers draw power from the computer, but I don't think that's
true of MT-800 type devices.
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov or jpc@gaia.msfc.nasa.gov
NASA/MSFC Communications Systems Branch
Newsgroups: comp.dcom.lans.misc
Subject: SMC COM20020 experiences
From: albaugh@dms.UUCP (Mike Albaugh)
Date: 20 Jul 92 23:04:14 GMT
Organization: Atari Games Inc., Milpitas, CA


	A friend is considering using the COM20020 chip from
SMC for a small LAN. Cost is an object, and interoperability
(like TCP/IP) is _not_. So, the questions are:

1)	Does anybody have experience with this chip? It _seems_ to do the
	job for him, but sometimes nasty gotchas surface later.

2)	Is there a valid second source at the exact drop-in replacement
	level?

3)	If no to (2), is there a comparable chip, perhaps requiring a
	PCB or software change?

4)	Other suggestions? (aside from the DSP bit-boffing approach he
	is trying to replace)

email to me, please, and I will forward. I sort of doubt others are
all _that_ interested in ARCnet on toasters.

					Mike

| Mike Albaugh (albaugh@agames.com || netcom.com!agames.com!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)
Newsgroups: comp.dcom.lans.misc
From: seifert@netcom.com (Rich Seifert)
Subject: Re: Bridge hello messge format?
Date: Mon, 27 Jul 92 20:51:29 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <15824@pitt.UUCP>, bjpst5@icarus.lis.pitt.edu (Bryan J Petty) writes:
> 
>  Does anyone know the format for the Hello messages for an ethernet
>  bridge? This is defined in the 802.1d draft (I think). thanks Bryan 


It is completely specified in IEEE 802.1 d (which is now a signed-off
IEEE spec, and an ISO Draft IS.
It is formally known as a "Bridge PDU" and here goes:

Protocol Identifier (2 bytes; indicates that this is the Spanning Tree
Protocol)

Protocol Version # (1 byte, currently at version 1)

BPDU Type (1 byte; 0 = BPDU, 1 = Topology Change Notification)

Flags (1 byte; used for Topology change flags)

Root Identifier (8 bytes; identifies current root bridge. 2 bytes
are the bridge priority,m and 6 bytes are the bridge's 48 bit
unique ID)

Root Path Cost (4 bytes; the cost to the root from the bridge sending
the BPDU)

Bridge Identifier (8 bytes; indicates the bridge sending the BPDU)

Port IDentifier (2 bytes; indicates the port # on the bridge from
which the BPDU originated)

Message Age ( 2 bytes, indicates the age of this BPDU- they get old
as they propagate through the network)

Max Age (2 bytes; the maximum age of a valid BPDU as specified by the root)

Hello Time (2 bytes; the interval between Hellos coming from the root)

Forward Delay (2 bytes; used to control the time to wait when changing
certain bridge states, and for aging of bridge tables)

The BPDU is encapsulated in an 802.n frame.

-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"
From: rich@pluto.dss.com (Rich Rupp)
Newsgroups: comp.dcom.lans.misc
Subject: RE: Email address for datability?
Date: 29 Jul 92 15:14:23 GMT
Organization: Datability, Carlstadt, NJ

Datability can be reached at "support@dss.com" or "sales@dss.com".
Individual Datability users may be reached through that host also. In
addition, we monitor the relevant news groups and DECUSERVE.

Regards,

Rich Rupp
-- 

----------------------------------------------------------------------------
Richard L. Rupp                                           rich@pluto.dss.com
Datability Inc.                          201 438 2400x312, Fax: 201 438 7525
From: mtraynor@hpindda.cup.hp.com (Michael Traynor)
Date: Wed, 22 Jul 1992 04:40:41 GMT
Subject: Re: Need help with Token Ring
Organization: Hewlett-Packard
Newsgroups: comp.dcom.lans.misc

/ hpindda:comp.dcom.lans.misc / ijn@stl.stc.co.uk (Ian Normington) /  2:21 am  Jul 10, 1992 /

> Is it poosible to have a PC with a suitable T.R. card and software (such
> as FTP's PC/TCP) directly connected to the Token Ring interface (requires
> STP cable connected to a nine-pin female port). Or do I need a Trunk
> Coupling Unit. Or ...

Simply put, no.  You cannot simply connect two lobe cables (the cable which
normally runs from the card to the TCU) together and expect to have a two
node "ring".  Examining the wiring diagrams in the 802.5 spec shows why:
While the cable connectors appear physically symetrical, logically they are
not (ie. the signals are on the wrong pins).  There may be more to it, but
I checked just for sanity.

On the other hand, if you like to get your hands dirty, and you own a
soldering iron, you can probably build a simple two port TCU.  Again, the
802.5 spec should show you how.

Good luck,

Mike Traynor
Newsgroups: comp.dcom.lans.misc
From: hgpeach@ms.uky.edu (Harold Peach)
Subject: Stacker and PCLan
Date: Mon, 27 Jul 1992 17:09:57 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

We have a small IBM token-ring network running IBM's PCLan.  The users
keep a large number of databases on the file server and have filled up
the hard disk.  We plan on moving them to a different network in a few
months, but need a short-term solution.  We are thinking of installing
Stacker to compress their data files.  Anyone have any experience with
Stacker and PCLan coexisting?

Please reply to me direct as I do not regularily read this group.

Harold
hgpeach@ms.uky.edu
-- 
Harold G. Peach, Jr.       ><>       N4FLZ       _%       hgpeach@s.ms.uky.edu
Newsgroups: comp.dcom.lans.misc
From: darrell@cerberus.bhpese.oz.au (Darrell Boon)
Subject: Email address for datability?
Organization: BHP, Newcastle, Australia
Date: Mon, 27 Jul 1992 07:27:16 GMT
Summary: anyone know it ?
Keywords: email datability

Subject say it, anyone know a datability email address
I'll take anything..

Thanks
-- 
Darrell Boon				Phone   :  +61-49-401-675
Senior Systems Engineer			Fax     :  +61-49-402-165
BHP Information Technology		Internet:  darrell@bhpese.oz.au
P.O. Box 216 Hamilton 2303 AUSTRALIA
Newsgroups: comp.dcom.lans,comp.sys.novell
From: dawson@intelhf.hf.intel.com (Bryan Dawson)
Subject: Looking for Program which installs software over network
Summary: Interested in anyone using automated install software.
Keywords: Software Install Novell Lan
Organization: Development Tools Operation, Intel Corp., Hillsboro  OR
Date: Wed, 22 Jul 92 14:33:06 GMT

Our local networks have been growing and are being merged with
other networks in the company.  This makes it less and less practical
to install software by "sneaker net" or in an ad-hoc method which
relies on each workstation user to "do the right thing".  I am told
that there are software packages which provide a method for software
to be installed automatically over the network.  I would like to
hear from anyone using such software:

1> What package are you using and what are your LANS like?
2> How well does this setup work?
3> How do problems like changes in autoexec.bat get solved?
4> Any other comments of interest?

_________Thanks and Regards from: _____________________________

Bryan Dawson   >>  (503) 696-4231
               >>  Bryan_Dawson_at_jfccm1@ccm.hf.intel.com
Whose Opinions???  I'm a software engineer, I write programs,
that's ALL I do, and I WON'T STOP until EVERYTHING is CODE!
_______________________________________________________________

Newsgroups: comp.dcom.lans.fddi
From: caro@uni-paderborn.de (Carsten Rose)
Subject: Re: FDDI performance testing
Organization: Uni-GH Paderborn
X-Newsreader: Tin 1.1 PL4
Date: Wed, 29 Jul 1992 09:42:37 GMT

Hi,

Here are 3 news article which discuss the performance test utility 'ttcp'.
There are 2 different versions. The newer one has a variable socket buffer
size. You can get it from sgi.sgi.com, look in ~ftp/sgi/src/ttcp/.
There's a little different in the behavior of the '-s' option between the
2 versions of 'ttcp' - read the top of ttcp.c (this could save a lot your
time :-) ).

------------------------------------------------------------

From pbinfo2!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!sunic!ugle.unit.no!spurv.runit.sintef.no!he Fri Jul 24 09:37:07 1992
Newsgroups: comp.dcom.lans.fddi
From: Havard.Eidnes@runit.sintef.no (Havard Eidnes)
Subject: Re: ttcp source
Originator: he@spurv.runit.sintef.no
Organization: University of Trondheim, Norway
Date: Tue, 7 Jul 92 21:19:59 GMT

In article <mod5q9o@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>In article <12r0rkINN5nf@hal.com> jha@hal.com (Jane Ha) writes:
>+---------------
>| Does anyone know where I can get a copy of the latest public domain
>| ttcp source?
>+---------------
>
>Anonymous-FTP to sgi.sgi.com, look in ~ftp/sgi/src/ttcp/

If anyone want to play with the TCP send and receive window sizes, I made
some changes to the previous version of ttcp, and placed them along with
that version in ugle.unit.no, ~ftp/pub/unix/network/ttcp*.

- Havard

From pbinfo2!math.fu-berlin.de!zrz.tu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!uunet!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!ames!sgi!rhyolite!vjs Fri Jul 24 09:44:02 1992
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: ttcp source
Date: 9 Jul 92 20:49:32 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Jul9.055112.10311@ultra.com>, shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
> 
> Just a note of caution:  We've played around with SO_SNDBUF/SO_RCVBUF
> on several vendors' systems over the last year.  It turns out that
> the TCP implementations of more than one vendor do some bad things
> when you increase the buffer size.  You can get genuinely lousy
> performance on some systems by increasing the buffer size.  Also, if
> one end of the connection does it but the other doesn't, performance
> can really go down the tubes, apparently due to nasty interactions with
> delayed ack.  Also, the TCP of one Important Big Manfacturer just plain
> breaks when the buffer size is over 32K.
> 
> The moral is that you shouldn't just blindly add SO_SNDBUF/SO_RCVBUF
> to your applications until you verify that it actually improves things
> for the application you are using on the systems you use.  Also, you
> can get unpleasant results when one vendor decides to change their
> default, but other vendors still default to 4K.


all true.

Big windows can be bad on slow speed links such as SLIP Or PPP.  The
"go-back-n" retransmission policy in TCP is rather painful over a
2KByte/sec modem link.  Even with slow start, you can often have a full
window queued on the modem after a packet gets lost.

We have seen very unhappy file transfer speeds between our machines and
those of a larger workstation company when we use any window > 4K.
(We've been far above 4K for years.)  Packet traces suggest unhappy
interactions among delayed-ack, anti-silly-window and a bug
somewhere--we don't think in our stuff.  Rumor has it that their newer
code does not show the same symptom.

We've changed our default send and receive sizes to 60KBytes.  Unless
you do something on purpose, you'll get a window or "socket buffer"
size with SGI IRIX 4.0 that is about the largest possible without the
new TCP Large Window option.  This makes `ttcp` faster over our FDDI
implementation, and so I don't think we'll be changing back.

60K windows have turned up an amazing number of TCP implementations
that still follow the old BSD 4.2 bug and think the 16-values are
signed.


Vernon Schryver,  vjs@sgi.com

From pbinfo2!math.fu-berlin.de!Sirius.dfn.de!darwin.sura.net!wupost!cs.utexas.edu!ut-emx!ibmchs!auschs!awdprime.austin.ibm.com!vulcan.austin.ibm.com!will Fri Jul 24 09:46:41 1992
From: will@vulcan.austin.ibm.com (Will Fiveash)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: ttcp source
Date: 13 Jul 92 18:21:08 GMT
Organization: IBM PSP Austin, Tx.

In article <1992Jul9.055112.10311@ultra.com> shj@ultra.com (Steve Jay {Ultra Unix SW Mgr}) writes:
>In <n1j3lm0@sgi.sgi.com> rpw3@rigden.wpd.sgi.com (Rob Warnock) writes:
>
>>Our version also does the same thing, for those implementations for which
>>you can set the window size with the socket-buffer size (most BSD-based ones).
>>It contains the "-b" option (set SO_SNDBUF/SO_RCVBUF) which was added by
>>Steve Miller of the University of Maryland.
>
>Just a note of caution:  We've played around with SO_SNDBUF/SO_RCVBUF
>on several vendors' systems over the last year.  It turns out that
>the TCP implementations of more than one vendor do some bad things
>when you increase the buffer size.  You can get genuinely lousy
>performance on some systems by increasing the buffer size.  Also, if
>one end of the connection does it but the other doesn't, performance
>can really go down the tubes, apparently due to nasty interactions with
>delayed ack.  Also, the TCP of one Important Big Manfacturer just plain
>breaks when the buffer size is over 32K.

If you are refering to IBM, I am curious as to the specifics of your
last sentence.  I know for a fact that AIX v3.2 supports socket buffers
 > 56K (which was a limit historically associated with BSD 4.3).  TCP
on the other hand has problems partially due to protocol architecture
and BSD 4.3 implementation (variables declared as signed shorts instead
of ulongs, etc...).  We have fixed the implementation bugs and can run
TCP over our Serial Optical Channel which supports an MTU of 60K.  

I agree with your statements concerning the effects of socket buffer
sizes on TCP throughput but an important point not mentioned is that
the socket receive buffer determines the TCP window.  In my throughput
tests over the SOCC, I have found that the interaction between packet
size and window size is critical to achieving maximum throughput.



-- 
Will Fiveash,  "My opinions above, facts below."
Internet:  fiveash@perfmap.austin.ibm.com 


------------------------------------------------------------

Ciao
	Carsten

Carsten Rose, Germany		| Life. That's what happens while
EMail : caro@uni-paderborn.de	| you're thinking about the future
From: alan@StarConn.com (Alan Deikman)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: FDDI at home
Date: 29 Jul 92 21:54:13 GMT
Article-I.D.: StarConn.1992Jul29.215413.29741
Organization: Starnet-Public Access UNIX--Los Altos, CA  415-949-3133

In article <Bryzt2.AyB@world.std.com> edwards@world.std.com (Jonathan Edwards) writes:
>I am researching how to wire up my new house for future data comm needs.
>It would seem that running shielded twisted pairs would allow for everything
>from RS232 to 10base-T to FDDI. Have the cable specs for FDDI over 
>twisted pairs been established? And will it meet FCC class B?

Just out of curiosity, exactly what kinds of applications are
you planning on running at home?  Store receipies?  Balance your
checkbook?  Sheesh... And I thought *I* was a computer nerd for
buying a 486.

Regards,

Alan Deikman
============
From: uther@utkux1.utk.edu (Ron Tipton)
Newsgroups: comp.dcom.lans.fddi
Subject: FDDI performance testing
Date: 28 Jul 92 13:29:46 GMT
Reply-To: uther@utkux1.utk.edu
Distribution: na
Organization: Univ. of Tenn. Computing Center, Knoxville

------------


A while ago, someone posted the results of some performance tests
on FDDI cards using Sun workstations and (amoung others) Crescendo
FDDI cards.  I foolishly discarded the name of whoever did these
tests and have been unable to get performace within a magnitude
of this tester.  I would like to have a copy of the programs they
used to do these tests.

If anyone knows who posted these results, or knows the source of
these or other programs used to test FDDI cards I urgently need
the info.

Thanks,

Ron Tipton
From: edwards@world.std.com (Jonathan Edwards)
Subject: FDDI at home
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 26 Jul 1992 00:24:37 GMT

I am researching how to wire up my new house for future data comm needs.
It would seem that running shielded twisted pairs would allow for everything
from RS232 to 10base-T to FDDI. Have the cable specs for FDDI over 
twisted pairs been established? And will it meet FCC class B?
From: seifert@netcom.com (Rich Seifert)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: using active hubs & FDDI
Date: 27 Jul 92 20:43:52 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <nqqtk74@rhyolite.wpd.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> Some FDDI-ether bridges are junk, because they do not do the necessary
> IP fragmentation of 4K IP/FDDI datagrams.  Think about NFS which
> likes 4K and 8K UDP/IP datagrams.
> 

By definition, a bridge cannot perform fragmentation at all. This does
not make them junk. (It may make them ineffective for connecting 
FDDI-to-Ethernet when there are stations directly connected to the FDDI,
however, in exactly the environment you describe).

If one wants the capabilities of a given network protocol (such as
fragmentation in IP), one must implement that protocol. This is what
a router does. If one does not want the complexities of a router, 
they must live with the limitations of a bridge. Such is life.

There are MANY systems and protocols which neither provide nor
need fragmentation (such as AppleTalk, IPX, DECnet, ...). These
can use bridges or routers between FDDI and Ethernet based on
any number of factors (manageability, cost, performance, etc.)

The world uses, but does not necessarily revolve around, IP and NFS.

-- 
Rich Seifert                    Networks and Communications Consulting
seifert@netcom.com              (408) 996-0922
                                (408) 996-2860 FAX
"... specialists in Local Area Networks and Data Communications systems"
From: cliff@garnet.berkeley.edu (Cliff Frost)
Newsgroups: comp.dcom.lans.fddi
Subject: Re: benchmark terminology
Date: 31 Jul 1992 00:38:06 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: garnet.berkeley.edu

In article <1992Jul29.224911.2683@advtech.uswest.com>, jsims@uswest.com (John Sims) writes:
|> I'm curious what people feel is the correct way to report FDDI
|> (or for that matter data comm systems in general) throughput.

For throughput, K = 1000 is by far the most common usage that I've seen,
both in news postings and in ftp source code for various systems.

Ethernet is 10Mb/s, is 10,000,000 bits/sec (or close), not close to
10,485,760 bits/sec.

	Cliff Frost
	UC Berkeley
Newsgroups: comp.dcom.lans.fddi
From: wittmann@engr.wisc.edu (art wittmann)
Subject: using active hubs & FDDI
Organization: College of Engineering, Univ. of Wisconsin-Madison
Date: 27 Jul 92 08:32:44 CDT
Originator: wittmann@muskie.engr.wisc.edu



I'm working on an article that is going to talk about use of hubs on 
networks that one might design for a relatively heavy duty environment.

Hub manufacturers are building bridging FDDI interfaces for their hubs,
however, I'd prefer to recommend routing when possible.  Anyone have 
any insight into the *right* way to integrate hubs and routers?

Anyone want to agree or disagree one routing being the preferred method
for connecting hubs?  The environment that I'm describing would use FDDI
as a backbone and hubs to distribute token ring and ethernet to end stations.

Thanks in advance for any comments.

Art

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Art Wittmann                                  Phone: (608) 263-1748
Network Manager                               Email: wittmann@engr.wisc.edu
Computer Aided Engineering Center                or: wittmann@cae.wisc.edu
University of Wisconsin, Madison