PPP system with unwanted packet dropping at traffic overload - PPP

This is a discussion on PPP system with unwanted packet dropping at traffic overload - PPP ; Hi, We are implementing a system (basically a modem operating as a router) with embedded Linux (currently v2.6.25.16) where tailor made communication between the embedded platforms happens over PPP (in addition to Ethernet interfaces also available). Due to specialized hardware, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: PPP system with unwanted packet dropping at traffic overload

  1. PPP system with unwanted packet dropping at traffic overload

    Hi,

    We are implementing a system (basically a modem operating as a router) with
    embedded Linux (currently v2.6.25.16) where tailor made communication
    between the embedded platforms happens over PPP (in addition to Ethernet
    interfaces also available). Due to specialized hardware, we have developed
    our own PPP driver. This is not a *network* driver, but instead a *char*
    driver. I.e. we let our PPP talk with a serial tty interface (emulating an
    UART interface). This interface is now working.

    However, in periods of traffic overload, packet drops happens *inside* the
    PPP system, and not in the Linux forwarding TCP/IP queue system. This is not
    good because we now want to use advanced queuing systems supporting DiffServ
    (using tc). The driver has a queue length internally of 5 packets, and
    returns EAGAIN when queue is full (the driver operates in non-blocking
    mode). It looks like the PPP layer above do not try to resubmit the packet,
    but turns to dropping instead. Because of this, the ppp0 interface looks
    like a high-rate interface, and the Linux queuing system never backlogs as
    it should.

    We are unsure if any netif_stop_queue/netif_wake_queue functionality is used
    by the PPP upper layers. We would be happy to receive any suggestions.

    Best regards,

    Arne Lie
    SINTEF ICT, Dept. of Communication Systems
    e-mail: arne.lie@sintef.no

    PS:

    The PPP is started with:
    pppd /dev/pppfifo0
    (pppfifo is the name of the device tty driver) and the options file includes
    noctsrts
    lock
    passive

    In our pppfifo driver we have implemented:
    .throttle = pppfifo_throttle, (but it does not stop new data coming...)
    .unthrottle = pppfifo_unthrottle,
    .stop = pppfifo_stop,
    .start = pppfifo_start
    and in addition:
    .tiocmget = pppfifo_tiocmget,
    .tiocmset = pppfifo_tiocmset,
    We observe some ioctrl messages, but have not decoded them yet. Perhaps we
    need a detailed look at these?


  2. Re: PPP system with unwanted packet dropping at traffic overload

    In article ,
    Arne Lie wrote:
    >However, in periods of traffic overload, packet drops happens *inside* the
    >PPP system, and not in the Linux forwarding TCP/IP queue system. This is not
    >good because we now want to use advanced queuing systems supporting DiffServ
    >(using tc). The driver has a queue length internally of 5 packets, and
    >returns EAGAIN when queue is full (the driver operates in non-blocking
    >mode).

    Why is your queue limited to 5 packets? Why don't you just create a linked-
    list queue??

    >It looks like the PPP layer above do not try to resubmit the packet,
    >but turns to dropping instead. Because of this, the ppp0 interface looks
    >like a high-rate interface, and the Linux queuing system never backlogs as
    >it should.

    I don't know any specifics about the Linux PPP you're using, but if you know
    the problem is due to your 5 packet queue, why wouldn't you just boost the
    queue size?

    Patrick
    =========== For PPP Protocol Analysis, check out PacketView Pro! ===========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ================================================== ==========================

  3. Re: PPP system with unwanted packet dropping at traffic overload

    "Patrick Klos" wrote in message
    news:gababm$193e$1@pyrite.mv.net...
    > In article ,
    > Arne Lie wrote:
    >>However, in periods of traffic overload, packet drops happens *inside* the
    >>PPP system, and not in the Linux forwarding TCP/IP queue system. This is
    >>not
    >>good because we now want to use advanced queuing systems supporting
    >>DiffServ
    >>(using tc). The driver has a queue length internally of 5 packets, and
    >>returns EAGAIN when queue is full (the driver operates in non-blocking
    >>mode).
    >
    > Why is your queue limited to 5 packets? Why don't you just create a
    > linked-
    > list queue??
    The queue of 5 packets is more than enough: we also have to consider
    latency, this is a slow link.
    >
    >>It looks like the PPP layer above do not try to resubmit the packet,
    >>but turns to dropping instead. Because of this, the ppp0 interface looks
    >>like a high-rate interface, and the Linux queuing system never backlogs as
    >>it should.
    >
    > I don't know any specifics about the Linux PPP you're using, but if you
    > know
    > the problem is due to your 5 packet queue, why wouldn't you just boost the
    > queue size?
    In traffic overload any queue size would eventually be too small. See our
    next post about ppp XMIT_WAKEUP. Thanks for replying, though!!!

    /Arne

    >
    > Patrick
    > =========== For PPP Protocol Analysis, check out PacketView Pro!
    > ===========
    > Patrick Klos Email: patrick@klos.com
    > Klos Technologies, Inc. Web: http://www.klos.com/
    > ================================================== ==========================


+ Reply to Thread
« ppp XMIT_WAKEUP flag: who sets it? | HDLC over ttyS0 »