Re: Increasing interface queues

From: Archie Cobbs (archie_at_dellroad.org)
Date: 07/23/03

  • Next message: Julian Elischer: "Re: NAT and PPTP"
    To: Mike Tancsa <mike@sentex.net>
    Date: Tue, 22 Jul 2003 20:55:58 -0700 (PDT)
    
    

    Mike Tancsa wrote:
    > We have a box terminating a lot of MPD tunnels from dialup
    > connections. When the modems at remote sites renegotiate due to poor line
    > quality, there will be a pause in the flow of data. Occasionally, the
    > interface on the terminating side will get a "no buffer space" as data is
    > accumulating to be sent out. Is there a way for me to increase those queue
    > sizes so that the server's queue has more room to hold the data until the
    > other end is ready to receive again ?
    >
    > The only sysctl var I could see
    > % sysctl -a | grep -i queue
    > net.inet.ip.intr_queue_maxlen: 50
    > net.inet.ip.intr_queue_drops: 0
    > p1003_1b.sigqueue_max: 0
    >
    > I dont think is related to this issue.

    The ENOBUFS is coming from ng_pptpgre(4) and really means "the PPTP
    transmit window is full". The fact that PPTP has such a window is
    itself a bug (L2TP is better). But in any case increasing that queue
    length is not the right answer.. you actually want short queues (just
    long enough to handle burstiness in the flow of packets) to avoid
    excessive latency, and to let TCP etc. do its thing.

    If you want ng_pptpgre(4) to just silently drop the packets instead
    apply the patch below.

    -Archie

    __________________________________________________________________________
    Archie Cobbs * Halloo Communications * http://www.halloo.com

    Index: ng_pptpgre.c
    ===================================================================
    RCS file: /home/ncvs/src/sys/netgraph/ng_pptpgre.c,v
    retrieving revision 1.2.2.13
    diff -u -r1.2.2.13 ng_pptpgre.c
    --- ng_pptpgre.c 10 Oct 2002 18:27:54 -0000 1.2.2.13
    +++ ng_pptpgre.c 23 Jul 2003 03:55:52 -0000
    @@ -491,7 +491,7 @@
    >= a->xmitWin) {
                             priv->stats.xmitDrops++;
                             NG_FREE_DATA(m, meta);
    - return (ENOBUFS);
    + return (0);
                     }
     
                     /* Sanity check frame length */
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: Julian Elischer: "Re: NAT and PPTP"

    Relevant Pages

    • Re: Increasing interface queues
      ... Is there a way for me to increase those queue ... The ENOBUFS is coming from ng_pptpgre(4) and really means "the PPTP ... transmit window is full". ... If you want ng_pptpgreto just silently drop the packets instead ...
      (freebsd-questions)
    • Re: Possible bug in .Net 2.0 udp sockets?
      ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
      (microsoft.public.dotnet.framework)
    • Re: Performance Intel Pro 1000 MT (PWLA8490MT)
      ... driver changed to not use the braindamaged sk interrupt moderation. ... with small 50-60 byte UDP packets. ... when the tx queue fills up, the application should stop sending, at ... For transmission, with non-broken hardware and software, ...
      (freebsd-performance)
    • Re: [PATCH] 3/3 maple: update bus driver to support Dreamcast VMU
      ... Removes unneeded locking of queue of processed packets while properly ... Under what conditions will this lock be ...
      (Linux-Kernel)
    • Re: packet filter : official documentation not enought, questions remain
      ... First queue set up. ... qint is for internal traffic, qext is ... queue qint bandwidth 99% priority 2 cbq ... You have NO control over inbound packets. ...
      (comp.unix.bsd.openbsd.misc)