This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: Acceptable number of collisions?
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Thu, 27 May 1999 00:10:59 -0400
Paul Mezzanini <paul.mezzanini@saintleo.edu> wrote:
> All a hub does is provide a means to connect a bunch of wires together
> so they 'look' like one. (ya know what I mean, Tx to Rx yada yada yada)
>
> Of course I could be wrong, but I don't think I am. :)
Eh, no and yes...
Normally moving from 10Base2 to 10BaseT results in a
quadrupling of throughput...
This is because the TX/RX pairs are on separate lines...
With 10Base2 everything is broadcast over one wire and is
much slower...
Hubs also don't merely connect a bunch of wires
together... IBM Token ring hubs DO, ethernet somehow picked
up the Tokenring/Arcnet nomenclature which has resulted in a
lot of confusion...
Ethernet hubs are a misnomer... they are actually called
"concentrators" or "signal conditioners" since they receive
the signal and "clean it up" again...
Switches go one step further by isolating pathways between
connected cable segments, since there is less collision
retransmissions and often (in better switches) machines can
communicate with counterparts on dissimilar segments AT THE
SAME TIME, the apparent xfer rate improves...
In actuality two machines on a switch are no faster than two
machines on a hub... add more machines and the situation
changes dramatically if they are all talking to "other"
devices...
If they are all hitting the same server at the same time,
however, performance is not greatly improved...
===
Subject: Re: Acceptable number of collisions? (NOT SO!)
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Tue, 1 Jun 1999 18:01:53 -0400
Richard W. Gowen <richard@gowen.net> wrote:
> Jose M. Sanchez <opjose@ex-pressnet.com> wrote:
> > Sorry, NOT SO...
> >
> > The discussion was one about "collisions".
> > In a 10Base2 versus a 10baseT network actual data
> > transfer rates are unaffected... that is you do get a
> > maximum of 10megabits UNIDIRECTIONALLY going from point
> > to point under IDEAL conditions...
> That was my point. The physical protocol CSMA/CD
> establishes a physical collision domain in both 10baseT
> and 10base2. The operations of this domain are the same
> for both media types. See:"Local Area Networks 3rd
> Edition" by John Slone(c) 1997, Auerbach, Boston MA
> > However in a 10base2 network, data is broadcast in a
> > manner identical to standard RF transmissions. That is
> > the center core of the co-ax cable acts as an antenna...
> Excuse me, but I believe that the CSMA/CD protocol uses
> Manchester encoding. How exactly is this stepping of
> electrical voltage on a wire like an antenna?
Manchester encoding on a carrier frequency...
The carrier is "broadcast" to all stations over the
wire. The electrical signals exhibit the same propagation
characteristics as a typical antenna segment...
Hence the need for terminators in a 10base2 wire ...
> Since you want to keep this discussion to collisions why
> are we talking about acknowledgments?
Because it is a factor contributing to the number of
collisions occuring in a 10base2 network.
> design, implementation, and support experience are enough
> to make these statements.
Apparently not, or you'd be fully aware of the difference
data exchange speed between a 10base2 and a 10baseT lan even
though the underlying data speed is the same...
This is not my hearsay, rather what people have experienced
for many years when switching over from 10base2 to
10baseT...
> A token ring MAU (multistation access unit) does no signal
> conditioning and is nothing more then a passive relay.
Hmm. I mentioned this originally and you must have missed this..
> A 10baseT HUB is a bus topology, that is each station's
> CAT3 or better cable is physically wired to a central
> backing.
Not so, -ALL- 10baseT hubs have active conditioning circuitry... again show
me one that doesn't.
The spec mandates this.
> And as you can see, there is no mention of signal
> conditioning in the basic requirements of a hub. If you
> want a real life example of this I can point you to IBM's
> Model 8228 Token-ring MAU. I don't have an example handy
> of an ethernet passive hub.
You are grouping token ring into a discussion of ethernet hubs, then calling
the ethernet requirements
superfluous... Token ring is a different beast altogether...
> However, I can find one if the issue is pressed.
This I'd like to see.
>
> > Yes you can make a cable... and because of signal degradation and
> > propagation problems it will not exceed fifty feet... Give it a try
> > sometime! (Better yet, add the third machine in using nothing but
> > cables... let's see what happens then...)
>
> Works fine with four.
No. The very nature the design precludes this.
> > However for multiple connections the IEEE spec DOES
> > require signal conditioning...
> Where? I have looked at the CSMA/CD specs. I don't see
> what you are referring to. Please enlighten me (RFC
> number please).
When I get a chance I'll find them for you...
> > I can make an ethernet or token-ring hub with none of
> > this. In fact you can simply make a crossover cable
> > (cross tx and rx wires) to connect two 10baseT machines.
> > This is possible because all that is required at the
> > physical layer is a connection of wires between the two
> > machines. The configuration of those wires varies based
> > on topology type (ethernet, token-ring, etc...).
> > ---
> > Irrelevant, we were talking about throughput vis-a-vis
> > collisions on an ethernet lan....
> It is relevant since we are talking about the physical
> layer. The collision domain can be set up logically in a
> smart hub but only needs to be set up physically. That
> was my point.
Eh no, your point was that there was no difference when
moving from 10base2 to 10baseT...
The actual mechanics are not in question...
===
Subject: Re: [OT]Electronics (Was: Acceptable number of collisions?)
From: Tom Burke <tomii@erols.com>
Date: Tue, 01 Jun 1999 18:37:38 -0400
> John Summerfield wrote:
> > This is complete and utter rubbish. Thicker wire gives
> > lower resistance and so allows a greater current flow
> > for a given potential difference. [...] Of course,
> > this is only true for low frequencies and DC[0], due to
> > the skin effect... SCNR, Thomas [0] Ok, for you RF
> > folks 10MHz probably *is* DC... ;-)
OK, OK.... I gotta pipe up on this one - and it will be
long winded :)
All electromagnetic waves propagate at essentially the same
speed (Speed of Light - c - 300000 meters/second) (Although
electrons move considerably slower - imagine a tube full of
marbles). This being the case, there must be something
different going on with the change in speeds... Here it is:
10Mbit ethernet has a data transfer to 10Mbps (Ideally)
during transmit/receive. However, understand that we are
talking about PACKETIZED data here. To send a 100MB file at
10Mbps would ideally take 1.33 minutes. This is an
unacceptable time for one machine to usurp _ALL_ the network
resources.
Instead, we break the file up into packets. Depending on
the protocol, the packets can vary in size (even within the
same protocol). For ease of use, most have single-sized
packets. Now, most forms of ethernet rely on a variation of
the old ALOHA protocol - everything listens and transmits on
the same piece of wire.
Think of a dark room with 10 people in it. If you want to
talk, you listen & make sure that no one else is talking.
Then you pipe up & say whatever you want to say. If you
talk at the same time as someone else, you both hear
something different from what you said. You stop, wait a
random amount of time, then try to say it again.
The problem here, is that you can transmit quite a bit of
data before the guy who's 100 feet away's data reaches you,
so that you know your packet has had a collision (It takes
time for that electromagnetic wav to travel).
Now, there's some variations on this, & I believe 802.3 uses
a marker. If you want to talk, you send a reservation
signal down the wire. If you didn't transmit the marker,
you must wait a minimum amount of time before you can try to
reserve "air time." As the talker, you must wait a minimum
amount of time to ensure that al other stations have
received your reservation. If you hear a reservation that
is not yours (say, two stations at opposite ends tried to
reserve at the same time), both wait a random time & try
again. This maximum time is defined by the length of the
cable allowed to connect the stations. in 10base2, that
length is 200 meters. In 10base5, that distance is 500
meters. This distance is also the limiting factor on the
speed of transfer, as it limits the number of packets that
may be sent from a single host collision free.
Now, it seems that if you boost your signalling speed up to
100Mb from 10Mb, you should be able to move 10x the data (on
a normal network, with multiple hosts all wanting to
talk)... Statistically, this is not the case. In fact, as
I recall, it is actually more than that. It is all based in
nasty statistics & probability - I'll admit, I'm no good at
that stuff :(
As far as the 10/100Mb goes, that is the data transfer rate
(maximum). I doubt that this is baseband in very many
circumstances. In fact, this is probably modulated onto an
RF carrier. By Nyquist's sampling theorem, this carrier
must have a _MINIMUM_ of 2x the data rate to avoid aliasing
of data. I would guess that the carrier frequency is more
along the lines of 4 to 5 times the intended data rate.
Of course, this all assumes ideal lines, perfect
terminations, etc :)
For more info, check out: Data Netwrks by Dimitri
Bertsekas/Robert Gallager Digital Signal Processing by Alan
V. Oppenheim/Ronald W. Schafer Modern Digital and Analog
Communications Systems by B.P Lathi
===
Subject: Re: Acceptable number of collisions? (NOT SO!)
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Tue, 1 Jun 1999 01:55:38 -0400
Sorry, NOT SO...
The discussion was one about "collisions".
In a 10Base2 versus a 10baseT network actual data transfer rates are
unaffected... that is you do get a maximum of 10megabits UNIDIRECTIONALLY
going from point to point under IDEAL conditions...
However in a 10base2 network, data is broadcast in a manner identical to
standard RF transmissions. That is the center core of the co-ax cable acts
as an antenna...
When transmitting data from point a to point b without any other interfering
machine on a lan, due to the lack of collisions on the network data is
transmitted as quickly as it is on a 10baseT network PROVIDED that NO
acknowledgements are needed...
Now TCP/IP sends packets of acks, as do other protocols, so the sender gets
interrupted whenever the recipient attempts to ack the data stream... the
greatly reduces throughput... this introduces a point of degradation...
When more than one machine is present on the lan, even at idle, packets are
being exchanged, resulting in further "backing down" due to collisions...
Compared this to the same situation on 10baseT. 10BaseT has separate
send/receive pairs. In a normal 10baseT network full duplex operation is
enabled. The point to point transfer acks no longer cause collisions, since
they occur on the other wire pairs) resulting in data streaming at closer to
the maximum spec of the lan itself (namely 10mbit/sec)...
Toss a few more machines in to the fray, even without a switching hub,
because "idle" packets spend less time in collisions avoidance/detection,
there is a corresponding decrease in traffic which is interfering with the
point to point data transfers...
The end result, is that from the users perspective thruput increases greatly
when moving from 10base2 to 10BaseT.
---
"I think a basic electronics course is in order."
---
Eh, I think a real world experience course is due... but hey don't believe
me...
See:"Analyzing Novell Networks" by Carl Malamud (c) 1990, Van Nostrand
Reinhold, New York...
Plus many other books on the same subject...
And... if their is anyone on the list who has moved from 10Base2 to 10BaseT,
using hubs, please chime in on your results please... heh.
---
And FYI, coax cable can actually carry more throughput then telephone cable.
This is because
it has a greater diameter and more area for the electrons to flow across
then
all four of the telephone wires you use in 10baseT. How do you think
cableTV
pushes all that data to your television over 2 wires?
---
To paraphrase: "Duh..."
We were talking about 10baseT versus 10BaseT, not the merits of co-ax over
telephone media and
band width on both, your statement is irrelevant to the original
discussion... which was 10base2 over 10BaseT.
But yes co-ax can carry more signal bandwidth than plain old telephone wire,
which is why I'm using a cable modem... however how does this affect my
original assertion? "go with 10baseT on your home lan"
--
"Hubs also don't merely connect a bunch of wires together... IBM Token ring
hubs DO, ethernet somehow picked up the Tokenring/Arcnet nomenclature which
has resulted in a lot of confusion...
Ethernet hubs are a misnomer... they are actually called "concentrators" or
"signal conditioners" since they receive the signal and "clean it up"
--
again... This misleading if not untrue.
--
Hog wash, all hubs are signal conditioners of some sort... point me to one
that isn't...
Yes you can make a cable... and because of signal degradation and
propagation problems it will not exceed fifty feet... Give it a try
sometime! (Better yet, add the third machine in using nothing but cables...
let's see what happens then...)
What part of the above is misleading or untrue?
Let's see "Hubs don't merely connect wires together." True, they minimally
condition the signal...
"Ethernet hubs are signal conditioners." True.
--
While most modern HUBS (ethernet and token-ring) do more then just connect
wires together.
--
Thanks for admitting that, but aren't you implying that your OWN statement
is untrue?
--
things like signal degradation correction
or rmon statistic gathering or snmp trap event reporting, none of this is
required.
--
You are right, for a point to point connection none of this
is required, because you are effectively taking advantage of
designed in tolerances...
However for multiple connections the IEEE spec DOES require
signal conditioning...
But this has little to do with your assertion or the
original discussion...
--
I can make an ethernet or token-ring hub with none of this.
In fact you can simply make a crossover cable (cross tx and
rx wires) to connect two 10baseT machines. This is possible
because all that is required at the physical layer is a
connection of wires between the two machines. The
configuration of those wires varies based on topology type
(ethernet, token-ring, etc...).
--
Irrelevant, we were talking about throughput vis-a-vis collisions on an
ethernet lan....
--
While the term switch is widely overused in the industry, it
usually refers to a segment of a particular topology that is
being bridged or "switched" to other segments of the same or
different topology. Some of the newer switch manufactures
even offer a proprietary backplane between the switched
segments that offers high bandwidth. Usually switched
ethernet segments support one device per switched segment.
This is because with only one device on the segment you have
no collisions. This alone gives you better throughput.
--
I can't argue with that, this is a statement of
fact... which is why I originally told the person go with
ethernet... 10baseT over 10Base2 (the original discussion)
--
Well, my rant is done. I just can't stand when incorrect information is
given out.
--
I guess I can't stand it either hence this message...
Next time be sure of what you are saying before you assume that someone else
is wrong...
Better yet, read the WHOLE thread that way -you- will not be the one giving
out "incorrect" information again...
---
And, yes, I am a network engineer
--
heh, I just might be a "little" bit more... and at it a "little" bit
longer...
===
Subject: Re: Acceptable number of collisions?
From: John Summerfield <summer@OS2.ami.com.au>
Date: Tue, 01 Jun 1999 10:17:11 +0800
> Normally moving from 10Base2 to 10BaseT results in a
> quadrupling of throughput... This is because the TX/RX
> pairs are on separate lines... With 10Base2 everything is
> broadcast over one wire and is much = slower... This is
> untrue. The throughput is a constant 10 Megabits. =20 This
> is why it is called "10"base<MediaType>. And FYI, coax
> cable can actually carry more throughput then telephone
> cable. This is = because it has a greater diameter and
> more area for the electrons to flow across = then all four
> of the telephone wires you use in 10baseT. How do you
> think = cableTV pushes all that data to your television
> over 2 wires? I think a basic = electronics course is in
> order.
This is complete and utter rubbish. Thicker wire gives lower resistance
and so allows a greater current flow for a given potential difference. It
absolutely does NOT allow one to feed more information across it.
Bandwidth is improved by:
Faster switches: transistors are faster than wall-mounted
light switches
shorter wires
better conductors (gold is better than copper)
higher PD
faster medium: fiber optics are faster than copper,
radio is faster still.
Additionally, one cannot see from the diameter of a cable how much
copper's inside: coax has shielding that's nothing to do with signal
transfers. Whatever the copper content of the cables, it's less than is in
the traces on my M/b and I've no doubt the traces are faster than the
cables.
===
Subject: RE: Acceptable number of collisions? (NOT SO!)
From: "KRASZEWSKI, Marcin" <mkraszewsk@shl.com>
Date: Tue, 1 Jun 1999 10:28:38 -0400
Jose M. Sanchez [mailto:opjose@ex-pressnet.com] wrote:
[...]
> Compared this to the same situation on 10baseT. 10BaseT
> has separate send/receive pairs. In a normal 10baseT
> network full duplex operation is enabled. The point to
> point transfer acks no longer cause collisions, since they
> occur on the other wire pairs) resulting in data streaming
> at closer to the maximum spec of the lan itself (namely
> 10mbit/sec)...
I do not know what "a normal 10baseT network" is in the
above context, but Ethernet/802.3 is basically a half-duplex
network, and hubs (or concentrators) always work in the
half-duplex mode. That means that they (their ports) cannot
listen and talk at the same time. What a hub actually does
is it reads a received packet, and without storing it or
analyzing any header information, sends it to all other
ports (floods the ports). As a result each device attached
to a hub sees traffic (electric signal with certain specific
modulation) from all other devices on the same hub (and any
other hubs in the same collision domain for that
matter). Collision detection part of the Ethernet protocol
takes into consideration all the packets sent by devices in
a single collision domain (hence the name - collision domain
<g>).
Switches, OTOH, usually support both duplex modes, these
days most of them autosense the mode of a NIC attached to
it. Each switched port, and devices attached to it,
constitute a separate collision domain. Full duplex actually
means that the collision detection is not implemented (or is
ignored), so the NIC blindly sends packets on one pair,
while listening on the other. NICs in PCs can usually
support only half-duplex mode, servers usually come with
NICs which can support both duplex modes, and have three
settings: full, half and auto. Again, usually, not always.
====
Subject: Re: Acceptable number of collisions?
From: brian davison <bdavison@proaxis.com>
Date: Tue, 01 Jun 1999 23:21:07 -0700
> Bandwidth is improved by:
> Faster switches: transistors are faster than wall-mounted light switches
> shorter wires
> better conductors (gold is better than copper)
> higher PD
> faster medium: fiber optics are faster than copper, radio is faster still.
>
> Additionally, one cannot see from the diameter of a cable how much
> copper's inside: coax has shielding that's nothing to do with signal
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
actually it has lots to do with the signal.... the shielding
keeps out the extraneous noise and keeps the signal in.
That means you can put lots more signal down the pipe
without interfering with everything else. The capacitance
is what limits the frequency/distance equation and loads
down the signal, if it isn't being lost as a radiated radio
transmission. The switch to 10bt probably has more to do
with the limiting distance, and the ability to put signal
regeneration into the hubs to regain what is permanently
lost in the 10b2 daisy chain. The coax could easily carry
100 mhz. or 250mhz. but for successively shorter distances,
so the daisy chain configuration killed it. ***
>transfers. Whatever the copper content of the cables, it's less than is in
>the traces on my M/b and I've no doubt the traces are faster than the
>cables.
... yip ...
but look at the short distance the traces run, and the years
of engineering that went into keeping the motherboard from
being nothing but a major transmitting antenna. actually
the motherboards are just now being used at 100 mhz. and
only for the area required to tie the processor to the
memory bus. everything else is at 66 mhz, 33 mhz,(pci bus
for example), or 8 mhz(AT bus).
brian :)
*******
===
Subject: Re: [OT]Electronics (Was: Acceptable number of collisions?)
From: brian davison <bdavison@proaxis.com>
Date: Wed, 02 Jun 1999 00:30:01 -0700
<snip p p p ed>
> As far as the 10/100Mb goes, that is the data transfer
> rate (maximum). I doubt that this is baseband in very
> many circumstances. In fact, this is probably modulated
> onto an RF carrier. By Nyquist's sampling theorem, this
> carrier must have a _MINIMUM_ of 2x the data rate to avoid
> aliasing of data. I would guess that the carrier
> frequency is more along the lines of 4 to 5 times the
> intended data rate.
< snip>
The 10 or 100 mbit rate is a digital signal rate, and is the
data rate. Were the data encoded into an analog signal, the
above would be true. as it is, the bits required for
transmission are expanded by the packetizing overhead but
not much else. maybe someone will figure out how to get the
same kind of data rates on ethernet as the new modems do on
the phone system, where a bandwidth of less than 8kbits is
used to pass 56 kbits along.... were that true, then 100
mbit (100 bt) could be almost gigabit capable....
===
Subject: Re: Acceptable number of collisions? (NOT SO!)
From: "Richard W. Gowen" <richard@gowen.net>
Date: Wed, 2 Jun 1999 16:51:59 -0500
Jose M. Sanchez <opjose@ex-pressnet.com> wrote:
> Manchester encoding on a carrier frequency...
> The carrier is "broadcast" to all stations over the
> wire. The electrical signals exhibit the same propagation
> characteristics as a typical antenna segment...
> Hence the need for terminators in a 10base2 wire ...
There is a big difference between an analog signal such as
you see in an antenna's electromagnetic wave and a digital
signal like is used in 10baseT or 10base2. There is a
carrier frequency which is 10Mhz (regardless of media) but
it is a digital carrier. The only resemblance an ethernet
network has to a radio antenna is that the nic cards contain
transceivers that send and receive signals. The signals are
not the same. Don't believe me, then buy an Oscope. You'll
see a square wave instead of a rounded one.
And a terminator does exactly that, it terminates the square
wave so it doesn't bounce back and be seen again by stations
on the wire. Take one off and watch it, you'll see what I
mean.
> > Since you want to keep this discussion to collisions why are we talking
> > about acknowledgments?
> >
> Because it is a factor contributing to the number of
> collisions occuring in a 10base2 network.
The number of collisions occuring on ANY 10base media is
directly proportional to the segment utilization. It has
NOTHING WHATSOEVER to do with the media type.
Both 10base2 and 10baseT operate at 10Hz and have the same
collision domain. The only real difference between the two
are the distance limitations of the cables (100meters for
10baseT and 185meters/607ft for 10base2). This is due to
the IEEE requirement of a maximum signal loss source to
destination of 11.5db. These numbers are based on
unrepeated segments, since a repeater will take care of
signal loss.
> > A 10baseT HUB is a bus topology, that is each station's
> > CAT3 or better cable is physically wired to a central backing.
> Not so, -ALL- 10baseT hubs have active conditioning
> circuitry... again show me one that doesn't.
I can do better then that. I can show you how to make your own. It's very
similar to how you make a crossover cable. You take however many female
RJ45 connectors as you want you hub to hold. Then connect pin1(tx+) on each
connector to pin3 (rx+) on all the other connectors (one to many scenario).
Then connect pin2(tx-) on each to pin6(rx-) on all the others. There you
go. And it works. I built it in the lab today and tested it. Attached is
a graphic if you're still confused. FYI, this is called a bus topology
which still works with 10baseT even though most hubs use a repeated star
topology. Just because it's seldom done doesn't mean it's against the
rules.
> The spec mandates this.
> When I get a chance I'll find them for you...
You say this but I still don't see it. That is unless your
looking at the repeater requirements. But that would not
apply here to an unrepeated segment.
I am not just making this statement alone. Your statements
made me check with others. Namely, our support engineers at
both Cabletron and Cisco. Neither of them knew of this
conditioning standard you speak of. Other then the db loss
limitations and repeater rules, none of us have found
anything on this.
If you do know of some spec that applies to a single
non-repeated segment and signal conditioning please give me
the spec number. If not, drop it.
> > > ---
> > > Irrelevant, we were talking about throughput vis-a-vis
> > > collisions on an ethernet lan....
> > It is relevant since we are talking about the physical layer.
> > The collision domain can be set up logically in a smart hub
> > but only needs to be set up physically. That was my point.
> >
> Eh no, your point was that there was no difference when
> moving from 10base2 to 10baseT...
> The actual mechanics are not in question...
Yes the mechanics are in question. What detects a
collision? The transceiver of a nic card. Does this
transceiver handle collision detection differently based on
cable type? NO. Is there a difference in collision
mechanics or percentage of collisions based solely upon
cable type? NO. Is there a need to mention 10base2
vs.10baseT in a discussion related to collisions? NO.
One final point: Did you ever think that the reason the
people you've seen migrate from 10base2 to 10baseT seem to
work better is because they are moving from a bus topology
to a repeated star topology? This alone makes a big
difference. And this could probably change the traffic
patterns on that network, thus influencing the percentage of
collisions. But media type alone has no direct affect upon
the number of collisions on a single segment.
===
Subject: Re: Acceptable number of collisions? (NOT SO!)
From: "Jose M. Sanchez" <opjose@ex-pressnet.com>
Date: Thu, 3 Jun 1999 00:51:41 -0400
Richard W. Gowen <richard@gowen.net> wrote:
> Jose M. Sanchez <opjose@ex-pressnet.com> wrote:
> > Manchester encoding on a carrier frequency...
> > The carrier is "broadcast" to all stations over the
> > wire. The electrical signals exhibit the same
> > propagation characteristics as a typical antenna
> > segment...
> > Hence the need for terminators in a 10base2 wire ...
> There is a big difference between an analog signal such as
> you see in an antenna's electromagnetic wave and a digital
> signal like is used in 10baseT or 10base2. There is a
> carrier frequency which is 10Mhz (regardless of media) but
> it is a digital carrier. The only resemblance an ethernet
> network has to a radio antenna is that the nic cards
> contain transceivers that send and receive signals. The
> signals are not the same. Don't believe me, then buy an
> Oscope. You'll see a square wave instead of a rounded
> one.
Re: Square waves: no argument from me here...
> And a terminator does exactly that, it terminates the
> square wave so it doesn't bounce back and be seen again by
> stations on the wire. Take one off and watch it, you'll
> see what I mean.
> > > Since you want to keep this discussion to collisions
> > > why are we talking about acknowledgments?
> > Because it is a factor contributing to the number of
> > collisions occuring in a 10base2 network.
> The number of collisions occuring on ANY 10base media is
> directly proportional to the segment utilization. It has
> NOTHING WHATSOEVER to do with the media type.
Theoretically no, but in actual practice the same number of
workstation running on a 10base2 lan are far slower than
when the same workstations are switched over to 10baseT...
Again this is due to the separated RX/TX pairs...
> Both 10base2 and 10baseT operate at 10Hz and have the same
> collision domain. The only real difference between the
> two are the distance limitations of the cables (100meters
> for 10baseT and 185meters/607ft for 10base2). This is due
> to the IEEE requirement of a maximum signal loss source to
> destination of 11.5db. These numbers are based on
> unrepeated segments, since a repeater will take care of
> signal loss.
> > > A 10baseT HUB is a bus topology, that is each
> > > station's CAT3 or better cable is physically wired to
> > > a central backing.
> > Not so, -ALL- 10baseT hubs have active conditioning
> > circuitry... again show me one that doesn't.
> I can do better then that. I can show you how to make
> your own. It's very similar to how you make a crossover
> cable. You take however many female RJ45 connectors as
> you want you hub to hold. Then connect pin1(tx+) on each
> connector to pin3 (rx+) on all the other connectors (one
> to many scenario). Then connect pin2(tx-) on each to
> pin6(rx-) on all the others. There you go. And it works.
> I built it in the lab today and tested it. Attached is a
> graphic if you're still confused. FYI, this is called a
> bus topology which still works with 10baseT even though
> most hubs use a repeated star topology. Just because it's
> seldom done doesn't mean it's against the rules.
To paraphrase: Cool!
OK, I'll concede the point... you don't need it, never the less, you
probably want signal conditioning or active hubs...
> > The spec mandates this.
>
> > When I get a chance I'll find them for you...
> > > > ---
> > > > Irrelevant, we were talking about throughput vis-a-vis collisions on
> an
> > > > ethernet lan....
> > >
> > > It is relevant since we are talking about the physical layer.
> > > The collision domain can be set up logically in a smart hub
> > > but only needs to be set up physically. That was my point.
> > >
> > Eh no, your point was that there was no difference when
> > moving from 10base2 to 10baseT...
> > The actual mechanics are not in question...
> Yes the mechanics are in question. What detects a
> collision? The transceiver of a nic card. Does this
> transceiver handle collision detection differently based
> on cable type? NO. Is there a difference in collision
> mechanics or percentage of collisions based solely upon
> cable type? NO. Is there a need to mention 10base2
> vs.10baseT in a discussion related to collisions? NO.
> One final point: Did you ever think that the reason the
> people you've seen migrate from 10base2 to 10baseT seem to
> work better is because they are moving from a bus topology
> to a repeated star topology? This alone makes a big
> difference. And this could probably change the traffic
> patterns on that network, thus influencing the percentage
> of collisions. But media type alone has no direct affect
> upon the number of collisions on a single segment.
Except they are NOT moving to a "repeated" star topology...
Take the very same setup you created above...
Transfer files ON THE SAME NICS (hopefully you have dual mode
10base2/10baseT nics...)
in both modes. You'll get far better results on the 10baseT setup you're
talking about above...
Toss any other minor form of activity, (i.e. winblows polling the lan for
workstation) and the degradation
increases more than linearly...
Unless by repeated star, you mean your own "passive" hub (which you insisted
need not be active, hence not "repeated" either), then the results will
violate the same specifications you are quoting...
In effect, we should NOT see any difference between the two topologies,
going by what you are saying or implying...
But we do, and it's a BIG, BIG difference...
===
Subject: RE: Acceptable number of collisions? (NOT SO!)
From: KThorpe <kthorpe@pricetrak.com>
Date: Thu, 3 Jun 1999 9:59:00 +0100
Sorry, I was trying to keep out of this but I've just had to
get involved.
Switching our 10Base2 to 10baseT with 18 stations over three
floors gave a significant increase in speed and made
collisions a rarity rather than the norm. We've since had to
go to switched 100MHz but that's another story.
Part of the improvement is almost certainly due to improved
cabling. 10base2 is very prone to damage through kinks and
yanked connectors. Often this damage doesn't stop the
network but does add to collisions and bad packets. I assume
this is due to stray echoes on the cable from the resultant
bad joints.
Another part of the improvement is that AFAIK, standard
10baseT hubs are actually a star configuration and
simultaneously broadcast incoming packets on all
connections. This reduces the overall length of the network
considerably and reduces the window during which a collision
can be initiated.
With ethernet, shorter is better. Long networks are much
better built using token passing protocols such as Token
Ring or Cambridge ring.
===
Subject: Re: [OT]Electronics (Was: Acceptable number of collisions?)
From: Tom Burke <tomii@erols.com>
Date: Thu, 03 Jun 1999 19:58:41 -0400
> At 02:11 PM 6/2/99 -0500, you wrote:
> >Hmmm. All this time I thought it was 300E6 m/sec....
brian davison wrote:
> It says that in my text book too!!! thats ~=~ close to
> one foot per nanosecond for electron/wave propagation on
> wire... so if your memory module is 6in. away from the
> processor it adds at least 1 nanosecond to the access
> time! ok enough trivia now
It's wave propagation, not electron propagation... This is
a subtle point that most people don't get (and to most
people, it doesn't make a difference). Like I said, the
easiest way to look at it is a garden hose full of marbles.
Push one in, and immediately, one falls out the other end.
The marbles are moving very slowly, but the signal travels
pretty danged quickly.
In reality, (depending on the media) for the voltages &
currents in your computer, the electrons are moving a couple
hundred miles per hour at most (I suppose I could figure it
out, but it's just not worth my time right now :) )...
Again, depending on the media, the wave (signal) propagates
slightly slower than the speed of light.
At one time, I interviewed with Intel - they wanted me on
the P-II team. If I had taken the job, it would have been
as an analog engineer on that little board the processor &
cache sit on. They're pushing signals on it so quickly,
that everything becomes transmission line theory, &
impedance matching of the motherboard to the carrier to the
chip is really critical.
===
Subject: Re: adaptec 7895 not recognized?
From: Jan Carlson <janc@iname.com>
Date: Thu, 17 Jun 1999 13:06:57 -0400
Don Brown wrote:
> It seems that neither 5.2 or 6.0 Redhat support the
> adaptec 7895 or 7896 scsi adapters.
Those are definitely supported.
> When I try to install Redhat on my other system, it
> attempts to scan an imaginary 2940 and freezes. When I tried to install
> via expert install, I found that the 7895 was not an option. This is on
> a S1836DLUAN GX Thunder 100.
http://www.redhat.com/hardware tells you which module to use.
Look under Red Hat 6, Intel, Scsi Cards.
===