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>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8CD562C7462116D-1204-3BE9>