Subject: Re: Fix for your serial/PPP problems

From: Philippe Troin <[email-masked]>
Date: Sat, 24 Aug 1996 04:18:23 -0700

On Wed, 21 Aug 1996 00:14:10 PDT Philippe Troin (phil) wrote:

> On Wed, 21 Aug 1996 00:23:16 EDT renald loignon ([email-masked]) wrote:
> 
> > Could someone knowledgeable in low-level kernel matters take a look at the
> > following?  I looked at the Web page, and though it sounds interesting
> > overall (and it WOULD solve a serial problem I experienced with Debian 1.1.1
> > and kernel 2.0.6), there appear to be some technical inaccuracies which give
> > me second thoughts. Any comments appreciated.
> [mail copy snipped]
> 
> I've browsed through the web page, and this just looks sensible to me.
> The question is: why isn't this part of standard kernel ?

I've been trying it for over 24 hours, and I must say I'm quite impressed.
PPP  performance has really increased. It is streaming for long periods without
interruption. And no kernel Ooops or no problems.
Seemingly no problems...
Can anyone confirm these subjective enhancements ? I mean my PPP connection
might just be better by other means...

Phil.

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Sat, 24 Aug 1996 20:42:09 -0400

Hi Philippe --

> might just be better by other means...

I've had it going (on and off) for the last day also, and I also have
the sense (not quantified or rigorously tested) that it has finally
stopped all the billions of stalls I'd been getting.  I use a reasonably
fast "modem", i.e., a data-over-voice ISDN channel that talks through a
high-speed serial port at 56K.  It may be that my previous stall problems
were actually exaccerbated by using a higher-speed serial line (i.e.,
I must have been offering relatively more interrupts to the CPU than someone
with a slower modem).  

So I _really_ appreciate finding out about this utility.  THANKS!!!!!

Susan Kleinmann

---

From: Gerry Jensen <[email-masked]>
Date: Sat, 24 Aug 1996 20:15:01 -0600 (MDT)

> might just be better by other means...

To test if you're actually seeing improvement with irqtune, I'd try
transferring a large file between your machine and the machine you're
connected with (or a machine that's only a few links away) before
installing irqtune.  Note the transfer rate.  Do this a few times to get
an average as each time will vary a bit.  Then load irqtune and try
transferring the same file again several times and see if there's any
substantial improvement in the average transfer time. 

After I saw the original post about irqtune here, I decided to ask about
it on the kernel list.  Linus is looking into it now.  Apparently, irqtune
only helps with some (probably buggy) interrupt controllers.  Below is
Linus' reply along with a kernel patch that *may* possibly have the same
effect as irqtune on systems where irqtune does make a difference.  On my
system, I see no improvement whatsover with irqtune.  But, others have
seen substantial improvement.  Someone told me he saw some improvement but
at the cost of slowing down his SCSI drive.

Gerry

-----------------------------------------------------------------
>From [email-masked]  Fri Aug 23 03:45:42 1996
Date: Fri, 23 Aug 1996 09:08:43 +0300 (EET DST)
From: Linus Torvalds <[email-masked]>
To: Russell Berry <[email-masked]>
cc: Gerry Jensen <[email-masked]>, [email-masked]
Subject: Re: irqtune: improve serial port performance by 3x?
Status: RO

On Thu, 22 Aug 1996, Russell Berry wrote:
> 
> I got this, installed it on both my machines (home/work), and can see a marked 
> increase in ppp performance.  However, I'm concerned about interrupt priorities, 
> does this effect _ONLY_ the timer interrupt priorities, or does it actually tweak
> the way the kernel interprets all system interrupts???

I don't like the fact that irqtune helsp interrupt performance, because the
way Linux tries to handle interrupts it _shouldn't_ make a difference. The
fact that irqtune obviously _does_ make a difference would indicate that the
irq handling has some problem, and irqtune just masks that problem by
changing the interrupt priority levels. 

Essentially, Linux does a "EOI" immediately when it gets the interrupt, and
that EOI _should_ mean that all other interrupts will get through, regardless
of whether they have lower or higher priority (because the EOI tells the
interrupt controller that it can forget about the interrupt that we're now
handling).  As such there should be no effect from irqtune, because the
interrupt priorities shouldn't really matter. 

However, Linux uses the "nonspecific" EOI to do this, and while that should
work, it may turn out that some interrupt controllers don't like it, and for
some reason mask the wrong interrupt. People who see a difference with
irqtune, could you test this patch instead (it changes the low-level
interrupt handlers to use the "specific" EOI to tell the controller that that
specific interrupt is now handled). 

I'd be very interested in reactions to this patch indeed, can you please 
try it out and tell me whether this makes any difference?

(This is against 2.0.14, but it should patch in cleanly against just about
any reasonably recent kernel. Certainly all of the 2.0.x series)

		Linus
----
--- v2.0.14/linux/include/asm-i386/irq.h	Sun Mar 10 09:28:56 1996
+++ linux/include/asm-i386/irq.h	Fri Aug 23 08:18:12 1996
@@ -81,7 +81,7 @@
  * a bit - without them it seems that the harddisk driver won't work on
  * all hardware. Arghh.
  */
-#define ACK_FIRST(mask) \
+#define ACK_FIRST(mask,nr) \
 	"inb $0x21,%al\n\t" \
 	"jmp 1f\n" \
 	"1:\tjmp 1f\n" \
@@ -90,10 +90,10 @@
 	"outb %al,$0x21\n\t" \
 	"jmp 1f\n" \
 	"1:\tjmp 1f\n" \
-	"1:\tmovb $0x20,%al\n\t" \
+	"1:\tmovb $0x60+"#nr",%al\n\t" \
 	"outb %al,$0x20\n\t"
 
-#define ACK_SECOND(mask) \
+#define ACK_SECOND(mask,nr) \
 	"inb $0xA1,%al\n\t" \
 	"jmp 1f\n" \
 	"1:\tjmp 1f\n" \
@@ -102,11 +102,12 @@
 	"outb %al,$0xA1\n\t" \
 	"jmp 1f\n" \
 	"1:\tjmp 1f\n" \
-	"1:\tmovb $0x20,%al\n\t" \
+	"1:\tmovb $0x60+"#nr",%al\n\t" \
 	"outb %al,$0xA0\n\t" \
 	"jmp 1f\n" \
 	"1:\tjmp 1f\n" \
-	"1:\toutb %al,$0x20\n\t"
+	"1:\tmovb $0x62,%al\n\t" \
+	"outb %al,$0x20\n\t"
 
 #define UNBLK_FIRST(mask) \
 	"inb $0x21,%al\n\t" \
@@ -207,7 +208,7 @@
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t"\
 	"sti\n\t" \
 	"movl %esp,%ebx\n\t" \
@@ -224,7 +225,7 @@
 SYMBOL_NAME_STR(fast_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t" \
 	"pushl $" #nr "\n\t" \
 	"call "SYMBOL_NAME_STR(do_fast_IRQ)"\n\t" \
@@ -238,7 +239,7 @@
 SYMBOL_NAME_STR(bad_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	LEAVE_KERNEL \
 	RESTORE_MOST);
 	
@@ -255,7 +256,7 @@
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t"\
 	"movl %esp,%ebx\n\t" \
 	"pushl %ebx\n\t" \
@@ -283,7 +284,7 @@
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t"\
 	"sti\n\t" \
 	"movl %esp,%ebx\n\t" \
@@ -301,7 +302,7 @@
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(fast_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	SMP_PROF_IPI_CNT \
 	"pushl $" #nr "\n\t" \
 	"call "SYMBOL_NAME_STR(do_fast_IRQ)"\n\t" \
@@ -312,7 +313,7 @@
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(bad_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	RESTORE_MOST);
 
 #define BUILD_RESCHEDIRQ(nr) \
@@ -345,7 +346,7 @@
 SYMBOL_NAME_STR(IRQ) #nr "_interrupt:\n\t" \
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t"\
 	"sti\n\t" \
 	"movl %esp,%ebx\n\t" \
@@ -360,7 +361,7 @@
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(fast_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t" \
 	"pushl $" #nr "\n\t" \
 	"call "SYMBOL_NAME_STR(do_fast_IRQ)"\n\t" \
@@ -372,7 +373,7 @@
 "\n"__ALIGN_STR"\n" \
 SYMBOL_NAME_STR(bad_IRQ) #nr "_interrupt:\n\t" \
 	SAVE_MOST \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	RESTORE_MOST);
 	
 #define BUILD_TIMER_IRQ(chip,nr,mask) \
@@ -386,7 +387,7 @@
 SYMBOL_NAME_STR(IRQ) #nr "_interrupt:\n\t" \
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
-	ACK_##chip(mask) \
+	ACK_##chip(mask,(nr&7)) \
 	"incl "SYMBOL_NAME_STR(intr_count)"\n\t"\
 	"movl %esp,%ebx\n\t" \
 	"pushl %ebx\n\t" \
-----

---

From: Philippe Troin <[email-masked]>
Date: Mon, 26 Aug 1996 11:54:03 -0700

I've done some statistics regarding irqtune and kernels 2.0.14 and 
2.0.15.

The protocol was the following:
1) ftp to my ISP
2) put a file
3) get the same file 10 times with a 'mget file file <etc...>'

I timed only the 'GET', not the 'PUT' as Linux buffers outgoing 
packets and tricks the figures.

Test I was done on a 2.0.14 kernel with a 100kb nul file (dd 
if=/dev/zero...)
Test II was done on a 2.0.14 kernel with irqtune and a 100kb nul file.
Test III was done on a 2.0.15 kernel with a 100kb nul file.
Test IV was done on a 2.0.15 kernel with irqtune and a 100kb nul file.
Test V was done on a 2.0.15 kernel with a 100kb random file.
Test VI was done on a 2.0.15 kernel with irqtune and a 100kb random 
file.

The same phone line was used for tests I and II, III and IV, and V 
and VI.
That is I didn't disconnect between I and II, III and IV and V and VI.
However I rebooted and disconnected between II and III, IV and V.

Here are the timings as reported by ftp, as well as the transfer 
rates as reported by ftp.
Then come the average figures for timings and transfer rates. The 
average for transfer rates were computed from the average time 
(100kb/<avg. time>).
Finnaly, I computed standard deviance for timings (not for transfer 
rate, they should be the same as timings if I remember correctly my 
stats (arghhh) lessons).

	  I          II        III         IV         V          VI
Count Time Rate  Time Rate  Time Rate  Time Rate  Time Rate  Time Rate
----------------------------------------------------------------------
 1    56.4  1.8  27.2  3.7  59.2  1.7  27.3  3.7  67.2  1.5  26.9  3.7
 2    68.2  1.5  27.2  3.7  77.0  1.3  36.5  2.7  44.9  2.2  26.9  3.7
 3    40.7  2.5  41.0  2.4  58.4  1.7  27.1  3.7  80.0  1.2  26.9  3.7
 4    56.7  1.8  37.0  2.7  55.5  1.8  27.0  3.7  47.6  2.1  27.0  3.7
 5    63.0  1.6  36.6  2.7  44.8  2.2  41.1  2.4  68.1  1.5  27.0  3.7
 6    65.9  1.5  36.5  2.7  58.0  1.7  41.1  2.4  45.6  2.2  26.9  3.7
 7    68.9  1.5  41.2  2.4  46.2  2.2  41.0  2.4  62.1  1.6  26.9  3.7
 8    55.9  1.8  41.1  2.4  55.4  1.8  41.2  2.4  46.4  2.2  26.9  3.7
 9    73.2  1.4  42.2  2.4  70.0  1.4  36.5  2.7  60.4  1.7  27.0  3.7
10    42.8  2.3  36.6  2.7  60.8  1.6  27.2  3.7  48.6  2.1  26.9  3.7
----------------------------------------------------------------------
Avg.  59.17 1.7  36.66 2.7  58.53 1.7  34.60 2.9  57.09 1.7  26.93 3.7
Dev.  10.32       5.18       9.15       6.31      11.58       0.05

The figures are quite clear. Irqtune really improves my serial 
performances, even with kernel 2.0.15 (see previous messages, 2.0.15 
included a patch which might have helped serial performance).
What I don't understand is why a file consisting of zeros only do not 
get the same transfer rate as a random file. I suspect an obscure PPP
problem.

My machine is an AMD DX2-66 with 32MB RAM, 32MB swap, and I have fast 
serial controllers (16550A). The modem is an external 33.6 V.34/V.FC 
Cardinal connected to my ISP which has 33.6 too.

I'm not subscribed to the linux kernel mailing list, but you can 
forward this message over there.

I stick with irqtune right now. BTW, I saw no ill side effect when 
using it.

Phil.

---

From: Gerry Jensen <[email-masked]>
Date: Mon, 26 Aug 1996 18:24:17 -0600 (MDT)

> get the same transfer rate as a random file. 

If I understand your data, you're saying you get a much faster
transfer rate with the random file over the all-zeros file, right?
This is very bizarre.  The random file and a file consisting of all
zeros should *not* get the same transfer rate on any modern modem
which does hardware compression (most do).  The all zeros file should
get a much faster transfer rate than the random file.  The reason is
that it is not possible to compress a random file so the best transfer
rate possible would be the line speed (28.8 kbs for a 28.8 modem).  A
file of all zeros is easily compressible so you should do much better
(theoretically 115200 kbs for a 28.8 modem which does hardware
compression but in practice probably much less).

Are you sure your numbers are right?  If so, perhaps you're still
getting overruns even with irqtune, but now much less.  But the
all-zeros file is getting transferred so fast (because of the
compression) that it is seeing many more overruns than the random file
and correcting the overruns is slower than just transferring the file
at the slower rate that the random file is being transfered at.

> I suspect an obscure PPP problem.

I suspect you're right.  Have you set up PPP to use hardware flow
control?  Have you enabled hardware flow control with your modem init
string (it may be the default anyway)?  Are you setting the port speed
to 115200?

Another possibility is that your 16550A UART is not what it claims to be. 
With a non-buffered (8250) UART, I've seen this kind of behavior of faster
transfers actually becoming slower because of the overruns.  I suspect
that irqtune would have much more of an impact on that type of UART as
well.

You might want to try using a communications program like minicom and see
what kind of transfer rates you get there.  This might help isolate
whether it's really a serial problem or a PPP problem. 

Gerry

---

From: ReWt <[email-masked]>
Date: Mon, 26 Aug 1996 12:30:54 -0700 (PDT)

Hello, I was wondering why debian's terminfo doesnt display the differnces 
between char chars ^B, ^_ or combinations. For example with redhat or
slackware ^B == BOLD, which is true with debian as well. However ^_ with
redhat and slackware is == Cyan, and ^B+^_ is == bright cyan. With debian
^_ is == to BOLD, and combinations of ^B+^_ is == to normal. I was
wondering if someone could explain to me how I could make terminfo respond
to these control chars the same way as termcap does in slackware or
Redhat. Thanks.

-====================================================-
-= Senders Name : Shane Robert Stixrud              =-
-= Company Name : CyberChoice Solutions             =-
-= Email Address: [email-masked], [email-masked] =-
-====================================================-

---

From: Kevin M Bealer <[email-masked]>
Date: Tue, 27 Aug 1996 02:59:25 -0400 (EDT)

> compression but in practice probably much less).

Just at a guess (and I don't know ppp internals that well), it
might be PPP escaping the zero as a control character.  If the
software had to handle the escape sequence for "N thousand"
nulls, it might bog it down a bit, and those escape sequences
might themselves take up more space, as they often do.  Really,
though, I can't see that accounting for the difference on a
modem that does compression.  The compression should be more of
a factor than escaping every character even, assuming it IS a
compressed link.

I don't know if PPP even escapes nulls.

(clip)
> Gerry

[email-masked]/GNU__1.1___Linux__2.0.14___
... although "AI" research had centered on the idea of creating
thousands of lines of LISP code which would then somehow become
intelligent ... meanwhile in the darkness, the "EMACS" grew and
grew, unrecognized even by the AI community, fifty, one hundred
times the size of other text editors.  In retrospect the general
lack of suspicion is [perhaps] the most convincing proof ....

  -- "Why they didn't see it coming", New Brittanica 2136

---

From: "Richard G. Roberto" <[email-masked]>
Date: Tue, 27 Aug 1996 08:32:34 -0400 (EDT)

> I've done some statistics regarding irqtune and kernels 2.0.14 and 

There are some nasty panic problems running this kernel with
apache httpd.  I'm not sure about the details ...

> 3) get the same file 10 times with a 'mget file file <etc...>'

** snip **

I got this from the linux-kernel list:

>>From [email-masked] Tue Aug 27 08:23:03 1996
>Cc: Gerry Jensen <[email-masked]>, [email-masked]

 ** patch left in tact **

----

 	
@@ -255,7 +256,7 @@
 	"pushl $-"#nr"-2\n\t" \
 	SAVE_ALL \
 	ENTER_KERNEL \
-	ACK_##chip(mask) \

> I stick with irqtune right now. BTW, I saw no ill side effect when 

I believe there are users testing the patch with improved ppp
performace now -- sans irqtune.  By the way, there seems to be 
a samba tuning issue with kernels >2.0.10.  I'm not sure what
the variable is, but performance can suffer in certain samba
configurations.  I have more details somewhere if anybody
needs them.  I'm sure these issues will be addressed very soon.
The kernel dudes are all aware of them and seem pretty enthused
about fixin' stuff.  Its an interesting list, by the way.  I just
wish I knew what the heck they were talkin' about!

Thanks

Richard G. Roberto
[email-masked]
201-739-2886 - whippany, nj

--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************

---

From: Gerry Jensen <[email-masked]>
Date: Wed, 28 Aug 1996 01:47:22 -0600 (MDT)

> I don't know if PPP even escapes nulls.

You set up what characters you want escaped (in the receive direction) in
the /etc/ppp/options file (or ~/.ppprc) with the "asyncmap <map>" option. 
<map> is a 32 bit hex number with each bit representing a character to
escape.  "asyncmap 0x00000000" will escape no characters which is what one
would want in the general case (8-bit clean line, hardware flow control). 
If you omit the asyncmap option, *all* control characters (0-31 decimal)
are escaped.  So forgetting to put in the asyncmap option will slow down
your PPP connection by about 12.5% (if my math is correct) for random
data.  Transfering a file of all zeros should make your connection twice
as slow if your modem is not doing hardware compression.

Gerry