> On Mon, 23 Aug 2004, Steven Buehler wrote:
>
> > On Mon, 23 Aug 2004 08:25:09 -0400, Felix Boecker
> > <3.14159265359@mad.scientist.com> wrote:
> > > good idea, but ifconfig appears to be ok:
> > > eth0 Link encap:Ethernet HWaddr 00:D0:59:A9:C0:AA
> > > inet addr:10.231.192.172 Bcast:255.255.255.255
> > > Mask:255.255.240.0
> > > UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500
> > > Metric:1
> > > RX packets:3240 errors:0 dropped:0 overruns:0 frame:0
> > > TX packets:845 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:109 txqueuelen:1000
> > > RX bytes:696817 (680.4 Kb) TX bytes:102007 (99.6 Kb)
> >
> > I do see an issue: "collisions: 109" You're getting packet
> > collisions on the network, which will slow you down.
>
> Good catch. As a data point,
>
> eth0 Link encap:Ethernet HWaddr 00:50:BA:AF:1F:A3
> inet addr:192.168.1.11 Bcast:192.168.1.255
Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:197002 errors:0 dropped:0 overruns:0 frame:0
> TX packets:159475 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:210921127 (201.1 Mb) TX bytes:66624837 (63.5 Mb)
> Interrupt:5 Base address:0xb000
>
> No collisions, and about 350x the data transmitted. Does that LAN use
> DHCP, and did you get that address via DHCP? Does the same NIC work
at
> school under another OS?
>
> --
> -eben
There will always be some small amount of collisions, it is a part
of Multiple Access (many stations contending for the same
time slot on a shared ethernet bus) as in CSMA, with the CS
meaning Carrier Sense to tell the hdware when the collisions occur.
If you have a single machine on your private LAN, there should be few
if any collisions. Several machines will increase this rate.
Ethernet is considered to start bogging down when the
utilization goes past about 37% as the collision rate
increases rapidly. This means a real throughput of less
than 4 MB on what is listed as a 10 MB wire.
109 collisions on that amount of data should be
UN-noticeable. Congestion at the peering points on
your network backbone will be much more noticeable
in terms of delay. The reassembly in TCP should tell
the upper layers "immediately" that a re-send is needed.
An acceptable collision number is 0.1 percent (one in 1000).
(Collisions / (InputPackets + OutputPackets)) x 100
There are local, remote, and late collisions. A late collision
occurs because two stations kept transmitting past the
preamble length, which is supposed to be long enough
(64 bytes of alternating 0 and 1, up to the SFD) to allow
all stations to detect the collision. In a late collision the
NIC thinks everything went out OK and the frame becomes
missing. You probably don't have this problem but if you
do it is certainly bad hardware or cabling..
Local collisions can be caused by:
- overloaded network segment (high traffic)
- faulty or marginal NIC
- ethernet transceiver or repeater fault
- illegal hardware configuration
- ethernet cabling fault
- bad or poor host termination
- bad grounding
- induced noise on the segment
Some of these are more particular to coax-based
segments, however.
I don't have any idea of why DHCP / DNS is included in this
discussion. It is just another form of traffic and the physical
layer does not care what kind of traffic is being sent. You
can run stateless NFS, or packetburst over SPX (Novell)
to see when you start really losing data. The data rate
and frame length of a UDP DNS query should be
somewhat lower network load than just reading a web page
full of big graphics. Where did DNS come into this discussion??
You can also try testing with iperf or ttcp, and get some
hard numbers.
I saw a time a while back when two Silicon Graphics
Indigos on a 10 MB backbone would start a FTP session
and completely seize the network. It was alleged that
SGI had played games with the protocol and reduced the IFG
below the mandated 9.6 us, so that no one else could
contend for the buss.
If you use an analyzer that shows "runts" you generally
will see pieces of jam signal sent in response to
collisions, these will look like 55-55-55 or AA-AA-AA
as they are just strings of 01010101 or 10101010.
(actually the same thing) This is a good way to check
to see if you have this trouble. The LanDecoder/e DOS
based program using a SMC 8416 with an ODI driver shows
these errors quite well and I use it here. (Yes, DOS lives !)
Another test that could be done is for a valid Frame Check
Sequence (4 bytes at the Phy layer at the end of the frame,
which makes the frame 1518 bytes if you count it, 1514 if not).
An acceptable level of CRC error is 0.00001%. These are
typically caused by physical layer faults or by noise induced
on the cabling such as UTP running past a fluorescent
light fixture. You need a hardware based analyzer to
look for invalid FCS, which has nothing to do with the
network protocol or the data type, it is just bits on the wire..
If this collision rate bothers you, replace the NIC, the
cabling and possibly your hub if you use one, and try
running with fewer machines on your LAN if you have
more than a couple on at once.
-
Reference: pp 112-117, Network Consultants Handbook,
M Castelli, Cisco Press, 2002, ISBN 1-58705-039-0
Bob
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:13:32 EDT