lkml.org 
[lkml]   [1997]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.0.30 serial.c, ppp.c and pppd-2.2 questions
    -----BEGIN PGP SIGNED MESSAGE-----

    Hi,

    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 Andries.Brouwer@cwi.nl wrote:
    >Theodore Y. Ts'o:
    >
    >: Date: Thu, 24 Jul 1997 00:06:25 +0200
    >: From: Andries.Brouwer@cwi.nl
    >
    >: Possibly entirely unrelated (you are talking about missed timer
    >interrupts,
    >: 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.
    >
    >Andries
    >
    >
    - ---
    Manuel J. Galan
    manolow@step.es

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

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

    iQB1AgUBM9gRW9LJkgqGw1hxAQFLwgL+MeU0S8HsveFpYwb0/zBZhaHS4yMoYOXt
    X99vr2snyfJ1644TYFxZ9NbAG7Tk12AEsQuBmkn6KFw0MD8vsSpqeIAEpOKC2QEc
    imcY2G4nEggM6y3354gPanlRFYPYSnXc
    =C2yT
    -----END PGP SIGNATURE-----

    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.027 / U:0.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site