From owner-freebsd-questions@FreeBSD.ORG Wed Jul 6 18:55:32 2005 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70E3116A41C for ; Wed, 6 Jul 2005 18:55:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2340F43D46 for ; Wed, 6 Jul 2005 18:55:32 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 511275144F; Wed, 6 Jul 2005 14:55:31 -0400 (EDT) Date: Wed, 6 Jul 2005 14:55:31 -0400 From: Kris Kennaway To: freebsd-questions@freebsd.org Message-ID: <20050706185531.GA31552@xor.obsecurity.org> References: <44u0j7iyep.fsf@be-well.ilk.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <44u0j7iyep.fsf@be-well.ilk.org> User-Agent: Mutt/1.4.2.1i Cc: "Scott I. Remick" Subject: Re: Weird "nice" behavior X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2005 18:55:32 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 06, 2005 at 02:26:22PM -0400, Lowell Gilbert wrote: > "Scott I. Remick" writes: >=20 > > I'm seeing something strange/annoying tonight... maybe someone could he= lp > > explain why it's happening. > >=20 > > FreeBSD 5.4-RELEASE > >=20 > > I'm trying to do a large local rsync in the background, while listening= to > > streaming audio via RealPlayer and do other stuff. I have the rsync > > running at nice level 20 ("nice -20") which I've confirmed via ps: > >=20 > > 1001 77010 1452 0 116 20 45056 44332 select SN+ p1 0:30.89 rsyn= c -av -=20 > > 1001 77011 77010 295 139 20 45048 44232 - RN+ p1 20:17.12 rsyn= c -av -=20 > > 1001 77548 77011 0 116 20 45200 44460 select SN+ p1 0:12.06 rsyn= c -av - > >=20 > > RealPlayer is running at normal nice (0): > > 1001 80675 80650 16 98 0 30004 12516 select S p2 0:22.69 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80688 80675 0 96 0 30004 12516 select S p2 0:00.01 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80689 80688 0 20 0 30004 12516 pause S p2 0:02.67 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80692 80675 24 -8 0 13844 6772 piperd I p2 0:00.00 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80693 80675 24 -8 0 13844 6772 piperd I p2 0:00.00 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80694 80688 24 20 0 30004 12516 pause I p2 0:00.00 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80695 80688 0 20 0 30004 12516 pause S p2 0:01.34 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80696 80688 0 8 0 30004 12516 nanslp S p2 0:01.13 /usr= /local/lib/RealPlayer/realplay.bin > > 1001 80765 80688 0 8 0 30004 12516 nanslp S p2 0:01.10 /usr= /local/lib/RealPlayer/realplay.bin > >=20 > > Not sure why it spawns so many processes, but whatever... > >=20 > > Anyway, what's happening is despite rsync being nice 20, RealPlayer is > > incredibly choppy. Even if I'm not doing anything else on the system.= =20 > >=20 > > Now here's the weirder part: if I DO do something, such as just scrolli= ng > > a window, the audio stream stops being choppy. It's as if it takes some > > OTHER application claiming CPU cycles to get rsync to properly play "ni= ce" > > and release up time, at which point RealPlayer gets the cycles it > > deserves. But for some reason, rsync with just RealPlayer on its own wi= ll > > not play "nice" and give up time to RealPlayer like it should since > > RealPlayer is running at 0 and rsync is running at 20. >=20 > Sounds like you're blocked on I/O, not CPU. =20 > SCSI drives with tagged queueing would probably perform better. Also look for Jeff Roberson's patch that addresses this performance problem, which was sent (and committed) to -current a month or so ago, and which I think I forwarded to -stable. Kris --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCzCkiWry0BWjoQKURAgRjAKCQd9BAipljfqzE/cSFt19JxkksbACg45Ag WLABeOijaKomZwtsErCBGMc= =I0qZ -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--