Date: Mon, 14 Jun 2004 01:36:58 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Jon Noack <noackjr@alumni.rice.edu> Cc: current@FreeBSD.org Subject: Re: Device polling Message-ID: <20040613223658.GB55275@ip.net.ua> In-Reply-To: <40CCC201.6080804@alumni.rice.edu> References: <Pine.BSF.4.58L0.0406110957020.49590@crimp.gluerecord.net> <40CC97E0.5010003@alumni.rice.edu> <20040613181315.GB54104@ip.net.ua> <40CCC201.6080804@alumni.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 13, 2004 at 04:07:13PM -0500, Jon Noack wrote: > On 06/13/04 13:13, Ruslan Ermilov wrote: > >On Sun, Jun 13, 2004 at 01:07:28PM -0500, Jon Noack wrote: > >>I just tested this on my SMP all-in-one home server (Web, Mail, > >>NFS, Samba, Squid, etc.). It's been up for over 24 hours with no > >>apparent issues. The machine is used pretty heavily, with NFS > >>mounted home directories and CVS mirror (see below) -- a CVS update > >>of the src tree over NFS has done a good job of breaking fragile > >>setups in the past. Everything seemed OK. That said, peak > >>performance (as tested by iperf) took a nosedive: with 32-bit em > >>adapters (gige), tcp bandwidth dropped from over 360Mbps to around > >>200 Mbps. If anyone has any suggestions for more in-depth testing, > >>I'd be willing to try them. If I have the time I may also try the > >>latest netperf patch and see how that affects things. > > > >What are your operational polling(4) parameters? What the HZ is set > >to? >=20 > HZ=3D1000 and I was using the defaults for polling. Bumping up burst_max= =20 > to 300 results in slightly better peak performance at 220 Mbps.=20 > polling(4) says burst_max=3D150 is good for HZ=3D1000 and 100 Mbit networ= ks;=20 > are there any recommendations (for burst_max or in general) for 1 Gbit=20 > networks? >=20 > $ sysctl kern.polling > kern.polling.burst: 150 > kern.polling.each_burst: 5 > kern.polling.burst_max: 150 > kern.polling.idle_poll: 0 > kern.polling.poll_in_trap: 0 > kern.polling.user_frac: 50 > kern.polling.reg_frac: 20 > kern.polling.short_ticks: 2000 > kern.polling.lost_polls: 403164 > kern.polling.pending_polls: 0 > kern.polling.residual_burst: 0 > kern.polling.handlers: 1 > kern.polling.enable: 1 > kern.polling.phase: 0 > kern.polling.suspect: 365727 > kern.polling.stalled: 0 > kern.polling.idlepoll_sleeping: 1 >=20 Read the polling(4) manpage very carefully, to understand what these various parameters mean. Experiment. Bump HZ. If you were using the 64-bit PCI I'd say bump it to 5000, but since you're using 32-bit PCI, bumping it that high just doesn't make sense, so raise it up to 2000-3000. Set kern.polling.idle_poll=3D1. Set kern.polling.user_frac=3D30. Raising up kern.polling.burst_max might help as well. Remember, the maximum number of packets each interface can receive per second with polling enabled is (burst_max * HZ). When tuned properly, and if the card is not rl(4), you will usually get better peak performance in polling mode than in interrupt mode. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAzNcKqRfpzJluFF4RAlhZAJ9j8srVEd7GWvf0VFTmVKh0kNAaxwCcCzUE 1cUGLJEjMjOW5BqVtR4zfZw= =P2bF -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040613223658.GB55275>