Date: Fri, 19 Nov 2010 13:12:26 -0500 From: dieterbsd@engineer.com To: freebsd-performance@freebsd.org Subject: Re: TTY task group scheduling Message-ID: <8CD562C7462116D-1204-3BE9@web-mmc-d05.sysops.aol.com>
index | next in thread | raw e-mail
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 1080p are > very CPU intensive unless decoding is offloaded from the CPU. Depends on > decoder code too. I had some videos that were CPU-bound on my Athlon 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 be offloaded to a GPU or hardware decoder, if the output is being scaled, etc. If playing a video maxes out the CPU, then the video isn't going to be displayed correctly.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CD562C7462116D-1204-3BE9>