|
|
The most useful command for examining TCP/IP performance (and that of other protocol stacks) is netstat(TC). This command displays the contents of various networking-related data structures held in the kernel. We have already encountered the -m option to netstat in ``Monitoring STREAMS performance'' where it allowed us to see how STREAMS resources were allocated inside the kernel.
The command netstat -i displays the status of the system's network interfaces. (To view only a single interface, specify this using the -I option.) The output from this command has the following form:
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Collis sme0 1500 reseau paris 996515 0 422045 42 0 lo0 2048 loopback loopback 25436 0 25436 0 0The important fields are
Ierrs, Oerrs,
and Collis.
Ierrs is the number of received packets that the system recognized
as being corrupted. This usually indicates faulty network hardware such
as a bad connector, incorrect termination (on Ethernet), but it may also
be caused by packets being received for an unrecognized protocol.
For network adapters with small buffers, it may mean
that they have been saturated by end-to-end streams of packets. In this
case, you should switch the network interface to one-packet mode using
the
ifconfig(ADMN)
command as described in
``Using ifconfig to change parameters for a network card''.
Oerrs is the number of errors that occurred while the system
was trying to transmit a packet.
This generally indicates a connection problem.
On Ethernet, it may also indicate a prolonged period of time
during which the network is unusable due to packet collisions.
Collis is the number of times that the system
(connected to a network using Ethernet as its physical medium)
detected another starting to transmit while it was already transmitting.
Such an event is called a packet collision.
The ratio of the number of
collisions to the number of output packets transmitted gives a indication
of the loading of the network. If the number of Collis
is greater than 10% of pkts for the
most heavily used systems on the network, you should investigate
partitioning the network as described in
``Configuring network topology for performance''.
Networks implemented using
Token Ring and FDDI technology use a
different protocol to communicate at the physical
layer and do not experience packet collisions.
The value in the Collis field should be
zero for such networks.
See ``Troubleshooting TCP/IP'' for a full discussion of these issues.
The following table summarizes the commands that you can use to examine the performance of TCP/IP:
Examining TCP/IP performance
| Command | Field | Description |
|---|---|---|
| netstat -i | Ipkts | number of network packets received |
| Ierrs | number of corrupted network packets received | |
| Opkts | number of network packets transmitted | |
| Oerrs | number of errors while transmitting packets | |
| Collis | number of packet collisions detected |
If TCP/IP is configured, your system runs the /etc/rc2.d/S85tcp script each time it goes to multiuser mode. (Note that this file is a link to /etc/tcp.) This script starts several TCP/IP daemons. If configured to run, the following daemons may affect performance:
To maximize performance of a connection over a SLIP link, do the following:
To maximize performance of a connection over a PPP link, do the following:
For a complete discussion of using PPP, see ``Configuring the Point-to-Point Protocol (PPP)''.
The ping(ADMN) command is useful for seeing if a destination machine is reachable across a local area network (LAN) or a wide area network (WAN). If you are root, you can use the flood option, -f, on a LAN. This sends a hundred or more packets per second and provides a stress test of the network connection. For every packet sent and received, ping prints a period (.) and a backspace respectively. If you see several periods being printed, the network is dropping packets.
If you want to find out how packets are reaching a destination and how long this takes, use the traceroute(ADMN) command. This provides information about the number of hops needed, the address of each intermediate gateway, and the maximum, minimum and average round trip times in milliseconds. On many hop connections, you may need to increase the maximum time-to-live (TTL) and wait times for the probe packets that traceroute sends out. To do this, use the -m and -w options.
See also:
The types and capabilities of Ethernet network technology (as defined by the IEEE 802.3 standard) are shown in the following table:
Ethernet network technologies
| Type | Topology and | Maximum segment | Maximum number |
|---|---|---|---|
| and alternative names | medium | length | of nodes per segment |
| 10Base5, ThickNet | linear, 50 ohm 10mm coaxial cable terminated at both ends | 500m | 100 |
| 10Base2, ThinNet, CheaperNet | linear, 50 ohm 5mm coaxial cable terminated at both ends | 185m | 30 |
| 10Base-T, twisted pair | star, unshielded twisted pair | 100m | 2 |
To attach nodes to the network, 10Base5 connects drop cables to vampire taps directly attached to the coaxial cable or to transceiver boxes placed in line with the cable.
10Base2 T-piece connectors must be connected directly to the coaxial terminal of the network card -- that is, you cannot use a coaxial cable as a drop cable.
If you want to extend the length of an Ethernet cable segment, there are three ways of doing this:
If there are a large number of input or output errors, suspect the network hardware of causing problems. Reflected signals can be caused by cable defects, incorrect termination, or bad connections. A network cable analyzer can be used to isolate cable faults and detect any electrical interference.
Dividing a network into subnetworks to reduce network traffic
To reduce network loading, consider
dividing it into separate networks (subnets) as shown in
``Dividing a network into subnetworks to reduce network traffic''.
This diagram shows how a network could be divided into three
separate subnets. Routers connect each subnet to a backbone
network. This solution only makes sense if you can group
clients with individual servers by the function they perform.
For example, you could arrange that each subnet corresponds
to an existing department or project team within an organization.
The clients dependent on each server should live on
the same subnet for there to be a gain in network performance.
If many machines are clients of more than one
server, this layout may actually
make the situation worse as it will impose an additional load
on the servers acting as routers.
An alternative would be to use bridges to connect the network segments though this may be a more expensive solution. A potential problem with this is that if a bridge fails, the connection between the two segments is severed.
By connecting subnets using more than one router, you can provide an alternative route in case of failure of one of the routers. Another problem with using bridges is that they are intended to partially isolate network segments -- they are not a solution if you want to provide open access to all available services.
Design the layout of subnets to reflect network usage. Typically, each subnet will contain at least one server of one or more of the following types:
If you run client-server applications across repeaters, bridges, or routers, you should be aware that this will impose additional delay in the connection. This delay is usually least for repeaters, and greatest for routers.
See also:
There are few performance issues concerned with routing. Choice of routes outside your system is not generally in your control so this discussion only considers routing within an autonomous network.
Most networks use the Routing Information Protocol (RIP) for internal routing. RIP uses a metric for choosing a route based on distance as a number of hops. This metric is not optimal in certain circumstances. For example, it would choose a path to the desired destination over a slow serial link in preference to crossing an Ethernet and a Token Ring. You can increase the hop count on the slow interface advertised in the /etc/gateways file to overcome this limitation. The RIP protocol is available with both the routed(ADMN) and gated(ADMN) routing daemons.
Most networks tend to use routed as it requires no configuration. However, we recommend that you only use RIP for simple network topologies. The Open Shortest Path First (OSPF) protocol is better suited than RIP for complex networks with many routers because it has a more sophisticated routing metric. It can also group networks into areas. The routing information passed between areas uses an abstracted form of internal routing information to reduce routing traffic. OSPF is only available using the gated routing daemon.
You can use the Internet Router Discovery (IRD) protocol for routing within networks in autonomous systems. This is not a true routing protocol but it allows hosts connected to a multicast or broadcast network to discover the IP addresses of routers using ICMP messages. Routers can also use the protocol to make themselves known. The irdd(ADMN) daemon uses the IRD protocol and is normally configured to run by default in addition to routed.
You can minimize the routing traffic on your network by configuring:
The Domain Name Service server included with TCP/IP can operate in a number of modes, each of which has its own performance implications.
A primary or secondary DNS nameserver maintains and accesses potentially large databases, answers requests from other servers and clients, and performs zone transfers. Both network traffic and memory are impacted.
There are several ways in which you can influence the performance of primary and secondary DNS nameservers:
A DNS client pushes all resolution requests onto one or more DNS servers on the network; none are handled locally. This puts the burden of resolution on the network and on the nameservers listed in resolv.conf. It also means that named does not run and, therefore, does not add to the system load. In the case where the local machine has limited memory and response time over the network ranges from adequate to excellent, this configuration is desirable from a performance standpoint. If network response time is slow and memory is not limited, consider re-configuring the system as a caching-only server.
See also: