Re: Device polling, kern.polling.burst_max and gig-e

From: Steve Francis (steve_at_expertcity.com)
Date: 01/30/04

  • Next message: Luigi Rizzo: "Re: Device polling, kern.polling.burst_max and gig-e" 
    Date: Fri, 30 Jan 2004 10:46:06 -0800
To: Luigi Rizzo <rizzo@icir.org>

    Luigi Rizzo wrote:

    >i would probably increase HZ to 2000 and burst_max to 300-400,
    >not much more though otherwise you are going to spend too much
    >time in the timer handler.
    >In any case, i don't think the card is able to go above 6-700kpps.
    >
    >
    OK, thanks.
    Each card is only being asked to do (at most ) 250kpps. Two cards with
    that load in the system.

    No tuning of

    kern.polling.each_burst recommended?
    Thanks

    >If you are having a lot of load, it is natural that you are
    >going to get losses, the 2sec period is probably how often the
    >nic updates the stats.
    >
    > cheers
    > luigi
    >
    >On Fri, Jan 30, 2004 at 10:34:08AM -0800, Steve Francis wrote:
    >
    >
    >>We have a 4.9-RELEASE-p1 box dedicated to some traffic analysis. It
    >>monitors on two em interfaces: about 200,000 pps on one interface, and
    >>180,000 pps on the other.
    >>It's been dealing with that OK, but our traffic levels are increasing -
    >>we reached over 240,000 pps on one interface last week. This made CPU
    >>reach 100%, and some packets not get processed.
    >>So, last night we enabled polling on the nics.
    >>Initially, great result - CPU dropped from 82% load (45% system load due
    >>to interupts) yesterday to 55% load today (12% in system), for same pps
    >>load (about 300,000 pps total) at the time.
    >>
    >>However, input errors went from 0 to about 1200 (oddly, it was 1200
    >>every other second, and 0 for the seconds in-between.)
    >>
    >>A bit of digging around led me to increase kern.polling.burst_max.
    >>According to http://info.iet.unipi.it/~luigi/polling/, "The default
    >>value is enough for a 100Mbit ethernet". I increased it gradually to
    >>900, whcih has almost (but not entirely) eliminated the errors. Now the
    >>errors are zero for most intervals, but every 10 or so intervals there
    >>are between 10 and 100 input errors.
    >>
    >>So:
    >>- does it make sense to leave the default at 150, in this day of gigabit
    >>nics?
    >>- is there a danger in increasing the burt_max? (My burst size goes
    >>straight to the max of 900.)
    >>- can it be increased more ?
    >>- are there other variables that make sense to increase for gigabit?
    >>(like kern.polling.each_burst:?)
    >>
    >>Since I increased the burst max, I now have slowly incrementing
    >>kern.polling.lost_polls - about 1 every 2 seconds. Anything to worry about?
    >>
    >>Thanks
    >>Steve Francis
    >>
    >>
    >>
    >>
    >>_______________________________________________
    >>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"
    >>
    >>

    _______________________________________________
    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: Device polling, kern.polling.burst_max and gig-e"

    Relevant Pages

    • Re: Test on 10GBE Intel based network card
      ... Ignore my last mail direct to you, 638976 PPS is awful. ... Are you passing any parameters to the driver in boot.conf. ... network device drivers among other things. ... traffic from card A goes to card B and all the traffic from card B goes to ...
      (freebsd-performance)
    • Re: Meinberg PPS signal is not synchronous with refclock signal
      ... The PCI511 card decodes the AM signal from DCF77 only. ... I did not wonder about the offset between gps ... and pps but about the offset between gps refclock and it's own gps pps ... (same for dcf refclock and it's own dcf pps). ...
      (comp.protocols.time.ntp)