From: Ian Kumlien <pomac@vapor.com>
To: Antonio Vargas <wind@cocodriloo.com>
Cc: Robert Love <rml@tech9.net>,
linux-kernel@vger.kernel.org, geert@linux-m68k.org
Subject: Re: [SHED] Questions.
Date: Tue, 02 Sep 2003 00:49:32 +0200 [thread overview]
Message-ID: <1062456571.5171.231.camel@big.pomac.com> (raw)
In-Reply-To: <20030901142128.GB2359@wind.cocodriloo.com>
[-- Attachment #1: Type: text/plain, Size: 4857 bytes --]
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@vapor.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2003-09-01 22:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-31 10:07 [SHED] Questions Ian Kumlien
2003-08-31 10:17 ` Nick Piggin
2003-08-31 10:24 ` Ian Kumlien
2003-08-31 10:41 ` Nick Piggin
2003-08-31 10:46 ` Nick Piggin
[not found] ` <1062326980.9959.65.camel@big.pomac.com>
[not found] ` <3F51D4A4.4090501@cyberone.com.au>
2003-08-31 11:08 ` Ian Kumlien
2003-08-31 11:31 ` Nick Piggin
2003-08-31 11:43 ` Ian Kumlien
2003-08-31 18:53 ` Robert Love
2003-08-31 19:31 ` Ian Kumlien
2003-08-31 19:51 ` Robert Love
2003-08-31 22:41 ` Ian Kumlien
2003-08-31 23:41 ` Robert Love
2003-09-01 0:00 ` Ian Kumlien
2003-09-01 2:50 ` Con Kolivas
2003-09-01 15:58 ` Antonio Vargas
2003-09-01 22:19 ` Ian Kumlien
2003-09-01 4:03 ` Robert Love
2003-09-01 5:07 ` Con Kolivas
2003-09-01 5:55 ` Robert Love
2003-09-01 22:24 ` Ian Kumlien
2003-09-01 14:21 ` Antonio Vargas
2003-09-01 19:36 ` Geert Uytterhoeven
2003-09-01 22:49 ` Ian Kumlien [this message]
2003-09-01 15:07 ` Daniel Phillips
2003-09-01 14:16 ` Antonio Vargas
2003-09-01 23:03 ` Ian Kumlien
2003-09-02 0:04 ` Nick Piggin
2003-09-02 0:23 ` Con Kolivas
2003-09-02 10:25 ` Ian Kumlien
2003-09-02 11:08 ` Nick Piggin
2003-09-02 17:22 ` Ian Kumlien
2003-09-02 23:49 ` Nick Piggin
2003-09-03 23:02 ` Ian Kumlien
2003-09-04 1:39 ` Mike Fedyk
2003-09-02 10:44 ` Wes Janzen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1062456571.5171.231.camel@big.pomac.com \
--to=pomac@vapor.com \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rml@tech9.net \
--cc=wind@cocodriloo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).