Re: [SHED] Questions.

[Ian Kumlien]

On Mon, 2003-09-01 at 16:21, Antonio Vargas wrote:
> On Mon, Sep 01, 2003 at 02:00:09AM +0200, Ian Kumlien wrote:
> > Yes, But... When you come from AmigaOS, and have used Executive...
> > things like this is dis concerning. Executive is a scheduler addition
> > for amigaos that has many schedulers to choose from. One of which is the
> > original feedback scheduler. While a feedback scheduler consumes some
> > cpu it still allows you to play mp3's while surfing the net on a 50 mhz
> > 68060. Hearing about 500mhz machines that skip is somewhat.. odd.
> 
> Ian, I came from Amiga to Linux many moons ago, and their target are
> very different... on Amiga, the mouse pointer is drawn as a hardware
> sprite (same as an C64 or an arcade machine), and the mouse
> movement counters are handled in hardware too, so your mouse pointer
> can't _EVER_ get laggy.

I also joined linux a long time ago... but the hardware pointer is not
the issue. I'm more referring to using cpublit and dragging the
scrollbar in a window... Like f.ex. Voyager.

(And, in this case, 50Mhz is the limitation not the scheduler. With 10
times that power i bet you could do it all with the cpu, just like a
common pc today.)

> The sound system is very different, on Amiga you ask the system to
> callback to you when audio needs replenishing, and anyways you could
> boost the player priority so that multichanel or mp3 playing gets more
> priority than other tasks. I can recall playing mp3 on a 68030/50
> and having to boost the player's priority so that it would get no
> skipping. As you probably know 68060 machines, even if at the same mhz,
> have about 8x raw calculation power.

Eh, a 060 struggles with a mp3, it consumes most of the cpu and it can
still render a browser window (not as fast as it could originally, but
thats not my point).

> So, I also feel very bad about linux when my audio skips on my 900mhz
> machine and I see reports that it does the same on 2400mhz ones, but I
> can understand that the general design and target is not the same...
> Amiga was _designed_, both software and hardware wise, for realtime
> while Unix and thus Linux is designed for multiuser timesharing.

AmigaOS is lowlatency but not realtime. And, with executive you run a
unix scheduler (feedback).

> All that said, having a mp3 decoder as a kernel module reading from 
> mlocked ram would a great way to have Amiga-like music replaying ;)

Hummm, Last time i played a mp3 on my amiga i kinda decoded it in the
delfina dsp =)
(to bad noone has done that for emu10k1... )

> Geert, perhaps you could tell us how linux music playing feels
> for a desktop m68k machine? 
> 
> [ I'm CCing you since you are the only one from the m68k port    
>   which I can see posting on a regular basis.]
> 
> > And afair it has no real interactivity estimator. 
> > 
> > (If you are interested you can always search for Executive on aminet..
> > It has several scheduler policies including those that work great on
> > small machines (25mhz or so))

> If the user or a program decided so, it could _always_ change a task
> priority to upper or lower levels, which is what I did to my mp3 player
> to avoid skips on my under powered machine (mp3 playing used 85%cpu) ;).

Heh, what cpu?

But a task raising it's cpu on it's own can be a pain since it could
dominate the machine on non executive running machines.

> "Executive" was an application which patched the Amiga scheduler and
> hooked up a priority manager. By altering task' priorities, it managed
> to get the standard round-robin scheduler to behave like a feedback one.
> (Executive was _G_R_E_A_T_ :)))

Executive implements dynamic priorities in a fixed priority OS, ie nice.
You select the range it should use to catch processes and where it
should place em. And, Executive is still great even though i haven't
used it for quite some time.

> Executive was configured to never touch tasks with elevated priorities,
> so in fact all user tasks would get the feedback scheduler but system
> drivers such as keyboard input system would continue running as realtime
> round-robin.

Hummm, input.device would never consume so much cpu that it would need
to be penalized. 
 
> > imho, that shouldn't really be needed... =P
> > (although executive apparently had a pri boost for active window... I
> > doubt that i ran with it though... Been a while =))
> 
> Yes, it added +1 to the task which owner the active window
> (this is also used in Windows if I recall correctly). But even without
> this "hack", both executive-enabled and standard systems ran great.

Give priority to "front most" program is in Windows and OS/2. I disabled
it in OS/2 Warp something on a p120 and watched it crawl =P.

-- 
Ian Kumlien <pomac@xxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part