SourceFiles.org - Use the Source, Luke
Home | Register | News | Forums | Guide | MyLinks | Bookmark

Sponsored Links

Latest News
  General News
  Reviews
  Press Releases
  Software
  Hardware
  Security
  Tutorials
  Off Topic


Back to files

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN//3.0"> <HTML>
<HEAD>
<CENTER>
<TITLE>IRQTUNE -- A Linux IRQ Priority Optimizer</TITLE> </CENTER>
</HEAD>
<BODY>
<P><P>
<CENTER>
<HR>
<H1>
<A NAME="__irqtune_0__"><EM>IRQTUNE</EM> -- A Linux IRQ Priority Optimizer</A> </H1>
</CENTER>
<CENTER>
<EM>
Copyright 1996, 1997 by Craig Estey.
<BR>
<STRONG>
irqtune version 0.6
</STRONG>
<BR>
Last updated: Sun Oct 19 16:35:00 PDT 1997 <BR>
See the <A HREF="__irqtune_66__">Changes</A> section at the bottom of this document. <BR>
<A HREF="
__irqtune_72__">Table of Contents</A> </EM>
</CENTER>
<P>
<EM>irqtune</EM> changes the IRQ priority of devices to allow devices that require high priority and fast service (e.g. serial ports, modems) to have it. <P>
<STRONG>
With <EM>irqtune</EM>, a 3X speedup of serial/modem throughput is possible. </STRONG>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_1__">Where do I get <EM>irqtune</EM>?</A> </H1>
<EM>irqtune</EM> is free software under the terms and conditions of the GNU Public License. See the file COPYING, included in the distribution, for details. <P>
<UL>
<LI>
The author is Craig Estey, (<A HREF="MAILTO:cae@best.com">cae@best.com</A>). <P>
<LI>
This FAQ is available online via
<A HREF="http://www.best.com/~cae/irqtune">http://www.best.com/~cae/irqtune</A>;. This is the most authoritative reference and will always contain the most up-to-date information. <P>
<LI>
The distribution is a gzipped tar archive that contains all programs, sources, and this FAQ (in both HTML and text versions). It is available from: <P>
<UL>
<LI>
<A HREF="http://www.best.com/~cae/irqtune/irqtune.tgz">http://www.best.com/~cae/irqtune/irqtune.tgz</A>; <BR>
<LI>
<A HREF="ftp://shell5.ba.best.com/pub/cae/irqtune.tgz">ftp://shell5.ba.best.com/pub/cae/irqtune.tgz</A> <BR>
</UL>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_2__">How do I know if I need <EM>irqtune</EM>?</A> </H1>
<STRONG>You are running Linux on an x86 PC, other architectures to be implemented</STRONG> <STRONG>later--Sorry.</STRONG>
<P>
<STRONG>
You probably need <EM>irqtune</EM>, if you are experiencing any of the following: </STRONG>
<P>
<UL>
<LI>
SLIP/PPP transfers seem slow. For example, using a 28.8 (or better) modem, the effective throughput is approximately 700 bytes/second instead of the expected 2500 bytes/second.
<P>
<LI>
A running serial or SLIP/PPP connection is slow, drops data, hangs, or times out.
<P>
<LI>
Netscape hangs mysteriously or stalls when trying to access a web page. <P>
<LI>
Equivalent serial/PPP programs under Windoze run much faster than under Linux. <P>
<LI>
Disk accesses seem to interfere with SLIP/PPP. <P>
<LI>
Interrupt handlers for specialized, time critical devices don't get control when they need to.
<P>
</UL>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_3__">What is actually happening to cause these problems?</A> </H1>
<P>
When the PC boots Linux, the timer is
given, by default, the highest IRQ priority in the system (it's IRQ 0 and thus, priority 0). On a standard configuration, the serial ports are priority 11 and 12!!! This means that 10 other devices have higher priority. <P>
<P><P>
<H3>
<A NAME="__irqtune_4__">Q: So what does IRQ priority do?</A> </H3>
<P>
When multiple devices are in contention to interrupt the CPU, their priority decides which interrupts will occur in what order. <P>
<P><P>
<H3>
<A NAME="__irqtune_5__">Q: When does this contention occur?</A> </H3>
<P>
After an arbitrary period of having interrupts disabled (e.g after a <EM>cli</EM>), at the point where they're reenabled (<EM>sti</EM>). This can happen in several places:
<P>
<UL>
<LI>
In an ISR that runs with interrupts locked, it happens in the <EM>epilog</EM>, just before attempting to execute the <EM>bottom-half</EM>. <P>
<LI>
The <EM>bottom-half</EM> itself may do a lock and unlock. <P>
<LI>
When a task that enters the kernel to do a system call, the system call handler may lock and unlock interrupts briefly. <P>
<LI>
Almost anywhere in the kernel are brief periods where it does a <EM>cli</EM> to lock interrupts and then an <EM>sti</EM> to unlock them again. <P>
<LI>
Under Linux, from the moment the first instruction of the ISR <EM>prolog</EM> is executed until an <EM>sti</EM> is done (This occurs even in <EM>slow</EM> interrupts where the <EM>prolog</EM> does an <EM>sti</EM> after just a few instructions). <P>
</UL>
<P><P>
<H3>
<A NAME="__irqtune_6__">Q: If there are multiple interrupts now pending, which one gets the service, the serial or some other?</A> </H3>
<P>
In the default configuration, the serial ISR will usually lose as it's priority 11.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_7__">How does irqtune help this?</A> </H1>
<P>
<EM>irqtune</EM> gives priority 0 to whatever device we specify. If we specify
a serial device, <EM>irqtune</EM> guarantees that the serial ISR gets control whenever a contention occurs.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_8__">Why does the serial interrupt service require the highest priority?</A> </H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_9__">Q: Why does the serial device merit such special treatment?</A> </H3>
<P>
Serial devices are somewhat unique. Even though they have one of the slowest data rates (relative to a disk), they are the largest consumer of interrupts and are extremely sensitive to <EM>interrupt latency</EM> (the time from when a device yanks the IRQ line until its ISR is executed). <P>
<P><P>
<H3>
<A NAME="__irqtune_10__">Q: Could you give a concrete example of this?</A> </H3>
<P>
<UL>
<LI>
For a modem running at 33.6, we can have a peak maximum (with compression) of 6700 bytes/second. The serial driver programs the silo to interrupt after 8 bytes, leaving a latency window of 8 bytes. This means that when the serial port yanks its IRQ line, it can still absorb 8 more characters before its buffer will overflow and data will be dropped <P>
<LI>
In terms of time, this means that the maximum that the serial ISR may be delayed is
(8 / 6700) seconds or 1194 microseconds. It also means that the serial ISR will require 838 interrupts/second.
<P>
<LI>
Currently there are 52 devices that install their ISR with the SA_INTERRUPT option.
This means that they wish to run with interrupts disabled. I have not looked at all the devices, but just assume for the moment that all will run with interrupts locked for an arbitrary period.
<P>
<LI>
Assume we've got 4 of them pending (remember, at <EM>higher</EM> priority). Assume that they will lock interrupts individually for 320, 300, 190, and 500 microseconds, respectively. Assume that the serial ISR also wants an interrupt.
<P>
<LI>
This means that the serial ISR will have to wait for (320 + 300 + 190 + 500) or 1310us
for these other higher priority ISR's to run to completion. This is greater than the maximum of 1194 us.
<P>
<LI>
With internal
modems, we probably just see start/stop behavior causing a slowdown. With an external modem, <STRONG>data will be dropped</STRONG>. This will cause PPP to see a CRC error and request transmission. Remember, the <EM>entire</EM> packet must be retransmitted, which means we just wasted 296-1500 bytes (depending on the selected MRU).
With an MRU of 1500 bytes, we just
wasted 23.4% of the bandwidth in a given second--all for the loss of a single byte!
<P>
<LI>
Worse yet, consider a 115 Kbps ISDN card that is masquerading as a serial device <EM>(Yes, I know it should be a DMA device)</EM>. In this case, the maximum delay the serial ISR can wait is 695 us. And that's just one ISDN channel. Try adding the other and, well, <EM>golly :-)</EM>. <P>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_11__">Q: In this example, how would boosting serial IRQ priority help?</A> </H3>
<UL>
<LI>
If the serial IRQ had priority 0, it would get in <EM>before</EM> the others. It could also <STRONG>re-interrupt</STRONG> after any individual lockout window. Thus, the maximum
it would be forced to wait would be largest individual time, not the <STRONG>summation</STRONG> of all of these times. In this example, this means 500 us. which is now within the 1194 us. maximum for the serial ISR. <P>
<LI>
It has been my experience that the serial device <STRONG>must always</STRONG> win these battles for contention. When serial devices don't get what they <EM>need</EM>, when they need it, they slow horribly or drop data outright. <P>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_12__">Isn't that example very <EM>unlikely</EM> under Linux?</A> </H1>
<P>
<EM>Unlikely</EM> doesn't mean never. There are places were the contention period <STRONG>must</STRONG> occur, no matter how we program the CPU. <P>
Variations in CPU speed,
RAM size, RAM speed, cache size, disk speed, disk rotational position, number and type of other devices, system workload, etc, etc etc, all contribute to variations of order and timing of internal OS events. <P>
<EM>Unlikely</EM> on one system may mean 1/1000th % chance. On another system, it may mean <EM>happens 50 times/second</EM>. Beyond a certain point, it all comes down to <EM>measurement</EM>.
<P>
Tight, accurate, repeatable measurement is the key to system tuning. If we can't measure it, we can't tune it. Once we <EM>can</EM> measure
these things, we can then <EM>try</EM> various combinations until we achieve our desired results. It can often be pointless to guess at performance. <P>
In fact, the interrupt disable windows themselves are used to prevent data corruption caused by various parts of the kernel that try to update a data structure simultaneously and get corrupted. Many of these windows are put there in the <EM>unlikely</EM> case that such corruption would occur. In this context, <EM>unlikely</EM> is <STRONG>never</STRONG> considered a reason to forego interrupt locking. Eliminating a necessary interrupt lock window could result in kernel panics, RAM corruption, disk data corruption, etc. <P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_13__">Doesn't this hurt the performance of other devices?</A> </H1>
<P>
<STRONG>Not really</STRONG>.
<P>
In actual practice, most devices don't even notice the difference. Most other
devices (e.g. disks, tape, ethernet) are <EM>DMA</EM> devices. The <EM>DMA</EM> does most of the work, thus greatly reducing their need for interrupts. If the device allows a request queue, it may function autonomously on several requests, producing only one interrupt for the entire batch. <P>
Furthermore, serial interrupt services are, themselves, <EM>very</EM> fast. They slam their data as quickly as possible and get out ASAP. No fancy calculations, just the minimum, mindless data transfer. Almost everything else is handled later, in the <EM>bottom-half</EM> with interrupts enabled. In fact, a serial ISR may have to re-interrupt it's own <EM>bottom-half</EM> several times.
<P>
Those devices that
<EM>do</EM> experience some slight slowdown are more likely to have long interrupt disable windows themselves. Having several smaller <EM>cli/sti</EM> windows is much better than one large <EM>cli/sti</EM> window--It's just harder to program. <P>
<P><P>
<H3>
<A NAME="__irqtune_14__">Q: But suppose I want a balanced priority system?</A> </H3>
<P>
Well, actually a <EM>prioritized</EM> system behaves like a <EM>balanced</EM> system--most of the time. This occurs when all devices have short interrupt lockout windows and short ISR execution times. The priority mechanism is like a safety valve--it only really matters when some device or combination of devices has held interrupts locked for an extended period of time. <P>
<P><P>
<H3>
<A NAME="__irqtune_15__">Q: But doesn't that seem <EM>unfair</EM> to other devices?</A> </H3>
<P>
When a disk ISR gets delayed,
that's all that happens, a slight delay--disks and tapes are <STRONG>not</STRONG> real-time devices. When a serial ISR gets delayed, data is destroyed--serial devices <STRONG>are</STRONG> real-time devices that dictate the cadence of the entire system. <P>
<STRONG>
It may sound cruel, but you just can't be <EM>fair</EM>. </STRONG>
<P>
And speaking of sound, if the sound card gets delayed, we hear an annoying pop right in the middle of our favorite piece of music. <P>
These are real-time devices that can <STRONG>not</STRONG> tolerate excessive delays. If we must defer some less time critical devices to meet the minimum real-time criteria of devices, then that's a bargain. <P>
<P><P>
<H3>
<A NAME="__irqtune_16__">Q: But suppose I really want both fast serial and fast disk?</A> </H3>
<P>
Ultimately, it's a bit of a compromise. Which is better: <BR>
<UL>
<LI>
Reliable serial and <EM>slightly</EM> slower disk. <BR>
<LI>
<EM>Slightly</EM> faster disk and <EM>unreliable</EM> serial/modem support. <BR>
</UL>
<EM>
When paying an ISP for Internet access in $$$/hour, it's an easy decision :-). </EM>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_17__">Isn't this IRQ priority thing a bit of a new idea?</A> </H1>
<P>
No. It's actually an old idea. I've been doing device drivers since 1977 and Unix kernel work since 1981. I've personally written 8 serial drivers have used this many times commercially. Giving the serial device the highest priority is actually standard practice in many systems. <EM>With a 4Mhz CPU, these problems used to occur at 1200 baud :-)</EM> <P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_18__">How do I install <EM>irqtune</EM>?</A> </H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_19__">Q: Where should I place <EM>irqtune</EM> files?</A> </H3>
<UL>
<LI>
Decide what directory you would like to <STRONG>contain</STRONG> <EM>irqtune</EM>'s home directory.
Some good choices are:
<STRONG>/usr/local</STRONG>,
<STRONG>/usr/lib</STRONG>,
<STRONG>/usr/lib/hwtools</STRONG>,
<STRONG>/home</STRONG>.
<BR>
<LI>
Exactly where depends upon your local conventions. <BR>
<LI>
In this example, we'll use <STRONG>/usr/local</STRONG>. <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_20__">Q: How do I unpack the archive?</A> </H3>
<UL>
<LI>
Go to the containing directory.
<BR>
<CODE>
cd&nbsp;/usr/local
<BR>
</CODE>
<LI>
Unpack the tar file:
<BR>
<CODE>
tar&nbsp;zxvf&nbsp;irqtune.tgz
<BR>
</CODE>
<LI>
This will create a directory, <STRONG>irqtune</STRONG> in <STRONG>/usr/local</STRONG>. This is <STRONG>/usr/local/irqtune</STRONG>. We will call this <STRONG>IRQTUNE_HOME</STRONG>. <BR>
</UL>
<P>
<EM>
Note: If tar's
</EM>
<STRONG>z</STRONG>
<EM>
option has problems:
</EM>
<BR>
<UL>
<LI>
An alternate unpack command:
<BR>
<CODE>
gzip&nbsp;-d&nbsp;&#60;&nbsp;irqtune.tgz&nbsp;|&nbsp;tar&nbsp;xvf&nbsp;- <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_21__">Q: How do I do a simple installation?</A> </H3>
<UL>
<LI>
Go to the <STRONG>IRQTUNE_HOME</STRONG> directory: <BR>
<CODE>
cd&nbsp;/usr/local/irqtune
<BR>
</CODE>
<LI>
To install <EM>irqtune</EM>, enter:
<BR>
<CODE>
make&nbsp;install
<BR>
</CODE>
<LI>
This will install the files:
<BR>
<CODE>
/sbin/irqtune
<BR>
/sbin/irqtune_mod.o
<BR>
/sbin/irqtune_npr.o
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_22__">Q: Why are .o files being placed in the /sbin directory?</A> </H3>
<P>
<EM>
As a note to purists, the installation directory is completely arbitrary. <STRONG>/sbin</STRONG> is short, sweet, and easy to type. </EM>
<P>
The standard convention would be to install <STRONG>irqtune</STRONG> as <STRONG>/sbin/irqtune</STRONG> and the .o files as, say, <STRONG>/usr/lib/irqtune/*.o</STRONG>. <EM>irqtune</EM> uses a slightly different convention. It wants all installed files to be in the same directory.
This works fine because argv[0] will
point to the .o files. This also allows: <BR>
<UL>
<LI>
Multiple versions of <EM>irqtune</EM> to be installed simultaneously (in different directories).
<BR>
<LI>
Simplifies testing of new versions.
<BR>
<LI>
Provides better assurance that the built version is correct. <BR>
<LI>
Using one directory produces less clutter. <BR>
<LI>
One directory is more portable across all the myriad kernel revisions. <BR>
<LI>
Future versions of <EM>irqtune</EM> may imbed the .o's directly into <STRONG>irqtune</STRONG>. <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_23__">Q: What if I really don't want .o files in <STRONG>/sbin</STRONG>?</A> </H3>
<P>
If placing .o files in <STRONG>/sbin</STRONG> is deemed to be an anathema, we have two options:
<BR>
<UL>
<LI>
Simply use another directory in place of <STRONG>/sbin</STRONG>: <BR>
<CODE>
make&nbsp;SBIN=/whatever&nbsp;install
<BR>
</CODE>
<LI>
Install with a stub (This will install /sbin/irqtune as a shell script and use <STRONG>IRQTUNE_HOME</STRONG>/sbin/irqtune_.o): <BR>
<CODE>
make&nbsp;INSTALL=sh&nbsp;install
<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_24__">Q: Are there any special considerations for this alternate installation method?</A> </H3>
<P>
Yes. If the shell/stub installation method is used: <BR>
<UL>
<LI>
<STRONG>IRQTUNE_HOME</STRONG> must not be removed. <BR>
<LI>
If using <EM>irqtune</EM> from an /etc/rc.d/rc.
file <STRONG>and</STRONG> <EM>irqtune</EM> will be invoked <STRONG>before</STRONG> secondary mounts are done, <STRONG>IRQTUNE_HOME</STRONG> should be placed on the root device.
<BR>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_25__">How do I use <EM>irqtune</EM>? Don't I have to rebuild my kernel?</A> </H1>
No, we do <STRONG>not</STRONG> have to rebuild the kernel. <EM>irqtune</EM> uses <EM>insmod</EM> and
<EM>rmmod</EM> to dynamically load and unload a kernel module. But it is correct to sense that irqtune is a kernel patch. <P>
<P><P>
<H3>
<A NAME="__irqtune_26__">Q: Ok, if it's a kernel patch, why not just issue a kernel patch like everybody else does (e.g. diff -u output)?</A> </H3>
<P>
<EM>irqtune</EM> will work even if we don't have the kernel source loaded. It uses <EM>insmod</EM> to load the patch, invoke it, and then unload it. The IRQ priority changes will last so long as the kernel is booted. <P>
<P><P>
<H3>
<A NAME="__irqtune_27__">Q: How do we invoke it?</A> </H3>
<P>
<EM>irqtune</EM> takes two arguments optional arguments: <BR>
<UL>
<LI>
irqtune <EM>master</EM> <EM>slave</EM>
<BR>
</UL>
The default is <EM>3 14</EM> which will work for many standard configurations. See <A HREF="__irqtune_31__">What about my non-standard hardware configuration?</A> for details. <BR>
<UL>
<LI>
Here is the usage output from irqtune:
<BR>
<CODE>
usage:&nbsp;irqtune&nbsp;[options]&nbsp;[master]&nbsp;[slave] <BR>
version:&nbsp;0.6
<BR>
arguments:
<BR>
&nbsp;&nbsp;master&nbsp;--&nbsp;high&nbsp;priority&nbsp;IRQ&nbsp;on&nbsp;PIC&nbsp;master&nbsp;(DEFAULT:&nbsp;3) <BR>
&nbsp;&nbsp;slave&nbsp;--&nbsp;high&nbsp;priority&nbsp;IRQ&nbsp;on&nbsp;PIC&nbsp;slave&nbsp;(DEFAULT:&nbsp;14) <BR>
general&nbsp;options:
<BR>
&nbsp;&nbsp;-h&nbsp;--&nbsp;display&nbsp;help <BR>
&nbsp;&nbsp;-v&nbsp;--&nbsp;display&nbsp;irqtune&nbsp;version <BR>
&nbsp;&nbsp;-o&nbsp;--&nbsp;reset&nbsp;to&nbsp;original&nbsp;values&nbsp;(0/8) <BR>
priority&nbsp;table&nbsp;options:
<BR>
&nbsp;&nbsp;-q&nbsp;--&nbsp;suppress&nbsp;priority&nbsp;table&nbsp;printing <BR>
&nbsp;&nbsp;-s&nbsp;--&nbsp;sort&nbsp;table&nbsp;by&nbsp;priority <BR>
&nbsp;&nbsp;-x&nbsp;--&nbsp;show&nbsp;inactive&nbsp;devices&nbsp;in&nbsp;table <BR>
error&nbsp;control&nbsp;options:
<BR>
&nbsp;&nbsp;-e&nbsp;--&nbsp;show&nbsp;full&nbsp;errors <BR>
&nbsp;&nbsp;-f&nbsp;--&nbsp;force&nbsp;loading&nbsp;even&nbsp;if&nbsp;probe&nbsp;detects&nbsp;errors <BR>
&nbsp;&nbsp;-u&nbsp;--&nbsp;force&nbsp;module&nbsp;unload <BR>
&nbsp;&nbsp;-V&nbsp;--&nbsp;insmod&nbsp;verbose&nbsp;mode <BR>
&nbsp;&nbsp;-w&nbsp;--&nbsp;treat&nbsp;warnings&nbsp;as&nbsp;errors <BR>
documentation&nbsp;options:
<BR>
&nbsp;&nbsp;-F&
60;file&#62;&nbsp;--&nbsp;use&nbsp;&#60;file&#62;&nbsp;instead&nbsp;of&nbsp;/proc/interrupts <BR>
&nbsp;&nbsp;-i&nbsp;--&nbsp;install&nbsp;program <BR>
&nbsp;&nbsp;-L&#60;directory&#62;&nbsp;--&nbsp;directory&nbsp;to&nbsp;search&nbsp;for&nbsp;insmod <BR>
&nbsp;&nbsp;-n&nbsp;--&nbsp;nogo&nbsp;mode&nbsp;(just&nbsp;show&nbsp;what&nbsp;would&nbsp;happen) <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_28__">Q: Could we do this from my /etc/rc.d/rc.local file?</A> </H3>
<P>
Yes. Just add a <STRONG>/sbin/irqtune</STRONG> line to this file and we're in business.
We may also issue another <EM>irqtune</EM> command at any time. <P>
<P><P>
<H3>
<A NAME="__irqtune_29__">Q: What if irqtune fails to load?</A> </H3>
See the <A HREF="__irqtune_42__">What about <EM>irqtune</EM> load failures or incompatibilities with kernel revisions?</A> section. <P>
<P><P>
<H3>
<A NAME="__irqtune_30__">Q: After <EM>irqtune</EM> sets a priority, how can we query the results later?</A> </H3>
<P>
<STRONG>
We can't.
</STRONG>
<P>
Due to a limitation of the PC interrupt hardware, it is <STRONG>not</STRONG> possible to read back values set previously.
<P>
<EM>irqtune</EM> will attempt to place a message in the system log (/usr/spool/syslog/syslog) when it changes the configuration. Examining this log file, or simply invoking <EM>irqtune</EM> again, may be the best ways to work around the hardware limitations. <P>
<EM>
Note: Some users have tried to use the "-n" option, thinking it will act as a "query" mode. This option is used, primarily, to generate examples in this document and will not have the desired effect. </EM>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_31__">What about my non-standard hardware configuration?</A> </H1>
<EM>irqtune</EM> defaults for a standard IRQ configuration. It assumes that the highest priority device should be on IRQ 3. This is normally the first serial port on standard configurations, which is what you want. <P>
<P><P>
<H3>
<A NAME="__irqtune_32__">Q: How do I determine what my IRQ configuration is?</A> </H3>
<P>
<EM>
NOTE: For brevity, we've combined the non-sorted and sorted output in these examples.
</EM>
<BR>
<UL>
<LI>
Just type <STRONG>/sbin/irqtune -n -o</STRONG> and we'll get something like: <BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P00:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P00:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P01:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P01:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P02:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P02:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P10:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I11/P05:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P11:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I12/P06:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I11/P05:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I12/P06:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P10:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P11:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<EM>
NOTE:
<STRONG>/proc/interrupts</STRONG>, and therefore irqtune, only reports on active devices. So to scope out
the serial IRQ's, ideally, you'd have X Windows up with your serial mouse and be connected via PPP to the net.
</EM>
<P>
<P><P>
<H3>
<A NAME="__irqtune_33__">Q: OK, we've got the output from /sbin/irqtune -n -o, what do we do with it?</A> </H3>
<P>
The leftmost number is the IRQ number. The next number is the priority. The rightmost column is the <STRONG>internal</STRONG> device name (not to be confused with /dev names). In the above case, the two serial ports are on IRQ 3 and IRQ 4. Just use the lower number, in this case 3:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM> <BR>
</UL>
This sets IRQ 3 to the highest priority. <P>
<UL>
<LI>
After this command, the IRQ priorities are now: <BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I11/P12:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I12/P13:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I11/P12:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I12/P13:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_34__">Q: BTW, What's the cascade device I saw in the output of irqtune?</A> </H3>
<P>
Glad you asked. There are actually two interrupt controllers, a <EM>master</EM> and a <EM>slave</EM>. The <EM>slave</EM> is <EM>cascaded</EM> to the <EM>master</EM> via its IRQ 2. The <EM>master</EM> controls IRQ's 0-7 and the <EM>slave</EM> controls IRQ's 8-15. <P>
You actually may select two high IRQ priorities, one for the <EM>master</EM> and one for the <EM>slave</EM>. <EM>irqtune</EM> defaults the <EM>slave</EM> to IRQ 14, which is normally the disk controller.
<P>
In fact, <EM>cascade</EM> is sort of a "zero width" device as it does not contribute to interrupt latency. Setting the <EM>cascade</EM> to top priority on the <EM>master</EM> has an interesting effect which we'll see shortly. <P>
<P><P>
<H3>
<A NAME="__irqtune_35__">Q: But we've also got an Ethernet controller on IRQ 12. What about that?</A> </H3>
<P>
In this case, we might want to use:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3 12</EM> <BR>
</UL>
because we want our ethernet card to have a higher priority than the disk controller. Actually if we did have this configuration, setting 3 14 (the default) would make the ethernet card, the lowest priority device in the system.
<P>
<UL>
<LI>
The resulting priority would be:
<BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I11/P14:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I12/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I12/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P09:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P09:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I11/P14:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_36__">Q: What about the serial multiplexer card on IRQ 11?</A> </H3>
<P>
This is a bit tricky because now we've got a serial device on the <EM>slave</EM> controller. It would be much better to put all serial cards on the <EM>master</EM> controller. Things would stay much simpler. <P>
In this case we would want to use:
<BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>11</EM> <BR>
<LI>
The resulting priorities would be more complex and would result in something like:
<BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P13:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P14:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I11/P00:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I12/P01:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P02:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P09:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P03:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I11/P00:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P08:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I12/P01:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P09:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P02:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P13:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P03:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P14:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_37__">Q: Wait a minute. didn't we just specify a <EM>slave</EM> IRQ number as the <EM>master</EM> to <EM>irqtune</EM>?</A> </H3>
<P>
Yes, this is shorthand way of saying <EM>2 11</EM>. You can make a <EM>slave</EM> device top priority, but we get no options for the <EM>master</EM> IRQ. It will always be <EM>2</EM>, the <EM>cascade</EM> device. Remember, the <EM>cascade</EM> device contributes no latency delay by itself. <P>
<P><P>
<H3>
<A NAME="__irqtune_38__">Q: So why is this configuration so bad?</A> </H3>
<P>
Well, we boosted the priority of the serial multiplexer at the expense of the regular serial ports. The only way to allow all serial ports equally high priority is to group them on consecutive IRQ's and set the high priority for the lowest of those IRQ's.
<P>
<P><P>
<H3>
<A NAME="__irqtune_39__">Q: How can we fix this with software?</A> </H3>
<P>
<STRONG>
We can't.
<P>
We're limited by the architecture of the PC and its interrupt controllers. We must change the IRQ of a device by physical restrapping--we can't do it by reprogramming the priority alone. </STRONG>
<P>
We'll go back to the earlier example. We'll wave a magic wand and <EM>Poof!</EM>--assume we just restrapped the serial multiplexer to IRQ 5: <BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM> <BR>
<LI>
The resulting priorities would be:
<BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I05/P02:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I05/P02:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I12/P13:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I12/P13:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_40__">Q: Could we do more of this restrapping, say, with the ethernet controller?</A> </H3>
<P>
Sure. Waving the wand again, we restrap the ethernet card to IRQ 6. <BR>
<UL>
<LI>
<STRONG>/sbin/irqtune</STRONG> <EM>3</EM> <BR>
<LI>
The resulting priorities would be:
<BR>
<CODE>
SORTED&nbsp;BY&nbsp;IRQ:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SORTED&nbsp;BY&nbsp;PRIORITY:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I05/P02:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I06/P03:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I05/P02:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I06/P03:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_41__">So in order to get the best overall system, we may need to change IRQ priority <EM>and</EM> physically change the hardware IRQ configuration?</A> </H3>
<P>
<STRONG><EM>Exactly</EM></STRONG>.
<P>
Different systems may have highly different criteria for what is optimum. It is, ultimately, a choice that each system administrator must make based upon the specific requirements for the particular system in question. We can only provide tools to do the job, but the final choice is ultimately decided on a case-by-case basis. There is no <EM>
one size fits all
</EM>
solution.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_42__">What about <EM>irqtune</EM> load failures or incompatibilities with kernel revisions?</A> </H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_43__">Q: What's the bottom line?</A> </H3>
<P>
<EM>irqtune</EM> makes every attempt to load its kernel module. <EM>irqtune</EM> probes the kernel, /proc/ksyms, and <EM>insmod</EM>. It attempts to detect, correct, or work around any difficulties. If the problems are truly severe, <EM>irqtune</EM> will report this also. Normally, <EM>irqtune</EM> probes silently, only reporting the results of the local system configuration if there's an non-recoverable error. <P>
<UL>
<LI>
To show what <EM>irqtune</EM> actually checks for each time it's invoked, here is the full error output (-e) from irqtune: <BR>
<CODE>
irqtune:&nbsp;version&nbsp;is&nbsp;0.6
<BR>
irqtune:&nbsp;kernel&nbsp;version&nbsp;2.0.30 <BR>
probe:&nbsp;irqtune&nbsp;must&nbsp;be&nbsp;invoked&nbsp;via&nbsp;the&nbsp;full&nbsp;path&nbsp;--&nbsp;OK <BR>
probe:&nbsp;/sbin&nbsp;in&nbsp;$PATH&nbsp;--&nbsp;YES <BR>
probe:&nbsp;insmod&nbsp;found&nbsp;in&nbsp;$PATH&nbsp;(/sbin)&nbsp;--&nbsp;OK <BR>
probe:&nbsp;insmod&nbsp;simple&nbsp;execution&nbsp;--&nbsp;OK <BR>
probe:&nbsp;insmod&nbsp;has&nbsp;version&nbsp;(2.0.0)&nbsp;--&nbsp;YES <BR>
probe:&nbsp;rmmod&nbsp;found&nbsp;in&nbsp;insmod&nbsp;directory&nbsp;--&nbsp;OK <BR>
probe:&nbsp;insmod&nbsp;version&nbsp;supports&nbsp;command&nbsp;line&nbsp;options&nbsp;--&nbsp;OK <BR>
probe:&nbsp;insmod&nbsp;version&nbsp;(2.0.0)&nbsp;compatible&nbsp;with&nbsp;kernel&nbsp;version&nbsp;(2.0.30)&nbsp;--&nbsp;OK <BR>
probe:&nbsp;insmod&nbsp;version&nbsp;should&nbsp;be&nbsp;2.1.34&nbsp;(or&nbsp;better)&nbsp;--&nbsp;WARNING <BR>
probe:&nbsp;insmod&nbsp;and&nbsp;kernel&nbsp;compatible&nbsp;with&nbsp;CONFIG_MODVERSIONS&nbsp;--&nbsp;OK <BR>
probe:&nbsp;irqtune_mod&nbsp;loading&nbsp;will&nbsp;be&nbsp;tried&nbsp;--&nbsp;OK <BR>
probe:&nbsp;kernel&nbsp;version&nbsp;irqtune&nbsp;built&nbsp;under&nbsp;(1.0.0)&nbsp;matches&nbsp;current&nbsp;system&nbsp;--&nbsp;NO <BR>
probe:&nbsp;kernel&nbsp;IRQ&nbsp;handling&nbsp;is&nbsp;compatible&nbsp;--&nbsp;OK <BR>
probe:&nbsp;kernel&nbsp;has&nbsp;module&nbsp;support&nbsp;(CONFIG_MODULES)&nbsp;--&nbsp;OK <BR>
probe:&nbsp;kernel&nbsp;has&nbsp;symbols&nbsp;--&nbsp;OK <BR>
probe:&nbsp;kernel&nbsp;is&nbsp;using&nbsp;versions&nbsp;(CONFIG_MODVERSIONS)&nbsp;--&nbsp;NO <BR>
probe:&nbsp;kernel&nbsp;symbols&nbsp;are&nbsp;checksummed&nbsp;(CONFIG_MODVERSIONS)&nbsp;--&nbsp;NO <BR>
probe:&nbsp;kernel&nbsp;has&nbsp;/proc/interrupts&nbsp;--&nbsp;OK <BR>
irqtune:&nbsp;simulating&nbsp;IRQ&nbsp;priority&nbsp;of&nbsp;3/14 <BR>
I00/P05:&nbsp;&nbsp;&nbsp;8578913&nbsp;&nbsp;&nbsp;timer <BR>
I01/P06:&nbsp;&nbsp;&nbsp;&nbsp;109547&nbsp;&nbsp;&nbsp;keyboard <BR>
I02/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0&nbsp;+&nbsp;cascade <BR>
I03/P00:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;86470&nbsp;+&nbsp;serial <BR>
I04/P01:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;serial <BR>
I11/P12:&nbsp;&nbsp;&nbsp;&nbsp;197648&nbsp;+&nbsp;sermux <BR>
I12/P13:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;17968&nbsp;+&nbsp;eth <BR>
I13/P14:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;math&nbsp;error <BR>
I14/P07:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;93123&nbsp;+&nbsp;Ux4F <BR>
irqtune:&nbsp;complete
<BR>
</CODE>
<LI>
<EM>irqtune</EM> probes report <STRONG>YES/NO</STRONG> for informative messages. These may be ignored. <EM>irqtune</EM> will automatically compensate for any irregularities found.
<BR>
<LI>
<EM>irqtune</EM> probes report <STRONG>OK/WARNING</STRONG> for problems that <STRONG>may</STRONG> prevent proper operation. These may require changes to the local configuration. Generally, these may be ignored unless <EM>irqtune</EM> fails to load. <BR>
<LI>
<EM>irqtune</EM> probes report <STRONG>OK/ERROR</STRONG> for problems that <STRONG>will</STRONG> prevent proper operation. These will require changes or upgrades to the local configuration.
<BR>
<LI>
If it is believed that the probes are reporting errors when none actually exist,
the <STRONG>-f</STRONG> option may be used to force <EM>irqtune</EM> to continue anyway. <BR>
</UL>
<P>
No matter what happens with probes or loads, <EM>irqtune</EM> will report the final completion status as its last line: <STRONG>complete</STRONG> or <STRONG>error</STRONG>. <P>
<P><P>
<H3>
<A NAME="__irqtune_44__">Q: What should be checked first?</A> </H3>
<UL>
<LI>
If we did a simple installation, we must specify the full pathname, even if <EM>irqtune</EM> is placed in a directory that is in $PATH. This is required because <EM>irqtune</EM> uses argv[0] to locate its <STRONG>irqtune_mod.o</STRONG> file. <BR>
<LI>
<STRONG>/sbin</STRONG> <EM>should</EM> be in $PATH--this is the probable place for <EM>insmod</EM>. As a convenience, <EM>irqtune</EM> will add <STRONG>/sbin</STRONG> to $PATH automatically.
<BR>
<LI>
Be sure that the kernel was built with modules support (CONFIG_MODULES) enabled. <EM>irqtune</EM> will probe for and report this condition. <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_45__">Q: What if the current kernel revision is different from the kernel revision in the prebuilt modules?</A> </H3>
<P>
<STRONG>
This does not matter.
</STRONG>
<EM>irqtune</EM> is 99.44% kernel revision independent. It is almost never necessary to rebuild the prebuilt modules. If <EM>irqtune</EM> fails to load the modules, consider everything in this section carefully before rebuilding <EM>irqtune</EM>. <P>
Notes to programmers:
<BR>
<UL>
<LI>
The "kernel_version[]" does <STRONG>not</STRONG> need to match the kernel revision for a module to load successfully.
<BR>
<LI>
A module does <STRONG>not</STRONG> need MODVERSIONS to load in a MODVERSIONS kernel. <BR>
</UL>
<P>
<EM>
Rebuilding the binaries before exploring the other options is a lot like Vonnegut's <STRONG>OFF</STRONG> switch--it's comforting but not connected to anything :-) </EM>
<P>
<P><P>
<H3>
<A NAME="__irqtune_46__">Q: Are there any kernel revisions that <EM>irqtune</EM> won't work with?</A> </H3>
<P>
When <EM>irqtune</EM> was first released, some experimental changes were made to the kernel to solve the IRQ priority problem by use of a round-robin, balanced priority system that was incompatible with <EM>irqtune</EM>. These changes were ultimately removed but <EM>irqtune</EM> will not work with kernel revisions 2.0.15 to 2.0.18. <EM>irqtune</EM> will detect this condition and report an error. See the <A HREF="
__irqtune_65__">Where can I find additional documentation or downloads?</A> section. <P>
<P><P>
<H3>
<A NAME="__irqtune_47__">Q: Are there any <EM>insmod</EM> revisions that are incompatible?</A> </H3>
<P>
<EM>irqtune</EM> first trys to load <EM>irqtune_mod.o</EM> and falls back to <EM>irqtune_npr.o</EM> if it detects a load error in <EM>insmod</EM>. <P>
Some versions of <EM>insmod</EM> have severe difficulty loading modules when the kernel is using MODVERSIONS. There is a known bug in <EM>insmod</EM>: <BR>
<UL>
<LI>
2.1.X <EM>insmod</EM> prior to 2.1.34 (e.g. 2.1.23) <BR>
<LI>
2.0.X kernel
<BR>
<LI>
kernel built with CONFIG_MODVERSIONS
<BR>
</UL>
Loading <EM>irqtune_mod.o</EM> will crash <EM>insmod</EM>, partially lock up <EM>irqtune</EM>'s module. <EM>irqtune</EM> will detect this and skip the <EM>irqtune_mod.o</EM> loading entirely. <P>
Generally, we should not use an older <EM>insmod</EM> with a newer kernel (e.g. using a 2.0.X <EM>insmod</EM> on a 2.1.X kernel). <EM>irqtune</EM> will detect and report this.
<P>
If <EM>insmod</EM> still has difficulties, we may want to upgrade it to 2.1.34 (or better). Newer versions of <EM>insmod</EM> are guaranteed to be backward compatible to older kernels.
This will increase the probability that the <EM>irqtune_mod.o</EM> will load and <EM>irqtune</EM> will not have to fallback to <EM>irqtune_npr.o</EM>. Note: <EM>insmod</EM> is actually part of the <EM>modutils</EM> package. <EM>modutils</EM> under 2.0.X is called <EM>modules</EM>. See the <A HREF="#__irqtune_65__">Where can I find additional documentation or downloads?</A> section. <P>
<P><P>
<H3>
<A NAME="__irqtune_48__">Q: What is the difference between <EM>irqtune_mod.o</EM> and <EM>irqtune_npr.o</EM>?</A> </H3>
<P>
The only kernel symbol that <EM>irqtune</EM>'s kernel module (<EM>irqtune_mod.o</EM>) uses is <EM>printk</EM> (to print a confirmation message to syslog). The <EM>irqtune_npr.o</EM> module
is exactly the same as <EM>irqtune_mod.o</EM> except that it does <STRONG>not</STRONG> use <EM>printk</EM>.
Since <EM>irqtune</EM>
pre-checks all parameters before attempting to load the kernel module, the confirmation message is a nicety but not a necessity. <P>
<P><P>
<H3>
<A NAME="__irqtune_49__">Q: What if we don't have ELF binary support?</A> </H3>
<P>
<EM>
Well, we should upgrade the kernel as ELF binaries are cool :-). </EM>
But if that's not possible, we'll just have to recompile <EM>irqtune</EM> to create <EM>a.out</EM> binaries. This is, perhaps, the only justification for rebuilding <EM>irqtune</EM>. Just be sure
that <STRONG>/usr/src/linux/include</STRONG> is installed. The exact procedure for building <EM>a.out</EM> binaries can vary with compiler revision, so it's important to check the documentation on this (a parameter or two may need to be added). <BR>
<UL>
<LI>
Then, just type:
<BR>
<CODE>
make&nbsp;warp9
<BR>
</CODE>
<LI>
Here is the makefile's own documentation: <BR>
<CODE>
INSTALLATION:
<BR>
&nbsp;&nbsp;install&nbsp;&nbsp;&nbsp;&nbsp;install&nbsp;prebuilt&nbsp;binaries&nbsp;in&nbsp;/sbin <BR>
&nbsp;&nbsp;custom&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;create&nbsp;custom&nbsp;installation&nbsp;--&nbsp;Normally&nbsp;not&nbsp;required&nbsp;--&nbsp;Try <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;install&nbsp;first&nbsp;(EQUIVALENT:&nbsp;kvers&nbsp;sbin&nbsp;install) <BR>
&nbsp;&nbsp;uninstall&nbsp;&nbsp;remove&nbsp;prebuilt&nbsp;binaries&nbsp;from&nbsp;/sbin <BR>

<BR>
INSTALLATION&nbsp;OVERRIDES:
<BR>
&nbsp;&nbsp;SBIN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SBIN=/whatever&nbsp;specify&nbsp;installation&nbsp;directory&nbsp;(DEFAULT:&nbsp;/sbin) <BR>
&nbsp;&nbsp;INSTALL&nbsp;&nbsp;&nbsp;&nbsp;INSTALL=simple&nbsp;simple&nbsp;installation&nbsp;(DEFAULT:&nbsp;simple) <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;INSTALL=sh&nbsp;install&nbsp;as&nbsp;shell&nbsp;stub <BR>
&nbsp;&nbsp;INSTALLER&nbsp;&nbsp;installation&nbsp;program&nbsp;(bin/install)&nbsp;(DEFAULT:&nbsp;sbin/irqtune) <BR>

<BR>
REBUILDING&nbsp;FROM&nbsp;SOURCE:
<BR>
&nbsp;&nbsp;kvers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;create&nbsp;kernel_version <BR>
&nbsp;&nbsp;sbin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rebuild&nbsp;binaries&nbsp;from&nbsp;source&nbsp;(full&nbsp;or&nbsp;partial) <BR>

<BR>
FORCE&nbsp;FULL&nbsp;REBUILD&nbsp;(requires&nbsp;/usr/src/linux/include): <BR>
&nbsp;&nbsp;clean&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;remove&nbsp;.o&nbsp;files&nbsp;to&nbsp;force&nbsp;full&nbsp;recompile) <BR>
&nbsp;&nbsp;warp9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rebuild&nbsp;all&nbsp;(EQUIVALENT:&nbsp;clean&nbsp;kvers&nbsp;sbin&nbsp;install) <BR>

<BR>
</CODE>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_50__">Q: What about IRQ sharing of serial ports?</A> </H3>
<P>
Under the 2.0.X (and later) kernels, use of IRQ sharing will defeat IRQ priority because
the serial port ISR's are installed as <EM>slow</EM> rather than <EM>fast</EM> interrupts (e.g. they don't use the SA_INTERRUPT flag). <P>
<UL>
<LI>
Change the serial port IRQ configuration so that ports don't share IRQ's
<BR>
<LI>
The other option is a kernel source patch to <STRONG>drivers/char/serial.c</STRONG>: <BR>
Change the following line:
<BR>
<CODE>
define&nbsp;IRQ_T(info)&nbsp;((info-&62;flags&nbsp;&#38;&nbsp;ASYNC_SHARE_IRQ)&nbsp;?&nbsp;SA_SHIRQ&nbsp;:&nbsp;SA_INTERRUPT) <BR>
</CODE>
and replace it with:
<CODE>
define&nbsp;IRQ_T(info)&nbsp;(((info-&62;flags&nbsp;&#38;&nbsp;ASYNC_SHARE_IRQ)&nbsp;?&nbsp;SA_SHIRQ&nbsp;:&nbsp;0)&nbsp;|&nbsp;SA_INTERRUPT) <BR>
</CODE>
</UL>
<P>
Under earlier kernels this is not a problem because the serial ISR was always installed with SA_INTERRUPT.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_51__">What about hardware/config problems?</A> </H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_52__">Q: What if the serial port doesn't work?</A> </H3>
<UL>
<LI>
The First Law of Computing: Make sure it's plugged in. <P>
<LI>
Double check the strapping for port and IRQ assignments. Verify that the port/IRQ desired is actually the one that is strapped. Some serial ports will appear to work even if the IRQ is wrong--they will just be <EM>extremely</EM> slow.
Some Plug-N-Play (PnP) ports may need to be explicitly strapped. <P>
<LI>
Check for port/IRQ conflicts with other devices. Serial ports may share IRQ assignments but sharing an IRQ between a serial port and something else (e.g. an ethernet card) is fraught with peril. See the previous section about serial IRQ sharing under 2.0.X kernels.
<P>
<LI>
Verify that the IRQ that the kernel reports as a result of auto-detection is the IRQ that was strapped. Some serial ports or hardware configurations can fool the auto-detect. If necessary, use the <EM><STRONG>setserial</STRONG></EM> program (in <STRONG>/etc/rc.d/rc.local</STRONG>) to force the kernel port/IRQ settings to match the hardware strapping. <P>
<LI>
Verify that <EM>irqtune</EM> got the correct IRQ numbers for the specific configuration.
For example, suppose our primary serial port is on IRQ 3, but we gave <EM>irqtune</EM> the value <EM>4</EM>. We just made the serial device on IRQ 3 into priority 14, not priority 0.
<P>
<LI>
Verify that the serial port baud rate is set correctly. That is, it is the same as what the modem expects. The serial port baud rate also has performance implications (See <A HREF="__irqtune_61__">Q: What about increasing the serial port baud rate?</A> for details). <P>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_53__">Q: What if PPP doesn't work?</A> </H3>
<P>
See the PPP man page and PPP-Howto for best information, but some recommended options:
<BR>
<UL>
<LI>
asyncmap 0
<BR>
<LI>
crtscts
<BR>
<LI>
defaultroute
<BR>
<LI>
modem
<BR>
<LI>
mru 296 mtu 296
<BR>
<LI>
passive
<BR>
</UL>
<P>
AT-like modems have a special character to escape from data mode to command mode.
To avoid confusion here, we'll call this modem escape character a <EM>guard</EM> character.
<P>
The default <EM>guard</EM> character is '+' (decimal 43, hex 2B). Normally, 3 such characters are required within a special timing sequence. <P>
Although it is <EM>unlikely</EM>, it is still possible that some PPP packets could generate the <EM>guard</EM> sequence inadvertantly. To prevent this, we may want to inhibit the generation of the <EM>guard</EM> character in a data sequence. To do this,
we would add the additional PPP option: <BR>
<UL>
<LI>
escape 2B
<BR>
</UL>
<P>
Since '+' is a common ASCII character (PPP escaped characters generate two characters), we may wish to use a less common value for the <EM>guard</EM> character. For example, a less common value might be (decimal 200, hex C8). We would add an <STRONG>ATS2=200</STRONG> command to our modem dialer script and change the PPP escape option to <STRONG>C8</STRONG>. <P>
<P><P>
<H3>
<A NAME="__irqtune_54__">Q: Why does PPP <EM>consistently</EM> drop every second packet sent from Linux, resulting in a 50% packet loss?</A> </H3>
<P>
<STRONG>
Some braindamaged PPP implementations do not handle PPP <EM>flag</EM> optimization!
</STRONG>
<P>
The PPP protocol uses a <EM>flag</EM> byte to separate packets. Each packet begins with a <EM>flag</EM> and ends with a second <EM>flag</EM>. <BR>
<UL>
<LI>
Loosely, each packet looks something this: <BR>
<CODE>
&
60;FLAG&#62;&nbsp;&#60;PACKET&nbsp;(e.g.&nbsp;header,&nbsp;data,&nbsp;CRC)&#62;&nbsp;&#60;FLAG&#62; <BR>
</CODE>
<LI>
Thus, a sequence of packets might look like this: <BR>
<CODE>
&#60;FLAG&#62;&#60;PACKET1&#62;&#60;FLAG&#62;&nbsp;&#60;FLAG&#62;&#60;PACKET2&#62;&#60;FLAG&#62;&nbsp;&#60;FLAG&#62;&#60;PACKET3&#62;&#60;FLAG&#62;&nbsp;... <BR>
</CODE>
<LI>
However, as an optimization, the PPP protocol permits trailing and leading
<EM>flag</EM> bytes to be combined within a sequence of packets: <BR>
<CODE>
&#60;FLAG&#62;&nbsp;&#60;PACKET1&#62;&nbsp;&#60;FLAG&#62;&nbsp;&#60;PACKET2&#62;&nbsp;&#60;FLAG&#62;&nbsp;&#60;PACKET3&#62;&nbsp;&#60;FLAG&#62;&nbsp;... <BR>
</CODE>
</UL>
<P>
Although the PPP protocol <STRONG>requires</STRONG> implementations receiving packets to handle <EM>flag</EM>
optimization, some <STRONG>broken</STRONG> PPP implementations do not understand it! <P>
These implementations
see the trailing <EM>flag</EM>, process the packet, then look for a fresh <EM>flag</EM>. They don't realize that the trailing <EM>flag</EM> of PACKET1 may perform double duty as the leading <EM>flag</EM> of PACKET2. They will ignore all data until they see a new <EM>flag</EM> (which, in this example, is the <EM>flag</EM> between PACKET2 and PACKET3). Thus, PACKET2 will be seen as noise data and be ignored. These implementations will only see only the odd number packets (e.g. PACKET1, PACKET3, PACKET5, etc.), resulting in a 50% packet loss!
<P>
Linux PPP implements <EM>flag</EM> optimization correctly and enables it by default. As charity to others, Linux does allow <EM>flag</EM> optimization to be turned off, but currently, this this requires the kernel to be rebuilt. <P>
In Linux, to turn off <EM>flag</EM> optimization on transmit, do the following: <BR>
<UL>
<LI>
Edit the file <STRONG>drivers/net/ppp.c</STRONG> <BR>
<LI>
Change the line:
<BR>
<CODE>
static&nbsp;int&nbsp;&nbsp;flag_time&nbsp;=&nbsp;OPTIMIZE_FLAG_TIME; <BR>
</CODE>
<LI>
Replace this with:
<BR>
<CODE>
static&nbsp;int&nbsp;&nbsp;flag_time&nbsp;=&nbsp;0; <BR>
</CODE>
<LI>
Rebuild the kernel.
<BR>
</UL>
<P>
<EM>
Note: A better solution is to return the defective PPP implementation to the vendor and demand a refund or replacement! </EM>
<P>
<P><P>
<H3>
<A NAME="__irqtune_55__">Q: How can we be certain that the PPP <EM>flag</EM> optimzation loss is occuring?</A> </H3>
<P>
By lowering the baud rate to something that is guaranteed not to drop data due to speed problems (e.g. 300 baud). If we get a consistent 50% loss at this low rate, this is almost certain proof of the <EM>flag</EM> optimization problem.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_56__">What other performance software remedies must be done?</A> </H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_57__">Q: What about using <EM>hdparm -u</EM> to set the interrupt-unmask flag in the hard disk driver?</A> </H3>
<P>
This is only necessary for the <EM>IDE</EM> driver. The SCSI driver has short disable windows by default. This will shorten the IDE interrupt disable windows.
<P>
<EM><STRONG>Beware:</STRONG></EM> Without this option, IDE disk activity will almost certainly cause serial data dropouts. If we have an IDE disk, this is <STRONG>mandatory</STRONG>. <P>
<P><P>
<H3>
<A NAME="__irqtune_58__">Q: What about disabling Van Jacobsen header compression in PPP?</A> </H3>
<P>
This reduces the amount of <EM>bottom-half</EM> processing the system has to do at the expense of larger packets being sent. This may be helpful on slower CPU's or heavily loaded configurations.
<P>
<P><P>
<H3>
<A NAME="__irqtune_59__">Q: What about adjusting the MRU/MTU numbers in PPP?</A> </H3>
<P>
Reducing the MRU/MTU
to a minimum (296) reduces the <EM>bottom-half</EM> processing and <EM>flip-buffer</EM> latency at the expense of
adding extra overhead bytes due to the reduced packet size. The optimal value will vary from configuration to configuration. <P>
<EM><STRONG>Beware:</STRONG></EM> Start with 296 as the optimal may not be 1500. <P>
<EM>
The <STRONG>flip-buffer</STRONG> is a double buffer mechanism in the serial/tty drivers through which all data <STRONG>must</STRONG> pass. It has a fixed size of only 512 bytes.
MRU/MTU greater than the <STRONG>flip-buffer</STRONG> size may create an internal race condition that may cause dropouts on slower CPU's or heavily loaded configurations.
</EM>
<P>
<P><P>
<H3>
<A NAME="__irqtune_60__">Q: What about going to newer kernel revisions?</A> </H3>
<P>
Although <EM>irqtune</EM> will work surprisingly well with just about any kernel revision, the low level IRQ handlers and device drivers have been vastly improved in the 2.0.X kernels. This will only improve <EM>irqtune</EM>'s effect. <P>
<P><P>
<H3>
<A NAME="__irqtune_61__">Q: What about increasing the serial port baud rate?</A> </H3>
<P>
The serial port baud rate should be high enough to support the maximum expected transfer rate--but no higher. Higher speed settings place extra strain on the CPU, increasing the likelihood of overruns. <P>
For a 33.6 modem, the minimum baud rate would be 38400. However, with compression, the expected transfer rate can be as high as 6 KB/second. This would require a baud rate of 57600. This may strain the CPU, and since the transfer rate is nominally about 4 KB/second, a lower baud rate may be a good compromise.
<P>
The best way is to try several rates, then benchmark them to see which provides the best overall performance.
<P>
<EM><STRONG>Note:</STRONG></EM>
Because of backward compatibility to older systems, we can't just set 57600 directly with
<EM>stty</EM>,
<EM>kermit</EM>,
<EM>pppd</EM>,
etc. Specify 38400 to these programs, and use the <EM>setserial</EM> program with an option of <STRONG>spd_hi</STRONG>. For ISDN speeds, use <STRONG>spd_vhi</STRONG>. Other options are possible so be sure to consult the manpage.
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_62__">How can I tell if <EM>irqtune</EM> actually did anything for me?</A> </H1>
<P>
Well, first off, if PPP/SLIP was dying mysteriously, it will probably be more reliable.
<P>
<P><P>
<H3>
<A NAME="__irqtune_63__">Q: How can we benchmark <EM>irqtune</EM>?</A> </H3>
Run without it and get a feel for the transfer rate: <P>
<UL>
<LI>
Hit <EM>many</EM> favorite web sites and note the transfer rates in bytes/second. Make life easy. Netscape is at least one browser that reports transfer rates in bytes/second in the status line. <P>
<LI>
FTP reports the transfer time of a file in bytes/second. Download (or upload) a few files (300K or greater to smooth out the benchmark) and note the transfer rates. Use a mix of <EM>ascii</EM> and <EM>binary</EM> files that to see the effect of modem compression. <EM>Binary</EM> won't compress too well so the numbers will reflect the <EM>real</EM> transfer rate. <EM>Ascii</EM> files which typically compress 2:1 will up the <EM>effective</EM> rate by 2X, making it more stressful.
<P>
<LI>
Try several things of varying duration, different times of day, different sites to accomodate variations in network loading. Don't stop until there is an average set of numbers that are more or less repeatable. <P>
</UL>
<P>
Repeat this using <EM>irqtune</EM> and note the transfer times again. <P>
<EM>NOTE: IRQTUNE just won't quit--if you want to test in the original mode</EM> <EM>again, reboot the system first.</EM> <P>
<P><P>
<H3>
<A NAME="__irqtune_64__">Q: What if we still don't see any real improvement?</A> </H3>
<P>
It's a matter of probability. Performance measurement is as much art as science.
<P>
<UL>
<LI>
We're much more likely to see improvement on a DX2/66 than a Pentium/166. With the 166, we may be <EM>overpowering</EM> the problem. We'll still have a problem, we just won't notice it as much because the Pentium has the extra speed to burn.
<EM>A badly tuned Ferrari may still outperform a well-tuned VW :-)</EM> <P>
<LI>
What problem was occurring before? Which of the symptoms listed earlier is happening? If performance was 2500
bytes/second <EM>before</EM> using <EM>irqtune</EM>, we're less likely to notice the smaller jump to, say, 2800.
<P>
<LI>
System loading is very light. The problems that <EM>irqtune</EM> will fix are more likely to happen when more devices and more work are added. On a certain configuration, <EM>irqtune</EM> had little effect. However, when a brand new SCSI DAT drive was added, serial performance nosedived. Using <EM>irqtune</EM> brought performance back to the correct level. <P>
<LI>
We may have a <STRONG>rogue</STRONG> interrupt service that disables interrupts for something outrageous, say 2 ms. This is singularly longer than the 1194 us. in the earlier example. <EM>irqtune</EM> will still help, but the real solution here is to reduce interrupt lockout times in the other device below the 1194 us. threshold.
<P>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_65__">Where can I find additional documentation or downloads?</A> </H1>
<P>
<UL>
<LI>
man pages for: <EM>insmod</EM>, <EM>hdparm</EM>, <EM>pppd</EM>, <EM>setserial</EM> <BR>
<LI>
The Linux Documentation Project
<BR>
<UL>
<LI>
Homepage: <A HREF="http://sunsite.unc.edu/LDP">http://sunsite.unc.edu/LDP</A>; <BR>
<LI>
HOWTO's: <A HREF="ftp://sunsite.unc.edu/pub/Linux/doc/HOWTO">ftp://sunsite.unc.edu/pub/Linux/doc/HOWTO</A> <BR>
</UL>
<LI>
The Linux Software Map (Hypertext)
<BR>
<UL>
<LI>
<A HREF="http://www.boutell.com/lsm">http://www.boutell.com/lsm</A>; <BR>
</UL>
<LI>
Linux v2 Information HQ
<BR>
<UL>
<LI>
<A HREF="http:/www.linuxhq.com">http:/www.linuxhq.com</A>; <BR>
</UL>
<LI>
ftp ftp.kernel.org
<BR>
<UL>
<LI>
<A HREF="http://ftp.kernel.org">http://ftp.kernel.org</A>; <BR>
</UL>
<LI>
2.0.X kernel and compatible modutils downloads <BR>
<UL>
<LI>
<A HREF="ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.0">ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.0</A>, <A HREF="ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.0/modules-2.0.0.tar.gz">ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.0/modules-2.0.0.tar.gz</A> <BR>
<LI>
<A HREF="ftp://ftp.kernel.org/pub/linux/kernel/v2.0">ftp://ftp.kernel.org/pub/linux/kernel/v2.0</A>, <A HREF="ftp://ftp.kernel.org/pub/linux/kernel/v2.0/modules-2.0.0.tar.gz">ftp://ftp.kernel.org/pub/linux/kernel/v2.0/modules-2.0.0.tar.gz</A> <BR>
</UL>
<LI>
2.1.X kernel and compatible modutils downloads <BR>
<UL>
<LI>
<A HREF="ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.1">ftp://ftp.funet.fi/pub/Linux/kernel/linux/v2.1</A>, <A HREF="ftp://ftp.kernel.org/pub/linux/kernel/v2.1/modutils-2.1.34.tar.gz">ftp://ftp.kernel.org/pub/linux/kernel/v2.1/modutils-2.1.34.tar.gz</A> <BR>
<LI>
<A HREF="ftp://ftp.kernel.org/pub/linux/kernel/v2.1">ftp://ftp.kernel.org/pub/linux/kernel/v2.1</A>, <A HREF="ftp://ftp.kernel.org/pub/linux/kernel/v2.1/modutils-2.1.34.tar.gz">ftp://ftp.kernel.org/pub/linux/kernel/v2.1/modutils-2.1.34.tar.gz</A> <BR>
</UL>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_66__">Changes</A>
</H1>
<P>
<P><P>
<H3>
<A NAME="__irqtune_67__">Revision 0.2 Changes:</A> </H3>
<UL>
<LI>
No code changes
<BR>
<LI>
Major rewrite and expansion of the problem explanation section <BR>
<LI>
More thorough explanation of how and why <EM>irqtune</EM> works <BR>
<LI>
Explanation of why serial devices must be highest priority <BR>
<LI>
Impact on other devices
<BR>
<LI>
Cleaner and better installation instructions <BR>
<LI>
Better benchmarking section
<BR>
<LI>
Problem resolution section
<BR>
<LI>
Explanation of my prior misread on the EOI thing <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_68__">Revision 0.3 Changes:</A> </H3>
<UL>
<LI>
irqtune automatically prints interrupt priority table <BR>
<LI>
Significantly improved error detection and reporting <BR>
<LI>
Improved loading under different kernel revisions <BR>
<LI>
<EM>insmod</EM> now invoked with <EM>-x</EM> to improve loading <BR>
<LI>
Added module <EM>without</EM> printk's -- irqtune_npr.o <BR>
<LI>
Special makefile options for difficult or custom rebuilds <BR>
<LI>
Corrected error in <EM>hdparm -u</EM> note. <BR>
<LI>
Improved the non-standard configuration section <BR>
<LI>
Added note and patch about IRQ sharing under 2.0.X kernels <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_69__">Revision 0.4 Changes:</A> </H3>
<UL>
<LI>
No code changes
<BR>
<LI>
Updated links in the FAQ to reflect configuration changes at my ISP, best.com. Specifically, the FTP address changed from ftp://www.best.com/pub/cae/irqtune.tgz
to
ftp://ftp.best.com/pub/cae/irqtune.tgz
<BR>
<LI>
<EM>irqtune</EM> distribution now available via HTTP as well as FTP. <BR>
<LI>
Consolidated and improved trouble resolution sections. <BR>
<LI>
Added explanation of irqtune_mod.o vs. irqtune_npr.o. <BR>
<LI>
Added explanation of /sbin usage.
<BR>
<LI>
Corrected some typos.
<BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_70__">Revision 0.5 Changes:</A> </H3>
<UL>
<LI>
Added alternate installation procedure with "INSTALL=" option. <BR>
<LI>
/sbin is added to $PATH automatically.
<BR>
<LI>
Added "-u" option.
<BR>
<LI>
Consolidated and improved installation documentation. <BR>
<LI>
Additional trouble resolution documentation. <BR>
<LI>
Again, updated links in the FAQ to reflect configuration changes at my ISP, best.com.
Specifically, the FTP address changed from ftp://ftp.best.com/pub/cae/irqtune.tgz
to
ftp://shell5.ba.best.com/pub/cae/irqtune.tgz <BR>
</UL>
<P>
<P><P>
<H3>
<A NAME="__irqtune_71__">Revision 0.6 Changes:</A> </H3>
<UL>
<LI>
Added an "inb" to force PIC to a determinate state before setting priority. <BR>
<LI>
Added include of errno.h to allow compilation with newer libc distributions. <BR>
<LI>
Added code to probe ksyms, kernel, insmod for incompatibilities. Specifically, versions of insmod that have bugs (fixed in insmod 2.1.34) are detected and handled correctly.
<BR>
<LI>
Added "-f" option.
<BR>
<LI>
Added documentation about insmod incompatibilities and upgrades. <BR>
<LI>
Added documentation and workaround for broken PPP implementations of PPP <EM>flag</EM> optimization.
<BR>
<LI>
Added documentation about recommended serial port baud rates. <BR>
<LI>
Added section with hyperlinks to other documentation and downloads. <BR>
<LI>
Added irqtune to LSM (finally :-).
<BR>
<LI>
Install script now obsolete. irqtune now self installs. Some moronic systems still don't have csh installed.
<BR>
</UL>
<P>
<P><P>
<HR>
<H1>
<A NAME="__irqtune_72__">Table of Contents</A> </H1>
<UL>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;<A HREF="__irqtune_0__"><EM>IRQTUNE</EM> -- A Linux IRQ Priority Optimizer</A> <LI>
<A HREF="
__irqtune_1__">Where do I get <EM>irqtune</EM>?</A> <BR>
<LI>
<A HREF="__irqtune_2__">How do I know if I need <EM>irqtune</EM>?</A> <BR>
<LI>
<A HREF="
__irqtune_3__">What is actually happening to cause these problems?</A> <BR>
<LI>
<A HREF="__irqtune_7__">How does irqtune help this?</A> <BR>
<LI>
<A HREF="
__irqtune_8__">Why does the serial interrupt service require the highest priority?</A> <BR>
<LI>
<A HREF="__irqtune_12__">Isn't that example very <EM>unlikely</EM> under Linux?</A> <BR>
<LI>
<A HREF="
__irqtune_13__">Doesn't this hurt the performance of other devices?</A> <BR>
<LI>
<A HREF="__irqtune_17__">Isn't this IRQ priority thing a bit of a new idea?</A> <BR>
<LI>
<A HREF="
__irqtune_18__">How do I install <EM>irqtune</EM>?</A> <BR>
<LI>
<A HREF="__irqtune_25__">How do I use <EM>irqtune</EM>? Don't I have to rebuild my kernel?</A> <BR>
<LI>
<A HREF="
__irqtune_31__">What about my non-standard hardware configuration?</A> <BR>
<LI>
<A HREF="__irqtune_42__">What about <EM>irqtune</EM> load failures or incompatibilities with kernel revisions?</A> <BR>
<LI>
<A HREF="
__irqtune_51__">What about hardware/config problems?</A> <BR>
<LI>
<A HREF="__irqtune_56__">What other performance software remedies must be done?</A> <BR>
<LI>
<A HREF="
__irqtune_62__">How can I tell if <EM>irqtune</EM> actually did anything for me?</A> <BR>
<LI>
<A HREF="__irqtune_65__">Where can I find additional documentation or downloads?</A> <BR>
<LI>
<A HREF="
__irqtune_66__">Changes</A>
<BR>
<LI>
<A HREF="#__irqtune_72__">Table of Contents</A> <BR>
</UL>
</BODY>
</HTML>


Sponsored Links

Discussion Groups
  Beginners
  Distributions
  Networking / Security
  Software
  PDAs

About | FAQ | Privacy | Awards | Contact
Comments to the webmaster are welcome.
Copyright 2006 Sourcefiles.org All rights reserved.