"Linux Gazette...making Linux just a little more fun!"

Copyright Ó 1998, 1999 by Ron Jenkins. This work is provided on an "as is" basis. The author provides no warranty whatsoever, either express or implied, regarding the work, including warranties with respect to its merchantability or fitness for any particular purpose.

The author welcomes corrections and suggestions. He can be reached by electronic mail at , or at his personal homepage: http://www.qni.com/~rjenkins/.

Corrections, as well as updated versions of all of the author's works may be found at the URL listed above.

NOTE: As you can see, I am moving to a new ISP. Please bear with me as I get everything in working order. The e-mail address is functional; the web site is semi operational, I will add to it as I get the time.

SPECIAL NOTE: Due to the quantity of correspondence I receive, if you are submitting a question or request for problem resolution, please see my homepage listed above for suggestions on information to provide.

Operating Systems Covered/Supported:
Slackware version 3.6
RedHat version 5.1
Windows NT Server version 4.0
Windows NT Workstation version 4.0

I only test my columns on the operating systems specified. I don?t have access to a MAC, I don?t use Windows 95, and have no plans to use Windows 98. If someone would care to provide equivalent instructions for any of the above operating systems, I will be happy to include them in my documents.

Part Seven: Internet Gateway performance tuning and tips
In a continuation of last month's column, we will look at some ideas, tips and tricks to improve the performance of our Internet Gateway, as well as some advanced configuration options.

As with each installment of this series, there will be some operations required by each distribution that may or may not be different in another. I will diverge from the generalized information when necessary, as always.

In this installment, I will cover the following topics:

• Overview of Performance tuning and enhancement.
• Techniques for performance enhancement.
• WAN connection upgrades.
• Hardware upgrades.
• Software upgrades.
• Caching options.
• General tips and tricks.
• References.
• Resources for further information.
• About the Author.

Also, throughout the article, I shall use the term WAN connection and PPP connection interchangeably.

Overview of Performance tuning and enhancement:
Performance enhancement, like any other project, requires an analysis of the cost of the enhancement versus the amount of improvement.

What we will endeavor to accomplish here is to improve the performance of our gateway, using a variety of techniques, while keeping the additional cost as low as possible.

For any method suggested here, there will be a trade off. Some of the following suggestions may or may not be applicable to your own unique situation.

Some of these techniques will provide a real, measurable, and noticeable improvement, while others will only become apparent through long term analysis, or examination of various statistical reporting methods available to you. The ability to accurately measure the performance of your gateway machine is essential to effective tuning.

As we go along and become familiar with each technique, I will also introduce appropriate methods of measuring these techniques, and therefore accurately measure the amount or percentage of improvement.

Techniques for performance enhancement:
Although some of the ideas and techniques discussed here will be applicable to other types of machines, such as file servers and workstations, the primary focus of this column will be geared toward the specific enhancement of gateway machines.

In the context of this assumption, the following techniques, in descending order of importance will provide the most improvement in the operation and speed of the gateway machine:

1. WAN connection upgrades.
2. Hardware upgrades.
3. Software upgrades.
4. Caching options.

WAN connection upgrades:
The single most effective method for increasing the performance of your Internet Gateway is to upgrade the speed of your connection to the Internet.

This can take the form of a dedicated or dialup connection in most cases. Some of the options you may want to consider include:

• Many ISP's offer "dual modem" service. This is a technique whereby the two individual modem connections are "bound" together using multi-link PPP. The performance enhancement is slightly less than the sum of the two individual connections.
• 56K modems, provided they are not software modems, more commonly known as "WinModems," may be an option. I have been told by one of my readers that the external models work well, and if the internal model is NOT a soft modem as described above, it should work as well. (Thanks go to Gerald McGlew for setting me straight on this information.)
• Presently, an Integrated Services Digital Network (ISDN) line, commonly known as a Basic Rate Interface, or BRI, is one of the best ways to remarkably improve the performance of your Gateway machine. In my area, an ISDN line, with unlimited usage, costs about $80.00 per month. The cost for a dial up ISDN connection in my area is about $50.00 total cost (line charge + ISP access) ~$130.00.
• Another possibility would be a cable modem, although I know very little about these devices, as they are not available in my area, so I do not know how cost effective they are.
• In some areas of the country, Digital Satellite Network systems are available. These work well, as long as you have a clear path to the satellite. However, the satellite connection is only unidirectional, meaning that it only moves FROM the remote station TO your PC. This is called the downlink. A separate method of access is required for the uplink, or your requests TO the remote network. This can be anything from a simple modem to a dedicated connection.

For checking the real time condition of your WAN connection, as well as the effectiveness of any compression options you may be using, pppstats is very helpful. This utility should be available on both Slackware and RedHat machines.

Hardware upgrades:
To improve the performance of your local network access, RAM and disk subsystems are king. Provided your motherboard has sufficient cache to handle it, put as much RAM as you can afford in your server and gateway machines.

Another crucial area is the disk subsystem. Although there have been significant advances in ATA technology, such as EIDE, UDMA, and so on, the standard for heavy, continuous use and high performance is still the Small Computer Systems Interface, or SCSI device.

It is important to note that IDE drives are SEQUENTIAL access devices, meaning each request for information must "stand in line" and wait for it's turn. SCSI drives are CONCURRENT access devices, meaning multiple requests can be serviced simultaneously.

While the price differential between IDE devices and comparable SCSI devices was prohibitive in the past, at the preset time, the difference is negligible. Consider Ultra (20MBS) drives a minimum, Ultra Wide (40MBS) drives better.

A SCSI subsystem is comprised of four basic parts

• the host adapter, or card that is inserted in your PC and coordinates all communication between the SCSI devices and your computer.
• The SCSI bus, upon which all the data interchange takes place. Usually a 40 or 50 pin cable, depending on the speed of the host.
• The SCSI devices, which may include disks, scanners, tape drives, and many other devices. The number of devices allowed on a given bus depends on the speed of the host as well, but is not limited to four devices, like a comparable IDE bus.
• The termination devices. Like the bus network we discussed in December, a SCSI bus requires termination at both ends, just like a 10BASE2 coaxial network. The termination can be active or passive, and may or may not require an additional device to be attached, especially on external SCSI devices.

NOTE: Unless you are planning on implementing some of the caching techniques described below, a disk subsystem upgrade will not provide a noticeable performance enhancement.

Simple routing and masquerading are done in the kernel, on the fly, causing minimal interaction with the disk.

However, if the machine also doubles as a file server, web server, or something other than just an Internet Gateway, then it is worth considering.

Software upgrades:
In the area of software enhancements, here are some options to consider:

PPP Software - You may want to consider upgrading your PPP software if your distribution does not contain PPP version 2.3.0 or greater.  This version contains support for the demand dialing option, thus eliminating the need for diald or any such extra stuff.

It also supports a more robust scripting method based on ppp-xx scripts, usually prepared at installation time and requiring only some editing to make them functional. These files are usually located in /etc/ppp and/or /usr/sbin.

Data Compression - A comprehensive explanation of Data compression theory is beyond the scope of this article, so briefly, here is an overview of compression methods and how they can improve the apparent speed with which traffic flows through your WAN interface.

Van Jacobson (VJ) Compression - This is enabled by default in most Linux distributions of the PPP daemon.

BSD Compression (bsdcomp) - Another compression scheme, usually disabled by default. You will be required to load a module, or re-compile the kernel to include support for this.

Deflate Compression - Yet another compression scheme, also disabled by default.

Any one of, and/or combination of these compression schemes may or may not improve the apparent performance of your PPP connection. To enable, disable, or adjust the parameters for any or all of these compression schemes, see the pppd man pages. Experiment with them, using netwatch to measure any speed changes, and pppstats to measure the amount of compression.

BIND - The Berkley Internet Name Daemon (BIND), commonly called named, is the service responsible for hostname to IP address translation on the Internet, most often referred to as Domain Name Service, or DNS**.

While it is impractical to run your own full blown DNS server (unless of course you have your own domain, and a block of assigned IP's,) It can be helpful to run what is known as a "caching only" nameserver.

Whenever you request an object on the Internet, whether it be a web page, ftp site, news server, or whatever, you usually issue the request in the form of a hostname/path_to_object/ format. When your request goes out, it is handed off to the DNS server specified in your resolv.conf file first.

Since the DNS system is hierarchical, like an upside down pyramid, with the point on the bottom being the DNS machine in your resolv.conf file, your DNS machine only knows about machines local to it's own network*, in this case, your ISP's. This information is contained in what are known as "zone" files, which are simply ASCII text files that list information about a "zone" or domain in a standardized format.

If the request cannot be resolved by this machine, it then consults the next higher machine in the pyramid, as so on until ultimately, if necessary, the query reaches the "root.servers" responsible for all the *.com, *.edu, *.net domains and so on.

Finally, at some point, after much communication back and forth across the WAN connection, the hostname you requested will be converted into an IP address, and sent back to your computer.

Clearly, there's a significant amount of communication going on in the background to let us meat based computing devices do the "dub dub dub" deal.

What a caching nameserver does simply put, is to "remember" these name to IP resolutions for a period of time, so the next time a particular object is requested, the nameserver can service the request locally, without having to go outside the local network. This is way cool for two reasons. It makes name resolution appear much faster, and reduces traffic on the WAN.

The downside to this is that each initial, or "new" request will take slightly longer to return to your computer. As I said before, everything is a trade off. Usually, the latency is nominal. This technique is almost always a good idea.

Squid - This is a web proxy/caching software suite that is infinitely configurable, and supports many services. To find out more about Squid, and whether it is right for your particular installation, see the resources section at the end of this document.

Leafnode - This is a replacement for the Network News Transport Protocol (NNTP) server usually used in most UNIX installations. It is small, easy to configure, and takes up a fraction of the disk space of the normal Internet News (INN) software. The trade off is that it does not scale well, and can really tie up your WAN connection when it initially downloads the articles available from the newsgroups you have selected (See the cron section of the General Tips and Tricks for some ways to minimize this congestion.) To find out more about Leafnode, and whether it is right for your particular installation, see the resources section at the end of this document.

Caching options:

• Advantages of cache options - Whenever you are able to store a document (such as a web page or news article,) or a data object (such as a name to IP resolution,) locally, this allows your gateway to service your request locally, thus reducing the amount of traffic across your WAN (PPP) connection. This is a good thing, because the apparent speed with which your request is serviced is greatly increased, while the WAN connection is left available for other requests and tasks. Additionally, if you have the disk space for it, spooling your own news is a great idea as well. This allows local network access to your Usenet spool, and keeps the download (usually called a fetch or suck because it sucks up all your bandwidth,) on the local net, and off the WAN.
• Disadvantages of cache options - However, there is a tradeoff involved here. This type of caching works best for documents and data that are considered "static" or infrequently changed. Depending on the expiry parameter set for your caching service (the amount of time a document or object resides locally on your machine before it is considered "stale" and deleted,) you may find yourself looking at "yesterday's news." This is primarily a concern in the web caching area, less so in the news although your articles will not be refreshed in "real time", and negligible in the nameserver.
• Configuration of a caching only name server - BIND may or may not be installed on your machine already, depending on your choices at installation time. If your distribution does not contain BIND version 8.1.x or greater, I strongly recommend you upgrade. The 4.x.x version are no longer in development, and the added features included in the 8.x.x version, such as dynamic zone transfers, and simplified configuration, make it worth the upgrade. See the resources section for the URL of the Internet Software Consortium (ISC) which develops and maintains BIND.

First, you will need a directory called /var/named. If it is not already there, create it.

Next, you will need a file containing listings of all the root servers, and a file that serves as your local information, or "zone" file. These files should be named root.cache, and 127.0.0, respectively. Examples of these two files may be found in the DNS-HOWTO, or the Cricket book listed in the resources section.

Finally, you will need a named.conf file, which passes the start up options to BIND. For a caching nameserver, it should look something like the following:

// Config file for caching only name server
options {
directory "var/named";
//Uncomment the line below if you are behind a
//firewall, and you can?t get things to work:
// query-source port 53;
};
zone "." {
type hint;
file "root.cache";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0";
};
// End Config file example

Those of you who are familiar with the C/C++ programming language will notice the similarity of the syntax of the named.conf file.

Briefly, the first section delineates the working directory, the second section tells the resolver where to look for the root servers file, and the last section is your "zone" file. This file should live in the /etc directory.

Finally, edit your resolv.conf file on the gateway machine to point first to itself, then to your ISP for name resolution:

search home.net
nameserver 127.0.0.1
nameserver <your ISP primary DNS>
nameserver <your ISP secondary DNS>

Then finish up by pointing all your home.net clients to the gateway for resolution:

search home.net
nameserver 192.168.1.1

RedHat 5.x - when you install the RPM, it automagically should install as a caching server. If not, then see above for the required files and proper named.conf examples.

General tips and tricks:

• Late night cron tricks - Cron (short for chronometer,) is a more user friendly (supposedly ;-)) front end to the at daemon. This daemon allows the unattended execution of scripts and commands on precise days at specific times. This is very handy for automating many of the drudge tasks inherent on a UNIX box, such as log rotation, ftp jobs, or in our case, news and caching server functions. This information is contained in files called crontab files. There may or may not be more than one of these files present on your system, depending on how it was set up at installation, and how many users you may have. This file or files live in the /var/spool/cron/crontabs directory.
• Automating function's with cron - To edit, or add an entry in the crontab file, use the command - crontab -e <return>. Once the file is open, entries are made in the format <minutes> <hours> <days> <weeks> <months> commands. Null entries are represented by an asterix (*). For an example, you will probably want to schedule your leafnode newsfeeds, as well as any extensive cache downloads in the early hours of the morning when you have the least amount of users on the system. To start the newsfeed (fetch) every morning at 4:00 a.m., the entry would be:

• Calling scripts from cron - There will be times when you want to execute a series of commands, or pass many options to one or more commands, and entering them over and over at the command line becomes a bummer. Enter shell programming. This is nothing more than a file that contains a series of commands to be executed, then exited after the last command is done. This is handy for any number of things. Indeed, the unicom file from last month is a shell script. As an example, say you wanted to remove your wtmp file, and create a new one every hour. The script for this might look something like:

Shell scripts can be created using any of the many text editors available on your Linux system. Let?s say we named this file wtmpclean. To make it executable by the system, simply issue the chmod command:

chmod +x wtmpclean

To call this script from cron, and have it run every hour, your crontab entry would be something like:

0 * * * * /usr/sbin/wtmpclean

• Browser cache settings - Netscape has a feature that allows you to adjust the size and behavior of your browser?s disk and memory cache. These are areas set aside on your disk and in RAM to "keep" your most recently requested browser objects, like an html page, a .gif or .jpg file, etc. To adjust these settings, from the Netscape menu bar choose Edit/Preferences/Advanced/Cache, Subject to RAM and disk space limitations, you can increase/decrease the size of your Disk and Memory cache, and choose how frequently your browser will go out across the WAN to compare the document in the cache to the document at it?s original location. Keep in mind the limitations mentioned previously. This is probably best set to "Once per session" unless you are trading stocks or something that requires frequent updates.
• Tweaking your modem - Most modems have extra features available that may or may not improve the performance and behavior of your modem. Check the manufacturer?s documentation and experiment.
• Data line conditioning - For a small additional monthly charge, you can have the phone company "condition" your line, or optimize it for data versus voice communications. This may or may not be useful to you, it is usually most helpful if you are in a rural area, or some other area that experiences excessive static or degradation of line quality.

Other:
Pppd man pages
Cron man pages
Leafnode man pages
PPP HOW-TO
SERIAL HOW-TO
DNS-HOWTO

Resources for further information:
Web Resources:
http://www.redhat.com/
http://www.slackware.com/
http://metalab.unc.edu/LDP/
http://www.linuxresources.com/
http://metalab.unc.edu/
http://www.isc.org/
http://www.apache.org/
Squid Software:
http://squid.nlanr.net
Leafnode Software:
http://wpxx02.toxi.uni-wuerzburg.de/~krasel/leafnode.html
Netwatch software:
ftp://ftp.slctech.org/pub/

Newsgroups:
alt.unix.wizards
comp.security.unix
comp.unix.admin
alt.os.linux.slackware
comp.os.linux.networking
comp.os.linux.hardware
linux.redhat.misc

Print Materials:
DNS and BIND (The Cricket Book) - 2^nd edition (O?Reilly & Associates)

As always, I?ve ran way long this month. Look for the Advanced Services information next month.

Linux Installation Primer #1, September 1998
Linux Installation Primer #2, October 1998
Linux Installation Primer #3, November 1998
Linux Installation Primer #4, December 1998
Linux Installation Primer #5, January 1999
Linux Installation Primer #6, February 1999