Tuning networking resources

Monitoring TCP/IP performance

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     0
The 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.

NOTE: You can also use the ndstat(ADM) command to obtain similar information to that displayed by netstat -i.

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

Configuring TCP/IP daemons for performance

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:

handles routing and supports a variety of routing protocols.

provides Internet routing discovery.

handles routing by default. routed may be commented out of /etc/tcp if your system uses irdd(ADMN) to maintain routing information. Note that all systems to which you are networked must be able to handle icmp(ADMP) routing. See ``Configuring Internet Protocol (IP) routing'' for a full discussion of the gated, irdd, and routed daemons.

provides Domain Name Service (DNS). named has many performance implications. See ``Configuring DNS name service for performance'' for information on configuring DNS to use named.

provides the remote who facility, see rwho(TC). rwhod is commented out of /etc/tcp for performance reasons. Uncommenting this daemon generates additional network traffic as the daemon queries the system for user and uptime information and broadcasts this data to the network.

implements the simple network management protocol (SNMP). snmpd runs by default. It generates additional packets during startup and other unusual system events. It monitors and responds to SNMP traffic from other machines. If you do not want SNMP running on your system, use the SNMP Agent Manager to turn off the SNMP agent as described in ``Configuring SNMP with the SNMP Agent Manager''.

Tuning SLIP performance

To maximize performance of a connection over a SLIP link, do the following:

For a complete discussion of using SLIP, see ``Configuring the Serial Line Internet Protocol (SLIP)''.

Tuning PPP performance

To maximize performance of a connection over a PPP link, do the following:

You can also edit the file /etc/ppphosts to configure these parameters; see ppphosts(SFF) for more information.

For a complete discussion of using PPP, see ``Configuring the Point-to-Point Protocol (PPP)''.

Testing network connectivity

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:

Configuring network topology for performance

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
For Ethernet technologies that use a linear network topology, the cable must not have any branches or loops and it must be correctly terminated at both ends.

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:

Monitor the network regularly for packet collisions as described in ``Monitoring TCP/IP performance'' or use a network activity tester (commonly called a sniffer) if you have access to one. If the proportion of collisions to packets sent is greater than 10%, your network is probably overloaded. Some networks may be able to struggle along at collision rates as high as 30% but this is rarely acceptable.

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:

Some machines may also be expected to run X client processes for X servers running on X terminals and workstations. Applications such as desktop publishing and PostScript previewers transfer large amounts of data across the network. If possible, you may find it preferable to confine running such applications to dedicated workstations on the network.

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:

Configuring routing for performance

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:

For a full discussion of the various protocols, the daemons that use them, and how to configure these daemons, see ``Configuring Internet Protocol (IP) routing''.

Configuring DNS name service for performance

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 caching-only DNS nameserver maintains and accesses a potentially large cache. Because a caching-only server may answer many of its own requests, memory is impacted more highly than network traffic. If the machine has limited memory, you should strongly consider turning the machine into a DNS client using the resolver configuration file, /etc/resolv.conf.

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:

Next topic: NFS resources
Previous topic: Tuning TCP/IP performance

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003