From owner-freebsd-questions@FreeBSD.ORG Sat Nov 21 17:10:18 2009 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660891065670 for ; Sat, 21 Nov 2009 17:10:18 +0000 (UTC) (envelope-from mel.flynn+fbsd.questions@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 13B3E8FC0C for ; Sat, 21 Nov 2009 17:10:16 +0000 (UTC) Received: from mx1.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 0E6807E853 for ; Sat, 21 Nov 2009 08:10:16 -0900 (AKST) Received: from dspam.sbmail.office-on-the.net (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with SMTP id 8A770C2CB05 for ; Sat, 21 Nov 2009 08:10:15 -0900 (AKST) Received: from webmail.testbox.ath.cx (mx1.sbmail.office-on-the.net [192.168.2.107]) by mx1.sbmail.office-on-the.net (Postfix) with ESMTP id 80849C2CB04; Sat, 21 Nov 2009 08:10:14 -0900 (AKST) MIME-Version: 1.0 Date: Sat, 21 Nov 2009 08:10:14 -0900 From: Mel Flynn To: Brett Glass In-Reply-To: <200911210207.TAA21572@lariat.net> References: <200911202135.OAA18537@lariat.net> <200911210207.TAA21572@lariat.net> Message-ID: X-Sender: mel.flynn+fbsd.questions@mailing.thruhere.net User-Agent: RoundCube Webmail/0.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DSPAM-Result: Innocent X-DSPAM-Processed: Sat Nov 21 08:10:15 2009 X-DSPAM-Confidence: 0.9899 X-DSPAM-Improbability: 1 in 9809 chance of being spam X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 89,4b081ef742361351413057 X-DSPAM-Factors: 27, but, 0.01000, but, 0.01000, Content-Type*charset="UTF+8", 0.01000, Received*webmail.testbox.ath.cx, 0.01000, From*>It is further explained by >>the >>comment in sys/kern/kern_poll.c: >>/* >> * Hook from hardclock. Tries to schedule a netisr, but keeps track >> * of lost ticks due to the previous handler taking too long. >> * Normally, this should not happen, because polling handler should >> * run for a short time. However, in some cases (e.g. when there are >> * changes in link status etc.) the drivers take a very long time >> * (even in the order of milliseconds) to reset and reconfigure the >> * device, causing apparent lost polls. >> * >> * The first part of the code is just for debugging purposes, and trie= s >> * to count how often hardclock ticks are shorter than they should, >> * meaning either stray interrupts or delayed events. >> */ >=20 > Well, even at HZ=3D2000, kern.polling.lost_polls and=20 > kern.polling.suspect are both incrementing, as is kern.polling.stalled: >=20 > stargate# sysctl -a | grep polling > kern.polling.burst: 150 > kern.polling.burst_max: 150 > kern.polling.each_burst: 5 > kern.polling.idle_poll: 0 > kern.polling.user_frac: 50 > kern.polling.reg_frac: 20 > kern.polling.short_ticks: 0 > kern.polling.lost_polls: 41229 > kern.polling.pending_polls: 0 > kern.polling.residual_burst: 0 > kern.polling.handlers: 2 That bugs me: if you have 6 devices, the number of handlers should be 6. /* * Try to register routine for polling. Returns 0 if successful * (and polling should be enabled), error code otherwise. * A device is not supposed to register itself multiple times. * * This is called from within the *_ioctl() functions. */ Unless this should really read "drivers", but I think it's devices. > kern.polling.enable: 0 > kern.polling.phase: 0 > kern.polling.suspect: 31653 > kern.polling.stalled: 10 > kern.polling.idlepoll_sleeping: 1 > hw.acpi.thermal.polling_rate: 10 >=20 > But if I slow the clock down to 1000 Hz, it's unclear if the=20 > machine will be able to keep up with traffic. I was already getting=20 > more than 1,000 network interrupts per second before I tried=20 > polling, and I'm not sure how many packets the interfaces (some=20 > fxp, some em) can buffer up. I'm going to try it, but if it doesn't=20 > work I will have to go back to interrupt-driven operation. You might be able if your network architecture allows it, to bring down the task load by increasing the MTU and enable jumbo frames. >From em(4): Support for Jumbo Frames is provided via the interface MTU setting. Selecting an MTU larger than 1500 bytes with the ifconfig(8) utility con=E2=80=90 figures the adapter to receive and transmit Jumbo Frames. The maximu= m MTU size for Jumbo Frames is 16114. --=20 Mel