From owner-freebsd-performance@FreeBSD.ORG Fri Nov 19 18:12:43 2010 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 090EB106566B for ; Fri, 19 Nov 2010 18:12:43 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from imr-db03.mx.aol.com (imr-db03.mx.aol.com [205.188.91.97]) by mx1.freebsd.org (Postfix) with ESMTP id BCE878FC0C for ; Fri, 19 Nov 2010 18:12:42 +0000 (UTC) Received: from imo-da02.mx.aol.com (imo-da02.mx.aol.com [205.188.169.200]) by imr-db03.mx.aol.com (8.14.1/8.14.1) with ESMTP id oAJICevO005246 for ; Fri, 19 Nov 2010 13:12:40 -0500 Received: from dieterbsd@engineer.com by imo-da02.mx.aol.com (mail_out_v42.9.) id n.f4c.82607ab (45477) for ; Fri, 19 Nov 2010 13:12:34 -0500 (EST) Received: from smtprly-ma03.mx.aol.com (smtprly-ma03.mx.aol.com [64.12.207.142]) by cia-mc06.mx.aol.com (v129.7) with ESMTP id MAILCIAMC066-5c564ce6be0add; Fri, 19 Nov 2010 13:12:33 -0500 Received: from web-mmc-d05 (web-mmc-d05.sim.aol.com [205.188.103.95]) by smtprly-ma03.mx.aol.com (v129.5) with ESMTP id MAILSMTPRLYMA034-5c564ce6be0add; Fri, 19 Nov 2010 13:12:26 -0500 To: freebsd-performance@freebsd.org Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2010 13:12:26 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 67.206.164.39 X-MB-Message-Type: User MIME-Version: 1.0 From: dieterbsd@engineer.com Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailer: Mail.com Webmail 32945-STANDARD Received: from 67.206.164.39 by web-mmc-d05.sysops.aol.com (205.188.103.95) with HTTP (WebMailUI); Fri, 19 Nov 2010 13:12:26 -0500 Message-Id: <8CD562C7462116D-1204-3BE9@web-mmc-d05.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: dieterbsd@engineer.com Subject: Re: TTY task group scheduling X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 18:12:43 -0000 Alexander writes: > One thing that just begs to be asked: since when decoding 1080p became > an interactive task? Normally, decoding video would not be considered an interactive task, unless you are doing things like stepping through frame-by-frame. Playing video, and/or audio is a true real time task. The computer must perform the work at a specific rate, not faster, not slower. Recording video and/or audio is also a true real time task, If the machine/OS drops the ball you have a spoiled recording, and most of the time you can't try again. Bruce writes: > you > can have a load of 100 or more before the system becomes unusable > whereas people are amazed to see loads of more than 15 on Linux. The load average leaves much to be desired as a metric. I have generated an obscenely high lead average while retaining great responsiveness, and done a simple "cp /disk1/file1 /disk2/" resulting in the machine taking *minutes* to respond to the simplest command. Andriy writes: > Well, I am not sure if I can agree about CPU-bound-ness. > Depends on the exact video file, of course, but certain high-quality=20 1080p are > very CPU intensive unless decoding is offloaded from the CPU. =20 Depends on > decoder code too. I had some videos that were CPU-bound on my Athlon=20 II X2 250 > with then-version of mplayer from ports. The bitrate is more useful than saying "1080p". The speed of the CPU is important, the codec, the efficiency of the decoder, whether parts can=20 be offloaded to a GPU or hardware decoder, if the output is being scaled,=20 etc. If playing a video maxes out the CPU, then the video isn't going to be displayed correctly.