Re: Issues with a Large Fat pipe Network simulation

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 06/21/05

  • Next message: Luigi Rizzo: "Re: Policy routing idea (Was: ipfw: Would it be possible to continue processing rest of rules after match ?)" 
    Date: Tue, 21 Jun 2005 12:36:18 -0700
To: Pieter de Boer <pieter@thedarkside.nl>

    On Tue, Jun 21, 2005 at 09:11:57PM +0200, Pieter de Boer wrote:
    > Luigi Rizzo wrote:
    >
    > > oh yes one thing... you are using 'via foo0' in your rule,
    > > which means the packet is intercepted both in the input and
    > > output path, which causes further contention on the queues.
    > Well, when using 'ip from client to server recv em0', packets get

    i said 'in recv em0' - you missed the 'in' keyword.

    > > I am pretty sure there is some issue there, also related to some
    > > timing issues and tcp window opening mode (slow start vs. linear)
    > I went to see if there were any sysctl's I could tune a bit. I found these:
    > net.inet.ip.intr_queue_maxlen: 50
    > net.inet.ip.intr_queue_drops: 382136
    >
    > I don't like drops. So I set intr_queue_maxlen to 400, and -poof-, the

    whoops... of course, i forgot that one too... which is not much
    of an issue if you use polling or bridging, that's why i forgot :)

    > speed went up to around 700mbit/s. Still not as fast as it was with 64KB
    > send/recv spaces, but it's a huge improvement nonetheless.
    >
    > I guess we probably should tune a bit more until we're confident that
    > the middle-box behaves correctly, before adding things like latency and
    > packet-loss :)
    >
    > Thanks for the advice! If you know other settings to tune on the
    > dummynetting host, I'd very much like to hear them. I'm pondering about
    > polling (which means we can't do SMP on the dummynet system, but it's
    > only pushing packets, so that shouldn't matter too much). At least we
    > have somewhat more info to work with now :)

    yes you should definitely enable polling if you can, and forget about
    smp - it's a router anyways, and multiple processors won't help.

    cheers
    luigi
    _______________________________________________
    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: Luigi Rizzo: "Re: Policy routing idea (Was: ipfw: Would it be possible to continue processing rest of rules after match ?)"

    Relevant Pages

    • Re: Polling tuning and performance
      ... What I'm aiming for, of course, is zero packet loss. ... network traffic and that only by polling). ... so with most interrupts avoided by using polling it has little effect. ...
      (freebsd-performance)
    • Re: [antinvidia@gmail.com: some questions about bge(4)]
      ... known bugs cause brgphy_serviceto often lose a packet. ... if the system can't actually poll at 1/HZ. ... since at least 1500 packets of buffering would be needed for polling ... Polling in idle can work better if the system is actually idle. ...
      (freebsd-net)
    • Re: Polling For 100 mbps Connections? (Was Re: Freebsd Theme Song)
      ... Polling For 100 mbps Connections? ... from the network into the ethernet receiver. ... It takes a certain amount of time to get the packet out of ... not in the ethernet driver code. ...
      (freebsd-questions)
    • Re: Proposed 6.2 em RELEASE patch
      ... Without kernel polling ... it seems that default interrupts moderation on em is ... call em_txeof if there's more than 32 busy packet ...
      (freebsd-net)
    • Re: Poor NFS server performance in 6.0 with SMP and mpsafenet=1
      ... > seems to increase latency on response to packets. ... > few machines which run with polling on, and for those usage patterns it ... achieves, IIUC, the same goal as our software polling: when the timer ... also have a "packet timer", and this is very interesting and just ...
      (freebsd-current)