HDTenEightyP/NetNews huggingface dataset:
From: whinery@nancy.uhcc.Hawaii.Edu (Alan Whinery)
Subject: Re: How does NFS and Netware compare.
Organization: University of Hawaii
Date: Mon, 13 Apr 1992 19:44:29 GMT

In article <1992Apr10.075919.27627@cscdec.cs.com> jack@cscdec.cs.com (Jack Hudler) writes:
>In article <9848.29dffc05@cpva.saic.com> turnerj@cpva.saic.com writes:
>>In article <mqh+61@engin.umich.edu>, kelson@engin.umich.edu (David Lewis) writes:
>>
>
>Big ditto here! (ala rushy). We run both NFS and Novell, I think NFS is much more
>open and much better. Novell nickels and dimes... no wait hundereds and thousands
>you to death. When I receive a workstation just hook to the network. With DOS I 
>have to purchase a Network card $700+ (token ring). It's getting easyer to 
>by Sparcs than IBM's.
>However, Novell DOS Clients are almost twice as fast as NFS.

>(and etc.) 


I just came from a meeting with our Novell guy, who says that there is a new
product from Novell, called NetWare NFS, which allows you to integrate NFS
and NetWare 3.11 networks to include cross-system file sharing,  LOCKD,
FTP, and printer sharing between NFS and NetWare networks. Another
tidbit which seems very pertinent to your query...



--
D. Alan Whinery, Computer Networks Engineer |
The University of Hawaii at Manoa           |  networks@uhunix.uhcc.hawaii.edu
2565 The Mall, Honolulu, HI 96822           |  whinery@nancy.uhcc.hawaii.edu
(808)956-6430    FAX (808)956-2412          |
From: jack@cscdec.cs.com (Jack Hudler)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: How does NFS and Netware compare.
Date: 10 Apr 92 07:59:19 GMT
Organization: Computer Support Corporation,  Dallas, Texas.

In article <9848.29dffc05@cpva.saic.com> turnerj@cpva.saic.com writes:
>In article <mqh+61@engin.umich.edu>, kelson@engin.umich.edu (David Lewis) writes:
>
>> OR I can buy Netware.  I would assume that NFS on unix can handle large
>> amounts of traffic, but how does it stack up to NetWare?  I dont want
>
>It's my general understanding that for dos-based clients that Netware will
>outperform the various NFS implementation.  However, NFS from unix client to
>unix server is supposed to be very fast.  An NFS server is also going to prove
>to be a much more flexible and open platform, IMHO.  For dos clients, it seems
>to be a case of speed versus flexibility.

Big ditto here! (ala rushy). We run both NFS and Novell, I think NFS is much more
open and much better. Novell nickels and dimes... no wait hundereds and thousands
you to death. When I receive a workstation just hook to the network. With DOS I 
have to purchase a Network card $700+ (token ring). It's getting easyer to 
by Sparcs than IBM's.
However, Novell DOS Clients are almost twice as fast as NFS.
-- 
      /        /    /  /      /) /)
     / __  __ /_-  /--/     _(/ // _  _
  \_/ (_\_(__/ \  /  /_/_/_(_)_(/_(/_//_
Jack Hudler - Computer Support Corporation - Dallas,Texas - jack@cscdec.cs.com
Xref: sparky comp.dcom.lans.ethernet:612 comp.dcom.lans.misc:222
From: yoram@FibHaifa.com (Yoram Rimoni)
Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.misc
Subject: TCP/IP and NetBios Drivers
Keywords: TCP/IP, NetBios
Date: 12 Apr 92 04:58:10 GMT
Reply-To: yoram@FibHaifa.com
Followup-To: comp.dcom.lans.ethernet
Organization: Fibronics ltd., Haifa - ISRAEL
Originator: yoram@matisse


Hello, 

Recently I heard that you can not run TCP/IP or NetBios on a PC using a standard
Ethernat interface card and a driver at a speed beyond 1 Mbps.  This sounds to
me as a real drawback and I would like to verify this information with other
users.  Do anyone of you knows about a standard Ethernet card for a PC that can
support the above protocols at a higher rate ?

Thank you for the information.


--- Yoram Rimoni                                                      ---
--- Fibronics Ltd., Advanced Technology Center, Haifa 31905, Israel   ---
--- Phone : +972-4-313665        Fax: +972-4-550266                   ---
--- E-mail: yoram@FibHaifa.com   or  yoram@fibronics.UUCP             ---
-- 
--- Yoram Rimoni                                                      ---
--- Fibronics Ltd., Advanced Technology Center, Haifa 31905, Israel   ---
--- Phone : +972-4-313665        Fax: +972-4-550266                   ---
--- E-mail: yoram@FibHaifa.com   or  yoram@fibronics.UUCP             ---
From: ersicrko@el6.er.ele.tue.nl
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: timedomain reflectometer printout
Date: 13 Apr 92 13:02:49 GMT
Organization: Eindhoven University of Technology, , The Netherlands.

In article <1992Apr1.091156.13441@crow>, trich@crow.ogi.edu writes:
> I am in Japan and am in need of some help interpreting the printout
> from a timedomain reflectometer.
> 
> After much messing around I managed to borrow a timedomain reflectmeter
> which I figured out how to use from the book "Keeping the Link"
> by Martin Nemzow.   The printout shows a phenomena which isn't described
> in this book.   I see the normal negative spike for each transceiver
> every 2.5 meters, but then after a group of transcievers I see a positive
> spike exactly 2.5 meters after the last transciver in the group.
> 
> In fact after the last transceiver in any group I see a positive spike
> 2.5 meters later.  why ?
> 

In reply of this above mentioned text I can suggest some other books:
- Application note 22W-6342:"Tektronix Metallic TDR's for Cable Testing",
  Tektronix, Inc, 1987
- LANguage 89-Straight Talk from Tek on Cable Trouble_shooting,
  Tektronix, Inc, 1988

Alas I for myself have not read these books, but some books that I have read
mention these two books. 

Good hunting!

Rob Kouwenberg EUT
ERSICRKO@ER.ELE.TUE.NL.
------------------------------------------------------------------------
Dutch :'Een zebra is een wit beest met zwarte strepen. Voor de zwartkijkers
onder U, dit is niet zo.'

free translation:"A zebra is a white animal with black lines on it. For all
those negative people, it isn't so." 
From: pat@hprnd.rose.hp.com (Pat Thaler)
Date: Thu, 9 Apr 1992 23:48:32 GMT
Subject: Re: Repeaters
Organization: HP Roseville Networks Division
Newsgroups: comp.dcom.lans.ethernet

In comp.dcom.lans.ethernet, pngai@adobe.com (Phil Ngai) writes:

    In article <35011@nntpd.lkg.dec.com> dave@racer.lkg.dec.com writes:
    >	Allowable topologies shall contain only one signal path between
    >any two points on the network.  A maximum of four Repeater Sets may be in
    >the signal path between any two stations on the network.  When four Repeater
    >Sets are used in any signal path, the path shall include two link segemnts.
							     ^
                                                         at least

All 5 segments could be link segments.  Also, the FOIRL segments should
be no more than 500 m.  If you use 3 repeaters, the two FOIRL segments
can be up to 1 km.  (From 13.3 of IEEE 802.3i.)

Pat Thaler
From: rsmith@vms.macc.wisc.edu (Rusty Smith, MACC)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: LANbridge 100's not passing arp requests
Date: 16 Apr 92 13:32:46 GMT
Distribution: usa
Organization: University of Wisconsin Academic Computing Center

In article <1992Apr16.000043.2236@bronze.ucs.indiana.edu>, ssw@bronze.ucs.indiana.edu (steven wallace) writes...

>In <1992Apr15.153505.1@wums.wustl.edu> brenner_t@wums.wustl.edu writes:
> 
>>I'm having a problem with LANbridge 100's not passing arp requests.  If the
>>bridge is reset it starts working again. This problem seems to have
>>gotten worse lately.  We have 250 nodes on 7 baseband ethernet segments
>>connected with LANbridge 100's.  It is not related to traffic or distance
>>problems.  When this occurs, I try to ping a node across a bridge, the arp
>>request gets sent out (I can see it with a network analyzer) but does not
>>get across the bridge.  When I reset the bridge, the arp request gets
> 
>Some versions of the DEC's lanbridge software contain a bug that allows them
>to "learn" the broadcast address. Some network devices, lord knows why, will
>send an ethernet packet with the SOURCE address being broadcast. The
>lanbridge learns this then stops forwarding all broadcasts (ARPs are
>broadcasts).  Contact your local DEC rep for new code.

If you have RBMS you can query the bridge. If it is version 2.0 then 
you need a chipset from DEC to upgrade to 2.1. We did this about 3
years ago. The old chips are 293E5 and 294E5, the new ones are 332E5
and 333E5. Also if you have an analyzer look for the broadcast as
a source on a misconfigured computer. Usually a p.c. that someone
can't figure out why it won't work and isn't on the network when
you look for it. Hope this helps.

Rusty Smith			Internet:  rsmith@vms.macc.wisc.edu
MACC Data Communications	Bitnet:    rsmith@wiscmacc
1210 W. Dayton St. Rm. B263     Univ. of Wisconsin @ Madison
Madison WI 53706                (608) 263-6307
From: tanemeth@economics.adelaide.edu.au
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Repeaters
Date: 10 Apr 92 04:38:13 GMT
Organization: Economics, University of Adelaide

In article whinery@nancy.uhcc.Hawaii.Edu (Alan Whinery) writes:
>...
> Thin coax is 1) a much better signal path than twisted pair, able to
> go almost twice as far as an ethernet plus 2) you can put 29 stations
> on a thin coax segment, vs 1 on a twisted pair segment. Thus, coax,
> though slightly more expensive is much more valuable once installed.
>
We are going to have to differ on that one!  The only place for thin ethernet
cable is inside the wiring closet, to connect hubs together.  Thick cable has
no place anywhere (well, newly installed, anyway).  Anyone who is installing
thin ethernet cable now is probably VERY misguided.

> If you reduce the number of 10BaseT hubs to MAC conversion points,
> ideally you can have all of your stations no more than one repeater
> away from the backbone, upon which you can place a server.
>
The backbone is no place for a server!  NO WAY!  By definition, the backbone is
what connects your individual networks together, and should only ever be
accessible via a router.

> Routine tinkertoy cascading of hubs is bad design, it will eventually lead
> to too many repeaters, and there is virtually no excuse for it.
>
However, PLANNED cascading of hubs is very useful and desirable.  If you have
a structured wiring scheme, it is almost mandatory to do it this way.  There is
nothing wrong with this, as long as the 10-B-T rules (and manufacturer's specs)
are complied with.

> If you are reduced to calculating repeater delays to judge whether
> you've got too many, you made some fundamental mistakes in the initial
> design of the network. There are standards so that you can tell what will
> work without trying to fudge it all of the time.
>
You are assuming that somebody designed the thing.  This is often not the case.
Usually, you inherit something, and have to keep it going.  Also, standards
have been known to change during the life of a network!

> (other garbage deleted)
Please don't bother to reply...

Tom Nemeth
Newsgroups: comp.dcom.lans.ethernet,comp.sys.sun.misc
Subject: Re: Connecting two machines without an "Ether"
From: hilbig_t@qis.dofasco.ca
Date: 9 Apr 92 08:52:31 GMT
Organization: Dofasco Inc, Hamilton, Ont. Can.
Nntp-Posting-User: hilbig_t

In article <1992Apr05.165348.26168@donau.et.tudelft.nl>, thomas@duteca2.et.tudelft.nl (Thomas Okken) writes:
> I want to connect two machines with thick-ethernet ports. Can I save the
> expense of two transponders (or whatever those little expensive boxes are
> called), and use some kind of straight-through cable? With some passive
> components perhaps?
> I suppose this should be possible, but I don't know anything about the
> pin-outs and electrical specs of the DB-15 ethernet port. If anyone has done
> this before, I'd love to hear about it.

Sorry, you can't directly connect the two AUI's together (that's why they 
transceiver cables have one male end and one female end.  One of the jobs
of the transceiver (that's what it's called) is to detect and report
collisions.  Without it one host would not know if it was colliding with
the other host.

Good news.  Buy two cheap 10BaseT/AUI transceivers ($100 each) and use a
10BaseT cross-over cable to connect the two hosts.  This is a fairly
low cost sollution and will allow you to use move to a small 10BaseT hub
if you ever buy another computer.  Depending on the distance between your
two machines, a transceiver cable would have costed up to $100, so the
10BaseT solution may not be that much more after all.



Thomas Hilbig,
Systems Engineer,			Address:    1330 Burlington St East,
Information and Automation Systems,		    Hamilton, Ontario
Dofasco Inc.                            	    Canada   L8N 3J5
hilbig_t@qis.dofasco.ca                 Telephone:  (416) 544-3761
From: joltes@husc4.harvard.edu (Richard Joltes)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Information on LAVC wanted..
Date: 13 Apr 92 14:05:39 GMT
Organization: Harvard University Science Center

moshek@FibHaifa.com writes:
 
>I'm looking for information regarding LAVC protocol.
>The information I'm looking for is:
>
>- Use of this protocol over Bridges, (Time-Out trouble-shootings)
>- On frame structure
>- Performance, and others..
>
>Thanks in advance.
>
>--- Moshe K.

If you're referring to DEC's LAVc (Local Area VAXcluster) implementation, it 
uses DEC's Clustering datagrams inside standard Ethernet packets, if I'm not
mistaken (and I know someone will correct me if I am!).  You should check out
DEC's _Guide to VAXclusters_ for additional information, and the _Guide to
DECnet_ would probably help as well.

I don't believe it's recommended to run a LAVc across a bridge.

--------------------------------------------------------------------------------
Dick Joltes						joltes@husc.harvard.edu
Hardware & Networking Manager, Computer Services 	joltes@husc.bitnet 
Harvard University Science Center

"Mind you, not as bad as the night Archie Pettigrew ate some
sheep's testicles for a bet...God, that bloody sheep kicked him..."
From: brenner_t@wums.wustl.edu
Newsgroups: comp.dcom.lans.ethernet
Subject: LANbridge 100's not passing arp requests
Date: 15 Apr 92 15:35:05 GMT
Organization: Washington University School of Medicine

I'm having a problem with LANbridge 100's not passing arp requests.  If the
bridge is reset it starts working again. This problem seems to have
gotten worse lately.  We have 250 nodes on 7 baseband ethernet segments
connected with LANbridge 100's.  It is not related to traffic or distance
problems.  When this occurs, I try to ping a node across a bridge, the arp
request gets sent out (I can see it with a network analyzer) but does not
get across the bridge.  When I reset the bridge, the arp request gets
across.  This fix (resetting all the bridges) seems to have lasted for a
couple weeks until the problem reoccured.  Currently I'm pinging a few
nodes on each seperate bridged segment every hour so that I can identify
the problem as soon as it happens and reset the bridges, but I'm looking
for a more permanent solution.  The people who connect the campus subnets
have seen the problem before but can offer no permanent solutions.  We are
currently adding about 20 nodes/ month and will be adding a couple more
bridges to segment off departments from our main baseband segment.

Thanks for your help,

Tim Brenner
Network Manager
Washington University Med School (WUMS) Computing Facility
brenner_t@wums.wustl.edu
Newsgroups: comp.dcom.lans.ethernet
From: ersicrko@el6.er.ele.tue.nl
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Ethernet questions
Date: 13 Apr 92 12:25:17 GMT
Organization: Eindhoven University of Technology, , The Netherlands.

In article <19089@suned1.Nswses.Navy.MIL>, lev@slced1.nswses.navy.mil (Lloyd E Vancil) writes:
> 
> Hello world!
> I am interested in getting more of an understanding of the way our network 
> works.  We have what amounts to a small MAN.  One of our chief server nodes is
> nearly 2km from the rest of the net and we have several clients that are
> more than 10km away over t1 links.  We have large numbers of TCPIP, LAT and
> PCNFS users.  We have seen several serious problems arise and we have
> had more or less success in fixing them.  Testing and monitoring seems to show
> a dual packetsize modality during our worst problem times, but to really
> understand what I'm seeing I need more information on ethernet.  Is there
> a recommended BASIC text on ethernet?

Howdy!

To get to know something is to know what you want to know. At this moment I
am trying to get to know as much as possible of the performance of an ethernet
network. By use of previous research of the Delft University of 
Technology I am capable of 'seeing' what is happening on the 
ethernet network. Once this is possible one is able to redefine 
what you want to know.

Simple ethernet terms:
- ethernet : 10 Mbps communication channel
- Manchester encoding technique
- CSMA/CD

Packet Ethernet:
- 8 bytes preamble
- 6 bytes destination, lsb of first byte indicates multicast mode 
( e.g. ab.XX.XX.XX.XX.XX instead of aa.XX.XX.XX.XX.XX )
- 6 bytes source
- 2 byte type def.
- 46-1500 bytes data
- 4 bytes CRC
- bits within byte transmitted left to right

recommended reading:
-> Computer Networks, Tannenbaum
-> LAN troubleshooting handbook, Miller
Digital's networks: An architec...., Digital
The local network handbook, Ungaro
The localnetter designer's handbook

etc, etc, etc, etc, etc,

Lectori Saluto
Rob Kouwenberg
ersicrko@er.ele.tue.nl.

PS try beholder, gobbler,spectre, etc : FTP dutepp0.et.tudelft.nl.
-----------------------------------------------------

'In mari meri miri mori muri necesse est.'
Dutch: 'In een zee van overvloedig veel wijn is het voor een muis 
noodzakelijk te sterven..'
English: God knows what!
Newsgroups: comp.dcom.lans.ethernet
From: ssw@bronze.ucs.indiana.edu (steven wallace)
Subject: Re: LANbridge 100's not passing arp requests
Organization: Indiana University
Date: Thu, 16 Apr 92 00:00:43 GMT

In <1992Apr15.153505.1@wums.wustl.edu> brenner_t@wums.wustl.edu writes:

>I'm having a problem with LANbridge 100's not passing arp requests.  If the
>bridge is reset it starts working again. This problem seems to have
>gotten worse lately.  We have 250 nodes on 7 baseband ethernet segments
>connected with LANbridge 100's.  It is not related to traffic or distance
>problems.  When this occurs, I try to ping a node across a bridge, the arp
>request gets sent out (I can see it with a network analyzer) but does not
>get across the bridge.  When I reset the bridge, the arp request gets

Some versions of the DEC's lanbridge software contain a bug that allows them
to "learn" the broadcast address. Some network devices, lord knows why, will
send an ethernet packet with the SOURCE address being broadcast. The
lanbridge learns this then stops forwarding all broadcasts (ARPs are
broadcasts).  Contact your local DEC rep for new code.


-- 
====================================================================
Steven Wallace, N9LKJ         |  wallaces@ucs.indiana.edu (internet)
Manager Network Operations    |  wallaces@iubacs          (bitnet)
Indiana University            |  (812) 855 - 0960         (voice)
From: drake@drake.almaden.ibm.com (Sam Drake)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Ethernet to Token-ring bridge
Keywords: Ethernet Token ring
Date: 10 Apr 92 05:29:40 GMT
Distribution: na
Organization: IBM Almaden Research Center

In article <1992Apr10.002432.17098@cbnewsl.cb.att.com> vass@cbnewsl.cb.att.com (srinivas.vasantharajan) writes:
>       Can anybody suggest a good Token-ring to Ethernet bridge?. 

IBM sells one .. the 8209.  


Sam Drake / IBM Almaden Research Center 
Internet:  drake@almaden.ibm.com    BITNET:  DRAKE at ALMADEN
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Repeaters
From: nason@pa881a.inland.com
Date: 13 Apr 92 12:12:15 CDT
Organization: Inland Steel Company, East Chicago, IN
Nntp-Posting-User: narayan

In article <1992Apr10.140813.1@economics.adelaide.edu.au>, tanemeth@economics.adelaide.edu.au writes:
> In article whinery@nancy.uhcc.Hawaii.Edu (Alan Whinery) writes:
>>...
>> Thin coax is 1) a much better signal path than twisted pair, able to
>> go almost twice as far as an ethernet plus 2) you can put 29 stations
>> on a thin coax segment, vs 1 on a twisted pair segment. Thus, coax,
>> though slightly more expensive is much more valuable once installed.
>>
> We are going to have to differ on that one!  The only place for thin ethernet
> cable is inside the wiring closet, to connect hubs together.  Thick cable has
> no place anywhere (well, newly installed, anyway).  Anyone who is installing
> thin ethernet cable now is probably VERY misguided.
> 
I don't think so.  Twisted pair provides little noise immunity, and is always
the worst choice (cheap).  Thin wire is second best, thick wire is the best. 
If you want a high quality network installation that is guaranteed to work
without those little irritants that seem to always pop up, you will use coax.  

We install networks in a high noise environment, thick wire is the ONLY choice. 
So to say that thick-wire has no use anywhere is presumptutous, short sighted
and grossly mis-informed.  

Using twisted-pair, zip cord or any other piece of junk picked up to throw
together a network to save a nickle, will in the end bite you back.  

You get what you pay for!!!

John M. Nason
Hardware Engineer, Inland Steel Company.



>> If you reduce the number of 10BaseT hubs to MAC conversion points,
>> ideally you can have all of your stations no more than one repeater
>> away from the backbone, upon which you can place a server.
>>
> The backbone is no place for a server!  NO WAY!  By definition, the backbone is
> what connects your individual networks together, and should only ever be
> accessible via a router.
> 
>> Routine tinkertoy cascading of hubs is bad design, it will eventually lead
>> to too many repeaters, and there is virtually no excuse for it.
>>
> However, PLANNED cascading of hubs is very useful and desirable.  If you have
> a structured wiring scheme, it is almost mandatory to do it this way.  There is
> nothing wrong with this, as long as the 10-B-T rules (and manufacturer's specs)
> are complied with.
> 
>> If you are reduced to calculating repeater delays to judge whether
>> you've got too many, you made some fundamental mistakes in the initial
>> design of the network. There are standards so that you can tell what will
>> work without trying to fudge it all of the time.
>>
> You are assuming that somebody designed the thing.  This is often not the case.
> Usually, you inherit something, and have to keep it going.  Also, standards
> have been known to change during the life of a network!
> 
>> (other garbage deleted)
> Please don't bother to reply...
> 
> Tom Nemeth