HDTenEightyP/NetNews huggingface dataset:
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Subject: Re: Ethernet Analyzer/testing devices/software
Organization: University of Strathclyde
Date: Fri, 28 Aug 1992 09:48:47 GMT

In article <aycn82=@quantum.on.ca>, aboyd@quantum.on.ca (Andrew Boyd) writes:
|> In article <1992Aug27.090801.11847@ccsun.strath.ac.uk> 
|> craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
|> >the PC bus is far too slow to transfer packets to main memory at 10Mbit/s
|> 
|> um, this is not quite correct.  Even using the lowly 8mhz bus, a 16-bit 
|> ISA card can keep up with a 10Mbit/sec throughput.


The raw bit rate is certainly fast enough to cope with 10Mbit/s, but don't
forget that the PC has to access other peripherals such as the video card
and hard disk controller over the same bus, which takes large
chunks out of the available bus bandwidth. In a previous job, 
I was the engineer who designed the hardware for the Spider 
Analyser (or TTC Netlens as it is now) and it just 
isn't possible to do all the things that need to be done on the bus and transfer 
packets at full rate of Ethernet across the bus. The achievable transfer rate
is however quite adequate for all but the most unusual of circumstances.

 
Dave Stevenson 				D.W.Stevenson@strath.ac.uk
Computer Centre Communications		Tel : 041-552 4400 x3461
University of Strathclyde
Glasgow, U.K. 
Newsgroups: comp.dcom.lans.ethernet
From: ccewch@nuscc.nus.sg (Wong Chee Heng)
Subject: Re: what is SQE  (DUMB QUESTION!)
Organization: National University of Singapore
Date: Wed, 2 Sep 1992 09:17:38 GMT

nason@pa881a.inland.com writes:
: circuitry.  Each MAU under 802.3 must be have a provision to manually turn off
: the SQE test.  This is done for a variety of reasons.  If the MAU is connected
: to a repeater, or if the MAU is connected to a Ethernet V2 device.  
: 
: One of the differences between 802.3 and ethernet V2 is the collision detect
:circuitry test.  Under Ethernet it is called the Collsion Presence Test.  Under
: 802.3 it is called the SQE test.  In your appliction, you want SQE test turned
: on.    
: 
Why SQE must be turned off when connecting to Ethernet V2 device? If the problem
is due to some incompatibilties of the two standards, shouldn't there be a
special MAU for Ethernet v2 device that allow SQE enabled? SQE seems to be
a good feature
From: craa85@ccsun.strath.ac.uk ( D.W.Stevenson)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Ethernet Analyzer/testing devices/software
Date: 27 Aug 92 09:08:01 GMT
Organization: University of Strathclyde

In article <BtLJq0.D71@world.std.com>, aep@world.std.com (Andrew E Page) writes:
|> 
|>    What is currently available for hardware that would allow you to
|> test hardware/protocols for ethernet hardware?  

Low cost PC based analysers are available which use a standard PC card in a PC 
to capture packets on the network, and the main PC processor is used to decode
the upper layers of the packets. This is limited in it's performance and may miss
packets when the network is heavily loaded (the card only has very limited
buffering space for captured packets and the PC bus is far too slow to transfer 
packets to main memory at 10Mbit/s).

If you absolutely must not lose packets, look at the HP range of analysers, which
are purposely designed pieces of test equipment but are complex and expensive. 

A compromise is a portable PC with a card which is purposely designed for
LAN monitoring, with large amounts of buffering space and an on board processor
to take care of a lot of the work of capturing packets. These will cope with
all but the most heavily loaded network and at a more reasonable cost. 
Examples are the TTC Netlens or the Network General Sniffer.

-- 
Dave Stevenson 				d.w.stevenson@uk.ac.strath
Computer Centre				Tel : 041-552 4400 x3461
University of Strathclyde
Glasgow, U.K.
From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: what is SQE  (DUMB QUESTION!) :  No such thing...
Date: 2 Sep 92 18:11:50 GMT
Reply-To: lstowell@pyrnova.pyramid.com (Lon Stowell)
Organization: Pyramid Technology Corp., Mountain View, CA
Originator: daemon@sword.eng.pyramid.com

In article <1992Sep2.091738.4218@nuscc.nus.sg> ccewch@nuscc.nus.sg (Wong Chee Heng) writes:
>: 
>Why SQE must be turned off when connecting to Ethernet V2 device? If the problem
>is due to some incompatibilties of the two standards, shouldn't there be a
>special MAU for Ethernet v2 device that allow SQE enabled? SQE seems to be
>a good feature

   Its cheaper to build a single model and include a jumper/switch
   to disable SQE for those interfaces still unable to tolerate it.
   Otherwise you'd have to build two separate models.  And for the
   installer, you can always try just flipping the switch if it
   doesn't work.  (some folks don't honestly know whether their
   particular adapter is V1, V2, V1.5, or real 802.3...and neither
   do a lot of datasheets....)   


   On the same thread, do V1 or V2 ethernet DTE's tend to get
   annoyed when they get their XMIT data echoed back on receive?


Newsgroups: comp.dcom.lans.ethernet
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Ethernet Analyzer/testing devices/software
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 29 Aug 1992 08:41:47 GMT

craa85@ccsun.strath.ac.uk ( D.W.Stevenson) writes:
+---------------
| it just isn't possible to do all the things that need to be done on the
| bus and transfer packets at full rate of Ethernet across the bus.
+---------------

This will come as a surprise to AMD, whose LANCE-based "half-card" hangs
the LANCE right on the bus (in "1st-party DMA" mode) without any buffering.
The bus *has* to run fast enough, or the LANCE would drop data.

And it should be fast enough. Even with one-wait-state memory, an 8 Mhz
ISA bus has 5.33 MB/s of bandwidth. A single Ethernet *should* consume
less than 1/4 of that.

(Yes, I know, what with descriptor accesses and a slow bus interface and
slow firmware, the LANCE consumes up to 45% of whatever bus you hang it on.
But that's worst case with continuous reception or transmission.)


-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.ethernet,comp.dcom.lans.misc,comp.protocols.novell
From: aboyd@quantum.on.ca (Andrew Boyd)
Subject: Re: 802.3 Non-Compliance (?)
Date: Mon, 31 Aug 92 13:45:27 GMT
Organization: Quantum Software Systems

In article <1992Aug28.194558.4752@iplmail.orl.mmc.com> more@tcc.orl.mmc.com 
writes:
>In this meeting (which unfortunately I wasn't in), the vendor made the statement
>that Netware Servers violate the 802.3. His statement was that when a netware
>server detects a collision, that rather than following the random backoff, 
>in the Ethernet world, the Netware server immediately attempts to retransmit
>the collided packet(after sending the jam sequence).

I'd be interested to know if your netware server is using one of the
following cards:

	WD (now SMC) 8003/8013
	3Com 503
	novell 1000/2000

If so, then the network interface controller (national semiconductor 8390)
does the collision backoff, not the driver software.  See the description 
of the Transmit Configuration Register in the 8390 data sheet.  The only
option is to _increase_ the backoff (ie be nice).

I think the salesman is, um, suffering from a credibility problem.  If I 
were you I would contact national and novell for more information.

----
#include <std.disclaimer>

Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.misc
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: 802.3 Non-Compliance (?)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Sat, 29 Aug 1992 17:06:20 GMT

In article <1992Aug28.174914.58494@cc.usu.edu>, jrd@cc.usu.edu writes:
> ...
> 	So far as I am aware NW board drivers do NOT reprogram the board
> to modify the exponential backoff algorithm. The vendors usually accused
> of this are Sun and or SGI; proof is not in my hands...

I should say not!

I will not presume to say what our esteemed solar friends do, except to
remind readers of Van Jacobson's published measurements of Sun's, where
he found at worst slowness and never violation of the back-to-back rules.

Silicon Graphics has never, ever violated the Ethernet exponential
backoff rules.  (Well, perhaps some chip failed somewhere, but I doubt
that ever happened and have never heard of it.)  First, until recent
years Silicon Graphics only used the AMD 7990 LANCE, and you cannot
change the LANCE's back-off without opening the package and attacking
the silicon with a laser or something.  There are simply no hooks in
the interface to the chip to change the backoff parameters even if you
are stupid enough to want to.  Second, we have recently used SEEQ
8003's and derivatives.  We have never changed the exponential back off
for the 8003 based products.  Never.  We have played with the deferral
rules in the lab, but only to increase back-offs, never to reduce them.

Changing the exponential backoff would be stupid, unless think you can
modify all of the stations on the wire.  Silicon Graphics is still far
too modest imagine that any ethernet could be considered a proprietary
wire.

Varitions of the statement about Sun is old.  I do not know if it was
ever true.  This is the first instance I recall when the charge has been
applied to Silicon Graphics.  Please be careful when you repeat such
calumnies.  Such innocent mentioning as yours is what keeps the
scumbags from the slow vendors repeating them.


Vernon Schryver,
Silicon Graphics Computer Systems, Inc.
2011 N. Shoreline Boulevard.
Mountain View, California 94043.


(Yeah, you can take this as an official statement.  If you need it
on paper, please let me know.)

vjs@sgi.com
From: seifert@netcom.com (Rich Seifert)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Nat'l Semiconductor's Ethernet chips
Date: 28 Aug 92 23:50:21 GMT
Distribution: na
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

> On the same board, I also plan to
> use isolation transformers and filters from Pulse Engineering (PE-65727
> and PE-65442) and a +5V/-9V DC/DC converter from either Reliability
> (2VP5U9 or 2VI5U9) or KSL Microdevices (05M09).  Does anyone have any
> comments about those vendors?
>

I have had nothing but trouble-free operation with the Pulse Engineering
product line. I recommend them highly.
 
-- 
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: jkt@SED.Provo.Novell.COM (Jack Thomasson)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: 802.3 Non-Compliance (summary and lesson)
Date: 3 Sep 92 20:48:56 GMT
	<1309@ncrclm.ClemsonSC.NCR.COM>
Organization: Novell, Inc.

the whole issue of novell's "non-compliance" is based on a historical
accident.  ipx was established using a draft of the 802.3 standard.
unfortunately (as will happen), the standard changed to require 802.2
headers as well.  ipx already uses the length field correctly; but
does not implement dsap and ssap when configured for ethernet_802.3,
which is the default for v3.11 and less.

a previous poster mentioned the overlap of ipx checksum (typically
0xffff) over dsap and ssap which kills some architectures.  i think
most (all?) of the affected architectures handle things much better
now.  at least, i haven't heard of any problems with machines running
current software/os versions lately.

other options:

v2.1 and v2.2 can be configured (using econfig) for ethernet_ii
frames.  this uses a sap in place of the length field.

a previous poster mentioned that v2.2 will do ethernet_802.2 which is
correct; but for appletalk (which actually uses ethernet_snap) not
ipx.  there may be a third-party solution to allow ipx on 802.2 for
v2.2.

odi-based drivers (v3.11+ and workstation) can be configured for
ethernet_802.3 (draft standard mentioned above, also know as "raw"),
ethernet_ii, ethernet_802.2 (fully compliant and a good choice, hint,
hint), and ethernet_snap (ethernet_802.2 + snap extension).
--
---------------------------------------------------------------------
Jack Thomasson                   :{)}               (the bearded one)
Internet:Jack_Thomasson@SED.Provo.Novell.COM           MHS:JKT@NOVELL
Novell, Inc. /  MS E-23-2 /  122 East 1700 South /   Provo, UT  84606
Phone: (800)453-1267x7604 | (801)429-7604          FAX: (801)429-5511
"WARNING: the comments do not necessarily reflect the implementation"
Newsgroups: comp.dcom.lans.ethernet
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Subject: Re: Traffic Visualization tool?
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 1 Sep 1992 06:36:02 GMT

daves@james.carleton.ca (Dave Sutherland) writes:
+---------------
| bwolfe@rad.rpslmc.edu (Brian A. Wolfe) writes:
| >For example, one way to show this graphically might be to 
| >depict the network map (I need to show about 50 hosts at once)
| >with icons representing the hosts, and then draw lines between the 
| >hosts in real-time that get thicker (and thinner) based on the 
| >volume of traffic between them. 
| 
| I believe Silicon Graphics has this exact approach to network traffic
| visualization. 
+---------------

Correct. The product is called "NetVisualyzer" (Registered Trademark).


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com
Silicon Graphics, Inc.		(415)390-1673
2011 N. Shoreline Blvd.
Mountain View, CA  94043
From: jim@mivax.mc.duke.edu (James D Dryfoos - Systems)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Ethernet CRC/Alignment errors
Keywords: ethernet CRC errors
Date: 24 Aug 92 01:49:00 GMT
Organization: Duke University Medical Center
News-Software: VAX/VMS VNEWS 1.41

In article <1992Aug21.041709.3208@usage.csd.unsw.OZ.AU>, pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) writes...
>I have a piece of the campus ethernet that seems to have an excessive
>number of CRC/Alignment errors. I have a Novell LANalyzer, and over an
>hour or so reports no late collisions, no illegal long/short packets,
>but a rate of CRC/Alignemtn errors sometimes up to 1 per 1000 packets.
>These errors become more numerous when the traffic exceeds about 7% of
>the ethernet bandwidth. To help in tracking down the source, could
>someone tell me whether these errors are propagated through repeaters -
>if not, that narrows the source to somewhere on this segment, which
>would help a lot!. Also, are they the sort of thing to start panicing
>about? Is 1 per 1000 or 1 per 5000 excessive at 10% utilyzation?

If the packets are under 64 bytes long, they are most likely the result
of collisions.  It is possible for a collision to occur on the net that
would not show up as collision, but as a bad CRC/alignment/short.
For example, a collision occuring on the other side of a fiber link would not
increment your collision counter, therefore the packet (which should be less
than 64 bytes) would increment the bad crc and short counters and possibly the
alignment counter.  I am not familiar with the Novell's Lanalyzer, but this
is what I see using Wandel&Golterman's DA30.  If I connect it to a FiberOptic
Tranceiver I never see collisions unless I try to transmit.

-Jim

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
*  James Dryfoos  -- Medical Informatics - Duke University Medical Center     *
*                                                                             * 
*  VMS Systems Programmer -- Postmaster - Duke Electronic Medical Post Office * 
*  dryfo001@mc.duke.edu - dryfo001@dukemc.bitnet                              *
*  Box 2914 Durham NC, 27710 USA - EARTH (919) 684-6421
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
* James Dryfoos  -- Medical Informatics - Duke University Medical Center      *
* VMS Systems Programmer -- Postmaster - Duke Electronic Medical Post Office  * 
*                                                                             * 
* INTERnet:  DRYFO001@MC.DUKE.EDU          BITnet: DRYFO001@DUKEMC            *
* INTERnet POSTMASTER: DMPM@MC.DUKE.EDU    BITnet POSTMASTER: DMPM@DUKEMC     *
* Concert Net DECnet:  MEDINF::JIM or 3073::JIM                               *
* Box 2914 DUMC Durham, NC  27710 USA, EARTH --  (919) 684-6421/fax 684-8675  *
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Xref: sparky comp.dcom.lans.ethernet:1792 comp.dcom.lans.fddi:589
From: dwm@roanoke.fibercom.com (Dave Minnich)
Newsgroups: comp.dcom.lans.ethernet,comp.dcom.lans.fddi
Subject: Cable plant for Ethernet/FDDI over twisted pair
Date: 1 Sep 92 17:41:23 GMT

Hey folks,

We are about to rewire one of our labs and hope to install (among other things)
a twisted-pair plant which would work for either Ethernet or FDDI over copper.
The topology is not an issue, since everything will run to a patch panel -- we
should be able to achieve whichever logical topology we need for a particular
application.  Has anyone had any experiences which would be helpful for us to
know going into this project?  Recommendations?  Horror stories?  Thanks,

--dave

-- 
David W. Minnich               INTERNET: dwm@fibercom.com
FiberCom, Inc.                 UUCP: ...!uunet!fibercom!dwm   
P.O. Box 11966                 PHONE: (703) 342-6700, (800) 423-1183 ext. 347
Roanoke, VA  24022-1966        FAX: (703) 342-5961
From: edwards@world.std.com (Jonathan Edwards)
Subject: 10Base-2 connection limits
Organization: IntraNet, Inc.
Date: Fri, 4 Sep 1992 17:38:30 GMT

I want to set up a small 10Base-2 network, and am thinking of running the
coax as homeruns to the wiring panel for better fault tolerance.
My question is whether I can avoid useing a hub, and just tie them together
with a sequence of T-connectors? 
Is there a specified limit to how far I can take this?

BTW, I am looking at 10Base-2 rather than 10Base-T because this is a home
installation, and several people have warned me that 10Base-T may generate
lots of RFI. Also, if I can avoid buying hubs, it is a lot cheaper.
Thanks,



-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: what is SQE  (DUMB QUESTION!)
From: nason@pa881a.inland.com
Date: 1 Sep 92 13:31:12 CDT
Organization: Inland Steel Company, East Chicago, IN
Nntp-Posting-User: teffeau

In article <44G6HJV@netmbx.netmbx.de>, weis@netmbx.netmbx.de (Dietmar Weis) writes:

> (...stuff deleted)
> SQE should be turned off for a transceiver connected to a *Thinwire* repeater.
> I don't know for a Standard Ethernet repeater.

Transceivers connected to an 802.3 repeater (any) should have its SQE-Test
turned off.  

> The reason is, that the SQE-Signal, which tests the Collision Detect

Not trying to nitpick but the SQE-Signal is the collsion detect signal.  It is
the signal that shows up on the CD lines of the AUI if there is a collision or
after the *successful* transmission of a packet by a DTE. The DTE knows to
expect an SQE signal after it successfully sends a packet and does not confuse
it with a real collision (SQE-Test).

> functionality in the Ethernet Controller, will be transmitted via the
> Thinwire repeater to the whole Thinwire segment, which would **dramatically**
> slow down. On a 15-pin AUI-Cable to an Ethernet controller you have seperate
> Collision Detect lines, which you don't have on a Thinwire. So the SQE-Test
> sends it's test Collision Detect signals right onto the segment.
> The attached stations think there are real collisions.

so true

My opinions are my own and not those of my company.  
Free advice is worth its cost.  
--- John M. Nason - NA9U ---|--------------------------------------------|
Inland Steel Company        |  -- nason@pa881a.inland.com                |
Process Automation MS 2-464 |  -- Fax:   219-399-7856                    |
3210 Watling Street         |  -- Voice: 219-399-2450                    |
East Chicago IN 46312       |"Ya can't shoot em till they stop sparklin" |
----------------------------|--------------------------------------------|
Newsgroups: comp.dcom.lans.ethernet
From: pim@fct.unl.pt (Joao Paulo Pimentao)
Subject: ThickWire repeaters...
Organization: Universidade Nova de Lisboa -- Lisbon, Portugal
Date: Fri, 4 Sep 1992 14:08:23 GMT


We are considering using thick wire ethernet to connect two buildins
on our campus. Later on we are going to replace it by fiber optics;
but the easiest way and the fastest for us presently is to create a
thick wire connection.
Our thick wire cable may be near the maximum lenght that I believe is
1 km.
Could you please help me sugesting the best way to extend it.
I think I can use repeaters to enlarge it with another km or so. Is
this true? Could you point me to some repeaters?

Thanks in advance

		Pimentao
--
Joao Paulo B. Pimentao            | BITNET/Internet: pim@fct.unl.pt
Universidade Nova de Lisboa	  |            UUCP: pim@unl.uucp
FCT - Dpto. de Informatica        | Fax:   (+351) (1) 295-5641/4461
2825 Monte Caparica, PORTUGAL     | Phone: (+351) (1) 295-4464 ext.1407
From: seifert@netcom.com (Rich Seifert)
Newsgroups: comp.dcom.lans.ethernet
Subject: Re: Advice needed on Bridges/Routers
Date: 29 Aug 92 00:04:29 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article <1992Aug21.220426.5765@megatek.uucp>, randy@ninja.megatek.uucp (Randy Davis) writes:
> 
>   I would like to get some recommendations on the best bridge or router
> to split our particular network configuration...
> 
>   We have about 120 Sun workstations, a small amount (<20) of other
> assorted compatible workstations, and a number of large servers on one
> physical section of thick-wire ethernet in a R&D environment doing lots
> of software development (and the resultant large "makes"), an amount of
> CAD work, and the usual other assortment of duties.
> 
>   The next step with the network is to split/segment it.  Although we are
> not yet seeing problems with the arrangement, I feel it is just a matter of
> time with our present growth rate -  at times the ethernet is approaching
> 40-50% utilization, with the inherent problems of delays for machines to
> find a "quiet" time to transmit, and the resultant collisions.
> 
>   I would like to solicit advice concerning the best way to split the
> network and why.  I've done a bit of research already on my own, and am
> actually tending more toward just splitting the network into functional
> groups and bridging between the segments.  However, with the cost of bridges
> and routers approaching each other, I was tending toward getting a couple
> of routers that can also do simple bridging with little overhead.
> 

Without getting into the bridge vs. router debate (AGAIN!), there are
some simple recommendations.

1: For sure, when you segment your network, do it according to logical
connectivity. Put the workstations on the same segment as the server
with which most of the traffic is directed. This will ease the 
internetworking burden of any device you choose to use. A good
rule of thumb is to segment such that at least 80% of the network 
traffic is local (if possible).

2: If all of the devices are within the same organization (same
management, same network numbers, same building, etc.) bridging
may make the most sense. The administration required is approximately
zero, the performance is high, and the cost is low.

3: If you wish to organizationally separate the segments (different
address assignment, etc.) use a router.

4: The number of protocols in use will affect your decision also. It
will be easier to route if the number of network layer protocols is
low (preferably one). If there are lots of protocols (e.g., IPX
IP, DECnet, etc.) bridging may be easiest.

Hope this helps.

-- 
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"
Newsgroups: comp.dcom.lans.ethernet