HDTenEightyP/NetNews huggingface dataset:
From: steve@acorn.co.uk (Steve "daffy" Hunt)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 10 Nov 92 19:12:19 GMT
Organization: Acorn Computers Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

TMOTA (jwil1@cs.aukuni.ac.nz) wrote:
: If you drag a window, then ALL background activity stops while you are
: doing it, so the window-drag gets 100% CPU power. Try *that* on a preemptive
: system: it has to be well written before it will INSTANTLY adjust all
: priorities in that manner.

But whether it is a *good* thing or not is another matter.  The fact
that things can (and do) suspend scheduling for arbitrary amounts of
time precludes reliably running certain things as RISC OS tasks -
servers and such.  And in fact the things that do suspend scheduling
are seldom doing it to improve responsiveness.  For example, I cannot
see the merit in doing it while loading or saving a file - and yet
everything does, just because it's hard to do otherwise.

I think it is a very dubious thing to claim as a benefit.  Hogcpu(2)
would be an easy thing to add to UNIX.  The fact that this has not
happened suggests that on balance it isn't wanted.

-- Steve
-- 
				Steve Hunt	steve@acorn.co.uk
From: sproven@cs.strath.ac.uk (Simon B Proven IE91)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 9 Nov 92 12:21:53 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <1992Nov6.165448.10184@news2.cis.umn.edu> alla0008@student.tc.umn.edu writes:
>Out of interest, can anyone say how the Taskwindow module determines how
>much work it should do per cycle? In particular, when there's more than
>one Taskwindow task active, does each one reduce its timeslice to keep the
>co-operative cycle time about the same? Also, when a Taskwindow is idle
>(say, just sitting with a CLI prompt), it takes no CPU time - how does it
>know not to?

I suspect that TaskWindow intercepts calls to OS_ReadCh etc, so that when
the task is idle, waiting for input, the TaskWindow module knows that it
can afford to give up control.

One program I would like to have is a program which monitors the load of
all currently running processes, and thus can provide an easy way to
see which programs take lots of time, and when.  This would then allow
programmers to optimise their code for the GUI better.  Maybe I'll write
it myself one of these day....

>Graham						allan@mnhep8.hep.umn.edu
>						gta@st-andrews.ac.uk

mad@bike
-- 
* Simon Proven - 3rd Year student of Computer and Electronic Systems at the *
* University of Strathclyde, Glasgow, Scotland  G1 1XQ                      *
* Secretary, University of Strathclyde Green Group                          *
* sproven@cs.strath.ac.uk             REAL (tm) peeps ride bike :)          *
From: david@cosc.canterbury.ac.nz (cantua)
Subject: Re: The ARM Club
Reply-To: david@cosc.canterbury.ac.nz
Date: Tue, 10 Nov 1992 22:15:42 GMT

From article <2XR1UIj025n@khantazi.welly.gen.nz>, by banksie@khantazi.welly.gen.nz (Philip R. Banks):
> david@cosc.canterbury.ac.nz (cantua) writes:
> 
>> Well, unless I've misunderstood what you're trying to achieve, this is
>> pretty trivial on a preemptive system.  Simply have your task handling
>> window dragging running at a higher priority than everything else, then
>> when it wants the CPU it will get it (although using 100% CPU for
>> dragging a window is a bit of a waste of CPU IMHO).  No pissing around
>> or INSTANTLY adjusting priorities.
> 
>    Personally I don't call quick redraws a waste of CPU myself, but then
> perhaps I'm strange...

Quick redraws are great, but my point was that using 100% CPU while the
user was dragging a window, even if the operation didn't require 100%
CPU, is a waste - especially if some other task could have made use of
that CPU time.  I wouldn't like everthing else (background processes,
disk IO, etc) to stop just because I'm dragging a window.  My opinion...

>> Again this seems pretty trivial on a preemtive system, and I fail to see
>> where cooperative has the advantage.  The input handling task (presumably
>> an OS task) runs at a high priority, so any sort of input is handled
>> quickly.  Any other tasks can have priorities how they wish (or the user
>> wishes) in order to achieve the desired distribution of CPU time.
>> 
>> [Stuff about RiscOS removed]
>> 
>> Well, unless I've missed something I see no reason here why cooperative
>> is "better" the preemptive multitasking.
> 
>    You have missed something. Co-operative gives this dynamic re-priotising
> *without* the user having to understand about task priorites and isssuing
> the needed commands to effect the changes.

Yes, I see your point about dynamic re-priotising, but you may not always
want the "current" task to have the majority of the CPU.  Also, with
pre-emptive, if the task handling user input is a system one, which is by
default at a high priority, then the user need do nothing to priorities
to get good response.

> Also tasks need not be aware of
> the changing priority levels either precisely like pre-emptive systems.

Huh?  I'm sorry I don't see what you're saying here.

> This
> is where co-operative gains it's big win, it's responsiveness to the user is
> far better and simpler to effect.

I don't see how response in a co-operative system is far better.

Co-operative puts the onus on the application writers to get things
right (which is often too much to ask).  Pre-emptive leaves it up to
the OS to get it right, and is independent of the user applications.

[stuff about task windows removed]

						Dave

=========================================================================
== David Eaves, Computer Science Department, University of Canterbury, ==
=========== New Zealand.  EMail: david@cosc.canterbury.ac.nz ============
=========================================================================
From: steve@acorn.co.uk (Steve "daffy" Hunt)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 10 Nov 92 18:33:57 GMT
Organization: Acorn Computers Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

TMOTA (jwil1@cs.aukuni.ac.nz) wrote:
: steve@acorn.co.uk (Steve "daffy" Hunt) writes:
: 
: >absolutely no way to determine how much work it should do before
: >relinquishing control.  In general it is an impossible task to write
: >code for a background operation that maximises its own performance
: >without taking an unacceptable toll on system throughput.
: 
: Hmmm... I think that's a load of bollocks, but if I say that you'll get
: upset... ;-)
: 
: Firstly, there IS a way to determine "how much work...before relinquishing
: control". You give yourself a TIMESLICE. That is, your own program
: pre-empts ITSELF (or pretends to). A timeslice is also a good idea, as
: TIME is constant on all processors, while instructions-per-second isn't.

I said IN GENERAL.  Your specific example is easy, because the code
apparently sits in a loop which it goes though at a frequency greater
than the desired rescheduling frequency.

There is a large class of programs which cannot be written that way
(or at least, would be stupidly difficult to write that way).

Anyway, there's rather more to scheduling that simple timeslicing, as
pointed out by your next comment:-

: >Co-operative tasking can be very lightweight and this can give an
: >impression of great snappiness when other tasks are idle, but as soon
: >as there is background work things tend to deteriorate very quickly.
: 
: NO!
: You base this on what?
: The only applications that 'background' that I have used much are:
:   TaskWindow: Uses too large a timeslice, so makes desktop jerky. Should
: 	      have a user configuration option.
:   Filing/
:   Spark:      Timeslices well, but is I/O bound, which can often mean it
: 	      is unable to Wimp_Poll for a long period of time while data
: 	      is read/written from/to slow devices such as floppies.

Contrast this with UNIX where an I/O bound process has very little
effect on the performance of other processes, since it spends most of
its time blocked in the kernel.

Lots of operations are I/O bound.  There's no excuse for them slowing
the rest of the system down to a crawl.  A system that does not let
such things multitask smoothly cannot be right.

: I have yet to use any program (apart from DSEdit II) that multitasks
: 'properly' in the background. What I mean by this is:

And I have yet to use *any* UNIX program that cannot.  Draw your own
conclusions.

-- Steve
-- 
				Steve Hunt	steve@acorn.co.uk
From: jtn@ukc.ac.uk (J.T.Noble)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Summary: I think some people have lost the drift somewhat.
Date: 13 Nov 92 14:34:48 GMT
Reply-To: jtn@ukc.ac.uk (Jim Noble)
Organization: Computing Lab, University of Kent at Canterbury, UK.

banks_p@kosmos.wcc.govt.nz writes in article <2xKe-mj025n@khantazi.welly.gen.nz>
>david@cosc.canterbury.ac.nz (cantua) writes:
>> Quick redraws are great, but my point was that using 100% CPU while the
>> user was dragging a window, even if the operation didn't require 100%
>> CPU, is a waste - especially if some other task could have made use of
>> that CPU time.  I wouldn't like everthing else (background processes,
>> disk IO, etc) to stop just because I'm dragging a window.  My opinion...
>   Certainly other tasks get stopped. But because the window redraw code has
>100% CPU utilisation the hiatus (sp?) is as small as possible. Remember
>co-operative taskings aim is to respond to the user as fast as possible not
>to provide efficient backgrounding.

Yes exactly. What are 'background' tasks for? Surely you want a background 
task to make use of the CPU when it would otherwise be twiddling it's thumbs 
(or bits if you prefer :-)? Therefore if you decide at a particular moment 
to start doing something, you want the background tasks to be put on hold 
until you're finished. Ok, so maybe what you are doing is not so processor 
intensive, and you can afford to let the background tasks pinch a bit of 
processor time. Now, who do you think knows best how much processor time a 
task needs/takes? The programmer perhaps?

It would not be impossible to implement this with pre-emptive multi-tasking,
but it would be subject to user fiddling (and if you can't fiddle with it, 
what is it there for! :-). What proportion of user's will have both the 
knowledge and time to start altering the priority of each and every task?

(IMHO) I believe pre-emptive multitasking is better suited to running tasks of
equal importance. (Eg. a multi-user system.) ie. there are no background tasks 
as such, only many "foreground" ones. If a foreground task is not so important, 
then maybe the user should be able to reduce it's priority.

>> I don't see how response in a co-operative system is far better.
>   It is better because the task being used always gets 100% CPU power to do
>things. Thus redraws are faster, calculations are always done at maximum
>possible speed, disc accesses are always at maximum speed etc...

This is how I see co-operation. Getting the 'primary' task done asap.
You don't want 'secondary' tasks interferring.

>   The two have radically different aims and features. Please note I am not
>saying co-operative tasking is a better form of tasking than pre-emptive or
>vice-versa. Merely a different form of tasking with it's own inherent
>advantages and disadvantages. And one of those advantages is good
>responsiveness to the user. Is there anything else that need be said?

I agree. Both ways of doing it have their relative pros. and cons.

>    Philip


--
ttfn,
	Jim.
Newsgroups: comp.sys.acorn.advocacy
From: rsxdp@unicorn.nott.ac.uk (D.Pead)
Subject: Re: Replay vs. Quicktime
Organization: Shell Centre for Maths Education University of Nottingham
Date: Wed, 11 Nov 92 10:53:55 GMT

In article <1992Nov9.090156.6913@fwi.uva.nl> aroest@fwi.uva.nl (Axello de Roestello) writes:
>rsxdp@unicorn.nott.ac.uk (D.Pead) writes:
>
>>Well, I've just seen a demonstration of QuickTime 
>>and it really is an excellent product, with just two minor  problems:
>
>>1: It can't display full-motion video, and
>>2: It can't display full-motion video.
>
>I think you make a slight mistake here: Quicktime is a SoftWare product. It
>is fully capable of displaying full-motion video at whatever size you want it.
>*At the moment* the HardWare is the problem. 

Well, I'm sure Replay would be absolutely fabulous on an ARM800 with VIDC20.
But it *WORKS* on an A5000 with a CD-ROM drive.

>full-screen video real-soon-now. The SuperMac "Digital Film" board will set
>you back $6000, but you will be able to grab full-screen video at 30 frames/sec
>to hard disc. Don't yell at the price. Its purpose in life is to provide a
>low-cost alternative to video editing equipment of $100,000 and more. RasterOps
>has a similar board in the pipeline. Check out the videoboards special in
>the MacWorld of October '92.

Great, I'm sure we'll soon have one in every school :-)
I thought that I'd made it quite clear that Quicktime was good for
video editing.  The problem is it can't display motion video at more
than about 5-6 frames per second without the sort of pricey hardware you
mention.
>
>Oh yes: These boards work perfectly without a Quadra. 

They also cost more than a Quadra!
>
>
From: steve@acorn.co.uk (Steve "daffy" Hunt)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 6 Nov 92 14:31:41 GMT
Organization: Acorn Computers Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Pete Goodwin (goodwin@edieng.enet.dec.com) wrote:

: What I mean by 'fast' isn't 'faster' than the Amiga, I mean 'faster' than
: pre-emptive. Since each task is responding to events, the response time is at
: its maximum since only one task is responding to one event. It falls down where

Response time in a co-operative system is completely at the mercy of
all the other programs running.  Each "co-operating" task has
absolutely no way to determine how much work it should do before
relinquishing control.  In general it is an impossible task to write
code for a background operation that maximises its own performance
without taking an unacceptable toll on system throughput.

A well-designed pre-emptive system gives you this for free.

Co-operative tasking can be very lightweight and this can give an
impression of great snappiness when other tasks are idle, but as soon
as there is background work things tend to deteriorate very quickly.
-- 
				Steve Hunt	steve@acorn.co.uk
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
From: banksie@khantazi.welly.gen.nz (Philip R. Banks)
Date: Thu, 12 Nov 1992 12:47:31 +1300
Reply-To: banks_p@kosmos.wcc.govt.nz
 <1992Nov9.001953.23918@cs.aukuni.ac.nz> <1992Nov9.163934.18398@news2.cis.umn.edu>
Organization: My Arc.

alla0008@student.tc.umn.edu (Graham Allan) writes:

> This works fine if only one process is doing work in background, but if
> two or more tasks are doing this, each one still takes its timeslice and
> the desktop response gets very slow. The only way to keep the desktop
> response good would be to try and keep the time of the complete polling
> loop below some critical value - and I don't see how any individual task
> can manage this, without knowledge of other tasks' timeslices. It has to
> be centrally co-ordinated by the OS (or something with overall knowledge
> of the system load).

   Bzzt! Wrong! Remember Null events are 'round robin'-ed between the tasks
that want them. So as long as each task occupies only a 15 cs timeslice then
the response time of the Wimp will *always* be 15cs or less regardless of
how many tasks are active.

> As for the 'too-long' timeslice of TaskWindows, I agree in principle, but
> probably they perform a lot of saving/restoring of state on task switches,
> which would become an unacceptable overhead with shorter slices.

   I suspect this is the case. However it would be nice if the timeslicing
with TaskWindows only occured on Null events. The backgrounding would be
much smoother.

    Philip

--
Philip R. Banks  Syntax: mail < banks_p@kosmos.wcc.govt.nz >            @@@@@/|
                                                                        @@@@/#|
                                                                        @@@/##|
Radiation emissions from Quirium are perilously high, therefore repairs @@/---|
should not be attempted by pilots with vertigo. ---Arc Elite Manual     @/    |
From: pete@eoe.co.uk (Pete Cockerell)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: 13 Nov 92 09:35:44 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

Philip R. Banks (banksie@khantazi.welly.gen.nz) wrote:
: [Stuff deleted]
: 
:    Pre-emptive also suffers from often saving and restoring alot of unneeded
: context.
:
Sorry, I can't agree that this is a pre-emptive/co-operative distinction at all.
You can design a pre-emptive OS where the context switch code is about three
instructions (eg change the virtual table pointer, load the context's registers
and return to that process). I was always under the impression that RISC OS had
to do rather more than that because it has to explicitly save and restore lots
of global state on a context switch that on systems written to be multi-tasking
from scratch would be local to the task's state anyway. But as I say, I don't think
this is an issue of how the multi-tasking aspect is implemented, more a combination
of machine and OS architecture.

: 
: --
: Philip R. Banks  Syntax: mail < banks_p@kosmos.wcc.govt.nz >            @@@@@/|

Pete
Newsgroups: comp.sys.acorn.advocacy
From: david@cosc.canterbury.ac.nz (cantua)
Subject: Re: The ARM Club
Reply-To: david@cosc.canterbury.ac.nz
Date: Mon, 9 Nov 1992 22:58:36 GMT

From article <1992Nov9.003709.24125@cs.aukuni.ac.nz>, by jwil1@cs.aukuni.ac.nz (TMOTA):

[Stuff deleted]

> 15cs timeslices gives approximately 6 polls per second, i.e. if you press
> a key or click the mouse, the respons should be started (i.e. insert character
> or start popping up a menu) within 1/6th of a second - fast enough for the user
> to not notice the background load often.
> 
> If you drag a window, then ALL background activity stops while you are
> doing it, so the window-drag gets 100% CPU power. Try *that* on a preemptive
> system: it has to be well written before it will INSTANTLY adjust all
> priorities in that manner.

Well, unless I've misunderstood what you're trying to achieve, this is
pretty trivial on a preemptive system.  Simply have your task handling
window dragging running at a higher priority than everything else, then
when it wants the CPU it will get it (although using 100% CPU for
dragging a window is a bit of a waste of CPU IMHO).  No pissing around
or INSTANTLY adjusting priorities.

> This is the great advantage of cooperative: So long as everything does
> cooperate (not yet the case under RISC OS) properly, the CPU time is shared
> out very effectively: When little user activity is going on, all tasks have
> an equal right to CPU time, and the backgrounded tasks can power along using
> 99% of the CPU time available. When the user clicks, control is instantly
> moved to the code which processes that click, and all background activity
> slows down or is suspended until the foreground task needs less CPU time.

Again this seems pretty trivial on a preemtive system, and I fail to see
where cooperative has the advantage.  The input handling task (presumably
an OS task) runs at a high priority, so any sort of input is handled
quickly.  Any other tasks can have priorities how they wish (or the user
wishes) in order to achieve the desired distribution of CPU time.

[Stuff about RiscOS removed]

Well, unless I've missed something I see no reason here why cooperative
is "better" the preemptive multitasking.

						Dave

=========================================================================
== David Eaves, Computer Science Department, University of Canterbury, ==
=========== New Zealand.  EMail: david@cosc.canterbury.ac.nz ============
=========================================================================
Newsgroups: comp.sys.acorn.advocacy
From: alla0008@student.tc.umn.edu (Graham Allan)
Subject: Re: The ARM Club
Organization: University of Minnesota
Date: Mon, 9 Nov 1992 16:46:34 GMT

In article <10896@baird.cs.strath.ac.uk> sproven@cs.strath.ac.uk (Simon B Proven IE91) writes:
>
>One program I would like to have is a program which monitors the load of
>all currently running processes, and thus can provide an easy way to
>see which programs take lots of time, and when.  This would then allow
>programmers to optimise their code for the GUI better.  Maybe I'll write
>it myself one of these day....
>

Didn't someone (Ran Mokady?) at Acorn write this - a CPU usage utility for
RISC OS 3.00? I pulled a copy over from the newcastle info-server, but
haven't seen it run yet - I had RISC OS 2 at the time (now I have RISC OS
3.1 sitting in a box beside the computer, but several thousand miles away
:-( ). Don't know if the thing still works on OS 3.1.

Graham						allan@mnhep8.hep.umn.edu
						gta@st-andrews.ac.uk
From: banksie@khantazi.welly.gen.nz (Philip R. Banks)
Newsgroups: comp.sys.acorn.advocacy
Subject: Re: The ARM Club
Date: Wed, 11 Nov 1992 00:08:09 +1300
Reply-To: banks_p@kosmos.wcc.govt.nz
Organization: My Arc.

david@cosc.canterbury.ac.nz (cantua) writes:

> Well, unless I've misunderstood what you're trying to achieve, this is
> pretty trivial on a preemptive system.  Simply have your task handling
> window dragging running at a higher priority than everything else, then
> when it wants the CPU it will get it (although using 100% CPU for
> dragging a window is a bit of a waste of CPU IMHO).  No pissing around
> or INSTANTLY adjusting priorities.

   Personally I don't call quick redraws a waste of CPU myself, but then
perhaps I'm strange...

> Again this seems pretty trivial on a preemtive system, and I fail to see
> where cooperative has the advantage.  The input handling task (presumably
> an OS task) runs at a high priority, so any sort of input is handled
> quickly.  Any other tasks can have priorities how they wish (or the user
> wishes) in order to achieve the desired distribution of CPU time.
> 
> [Stuff about RiscOS removed]
> 
> Well, unless I've missed something I see no reason here why cooperative
> is "better" the preemptive multitasking.

   You have missed something. Co-operative gives this dynamic re-priotising
*without* the user having to understand about task priorites and isssuing
the needed commands to effect the changes. Also tasks need not be aware of
the changing priority levels either precisely like pre-emptive systems. This
is where co-operative gains it's big win, it's responsiveness to the user is
far better and simpler to effect.

    Philip

PS As an addendum to the TaskWindow thread of this arguement the reason
TaskWindow's hogg the system is because they do a timeslice *every*
Wimp_Poll instead of on Null Polls. The net effect is that they interfere
between message/poll result passing and slow the Wimp down. (That and Edit's
slowness of course...)

--
Philip R. Banks  Syntax: mail < banks_p@kosmos.wcc.govt.nz >            @@@@@/|
                                                                        @@@@/#|
                                                                        @@@/##|
There may be an om in moment, but there are very few folk in focus!     @@/---|
   ---Emmerson, Lake and Palmer.                                        @/    |