Re: 2.5.74-mm1

[Nick Piggin]

Davide Libenzi wrote:

>On Tue, 8 Jul 2003, Daniel Phillips wrote:
>
>
>>1. 400ms buffers are hated by users, as was noted previously.  They are
>>passable for some applications, but way too laggy for others.
>>
>>2. Even if you are will to have a 400-500 ms buffer, if you can prove that you
>>will always meet that deadline, then it's a realtime system.
>>
>>3. If you can show logically that you will nearly always meet the deadline,
>>it's a soft realtime system.  That's what we're after here.  From a design
>>standpoint, there are elegant soft realtime systems, and there are sucky
>>ones.
>>
>>4. So how do you propose to "program timings" so that it's really hard to miss
>>those deadlines?
>>
>
>Having a backup of 400-500ms gives you an average hang-over of 200-250ms
>that are hardly noticeable by a human in this topic. The issue is not if
>you always meet the deadline, the issue is what amount of load will make
>you miss it. If I have to hire five ppl clicking and dragging on my desktop
>to make my player to skip, and it skips, I don't care if it missed the
>deadline. This because my desktop will hardly see that load. But if you
>have a 50-100ms backup, things turns out to be a little bit different.
>If you pretend to run a `make -jUNREAL` and still have the audio not
>skipping it is simply wrong. Running a `make -j20` in my machine shows an
>average of 24 TASK_RUNNING tasks, that even if they're granted with a mere
>40ms timeslice, it'll take a full second before an expired task will see
>the light again. BTW, under such load RealPlayer skips badly, but I don't
>really care since it never did while I was doing all the normal (and many
>extra) stuff I'm doing on my desktop.
>
>

I agree some people have some inflated ideas about a desktop workload,
but I'd just point out that if your mp3 player was using say 2% CPU,
it should be able to preempt the make soon after it becomes runnable,
and not have to wait at the end of the queue. It would become a CPU
hog itself if you had 48 other processes running though.