Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions

Manuel J. Galan (
Fri, 25 Jul 1997 03:19:07 +0100 (WET DST)



Well I am runnung 2.1.4[67] with a startech 16c650 serial connected
to a Zyxel ISDN TA (Omni Ta 128) at 460800 baud against a CISCO 2500
IOS 11.2(3)

When there is only one line (64Kb + stac compression) everything goes
more or less OK but when both lines join in a Multilink PPP connection
ppp chokes and transference stops for a while, then restarts and stops
again and so on. The result is that I get ~ 7 Kbyte/s whith two lines joined
in a large compressed file transfer... Not very good, mostly because I get
almost the same speed (or even better) using only one line.

Thansferring normal files, it is a real pity as the stac compression
could make transfer speed reach 50-55 Kbyte/s (as it does in M$ NT4) and
I only can get 8-10 KB/s under Linux.

My hardware is a tyan dual ppro with two cpu at 200Mhz, _no ide_, bt-958
scsi + scsi disks. only one serial active and ps/2 mouse.

Irqtune makes no difference.
I have tried ppp 2.2.0, 2.3.0 and 2.3.1 at no avail...

The thing that drives me mad is that NT4 _does_ work OK.

On 25-Jul-97 wrote:
>Theodore Y. Ts'o:
>: Date: Thu, 24 Jul 1997 00:06:25 +0200
>: From:
>: Possibly entirely unrelated (you are talking about missed timer
>: probably I am talking about missed serial line interrupts) but
>: my SLIP connection is completely unusable when something disk-intensive
>: is running. FTP gets into an exponential backoff and seems to hang
>: completely, but recovers some time after the make/find/whatever has
>: finished.
>: [This happens both with IDE and SCSI activity. I never really
>: investigated.]
>: At least for the IDE case, this is the very well known problem of the
>: IDE driver disabling interrupts to prevent data corruption in a few
>: badl;y designed IDE controllers. If you don't have the bad IDE
>: controllers (see the man page for more details), you will likely be able
>: to use "hdarm -u 1" which will fix the problem without causing your
>: disks to get massively corruption.
>: As far as the SCSI activity, my guess it is a similar problem, but the
>: solution to solve it is very dependent on the SCSI manufacturer.
>: - Ted
>You are an optimist.
>(On the one hand "hdparm -u 1" does cause corruption here,
>on the other hand, it doesnt help at all.)
>Suppose something is wrong in the scheduler, and processes
>with finished disk I/O get too much attention.
>I just showed my son how an e2fsck on a large SCSI disk really
>stopped all other activity.
- ---
Manuel J. Galan

Sent on 25-Jul-97 03:37:15

Version: 2.6.3ia
Charset: noconv
Comment: Requires PGP version 2.6 or later.