AmigaOS sucks?
Anders Lindgren
that the AmigaOS sucks on many points: Too unstable, Too insecure
(no sourcetracking/process-control), dumb multitasking (doesn't
take low-cost tasks first to speed up user-interaction and so on),
bad for multi-user purposes... Anyone have any ->facts on this one?
Experienced OS-folk's opinions also welcome!
-ali-
Christian Stieber
> A guy 'round here who knows pretty much about hardware said today
> that the AmigaOS sucks on many points:
He's right. But...
> Too unstable,
Quite untrue. It is rather stable now, IMHO. Remember: it was not designed
to be another Unix. MS-Windows, which has sa similar audience, is said to
be more unstable.
The main problem are unstable programs, since the AmigaOS doesn't have
memory protection. And it is not simple to add it now.
> Too insecure (no sourcetracking/process-control),
That's a problem. But irl it doesn't rally matter that much, since a
program simply does its own resource tracking. It just means you can't
kill a program (which isn't necessary if the program is stable).
And it means that resources are lost if the program is buggy.
> dumb multitasking (doesn't take low-cost tasks first to speed up
> user-interaction and so on),
call it "simple multitasking". The scheduler is pretty simple compared
to the more sophisticated algorithms used in other OSes. But for the
main target audience it works well. And software can be written to
take this account (e.g. a editor could run at priority 1, turning
it down to 0 for lengthy operations such as searching).
> bad for multi-user purposes...
Of course. But that's not a problem. AmigaOS was *never* designed to be
multi-user. MS-Windows is bad for multiuser purposes, too.
Why didn't your friend address the real problems? There are quite a few
design problems... Forbid(), Hardware access, dos, RTG to name some of the
more obvious ones :)
Christian
--
// Christian Stieber Sti...@Informatik.TU-Muenchen.de
\// Certified Amiga Developer PGP public key available
--------------------------------------------------------------------------
"Life starts at '030, fun starts at '040, impotence starts at '86"
keyboard not connected -- press F1 to continue
Marco Nelissen
: A guy 'round here who knows pretty much about hardware said today
: that the AmigaOS sucks on many points: Too unstable, Too insecure
That proves it: never ask a hardware guy to comment on software.
TOO unstable, TOO insecure. Seems pretty subjective to me. Too
unstable and insecure for WHAT?
: (no sourcetracking/process-control), dumb multitasking (doesn't
: take low-cost tasks first to speed up user-interaction and so on),
Oh, golly, everything that a PC has... NOT! What is he comparing the
Amiga with anyway. Does he expect to get the same level of reliability
and security out of a homecomputer as from an expensive unix-box?
: bad for multi-user purposes... Anyone have any ->facts on this one?
AmigaOS was never meant to be multiuser. That doesn't mean that it can't
do it, though. Saying that AmigaOS sucks because of the above reasons
is like saying that it sucks because it doesn't run Windows. It all depends
on what you need to do with it...
Marco
Stefan Burstroem
OS for home computers. You need UNIX if you want *real* resourcetracking
etc. Lets see:
Too unstable: Not my computer anyway. (OS 3.0) The AmigaOS *was* unstable, but
is not today.
Dumb multitasking: Beats both MacOS and Windoze
To insecure: Well, maybe...
Bad for multi-user purpose: Well, with muFS AmiTCP etc I don't find a reason
to say that you cannot have multi-users on an Amiga.
/Stefan
Michael van Elst
>A guy 'round here who knows pretty much about hardware said today
>that the AmigaOS sucks on many points: Too unstable, Too insecure
>(no sourcetracking/process-control), dumb multitasking (doesn't
>take low-cost tasks first to speed up user-interaction and so on),
>bad for multi-user purposes... Anyone have any ->facts on this one?
AmigaOS is stable: it doesn't crash itself, it survives memory shortages
and situations where the CPU is starved by user processes. It has very
few limits to resources (most things can be allocated until memory is
exhausted).
Of course it is unstable too. Without memory protection a bug can easily
destroy the whole system. But a fresh new OS/2 system _with_ memory
protection crashed more often by just following the install procedures
than my A3000 in a month.
I'm not sure what resource tracking has to do with security. AmigaOS
is insecure, but so are all systems that allow direct hardware access.
AmigaOS has no resource tracking. So programs cannot be aborted easily.
On the other side you do not have to clean up after you stopped a
program as a program tracks its own resources.
AmigaOS multitasking is _simple_. It cannot speed up user interaction
because user interaction is always at a high priority, the most
important job.
Smart scheduling is mainly for machines with many users or background
jobs. It is not that important for personal computers and the Amiga _is_
a personal computer.
Smart scheduling is also slow, to get reasonably low overhead you need
either large time slices or very fast machines.
Regards,
--
Michael van Elst
Internet: mle...@mpifr-bonn.mpg.de mle...@serpens.rhein.de
"A potential Snark may lurk in every tree."
Pete Goodeve
> A guy 'round here who knows pretty much about hardware said today
> that the AmigaOS sucks on many points:
It looks like this statement has been fairly well rebutted by a
number of people already, but I might as well add my voice and
point of view...
> Too unstable,
I'd definitely object to this one -- in either sense of 'unstable'.
As far as run-time stability goes, I have an old 1000 running OS 1.3
which is on 24 hours a day; I have to reboot because of a crash maybe
once every three months or so -- normally after I've tried to run a
buggy program. (Apps with bugs will crash the system, yes, but have
you run MSWindows lately? (:-)) My '030 (2.04) development machine doesn't
remain on like that, but is no less stable; the usual cause of a (still
rare) crash there is my own coding error.
The other form of 'stability' I'm thinking of is across versions of the OS.
Most programs written for 1.0 [that obeyed the rules!] will still happily
run on the latest system (a notable exception being the Boing! demo).
That's not true of MSWindoze in my experience, nor of many other OSs
I suspect.
> Too insecure (no sourcetracking/process-control),
It is definitely 'insecure' as compared to systems with memory protection
and so on, but the "Too" is very subjective! A bit like saying a
Ferrari is "too" unsafe -- depends what your needs, desires, and
intentions are, dun'nit? There are tradeoffs (see below).
> dumb multitasking (doesn't > take low-cost tasks first to speed up
> user-interaction and so on),
The task-switching algorithm is fairly simple, priority-based -- and
*fast*! It is probably more efficient for most uses than a more
complex scheme In my experience, user interaction on the Amiga has less
delay than any other system I've worked with. I get the feeling this
guy has never actually *used* an Amiga -- just has theoretical
preconceptions...
> bad for multi-user purposes... Anyone have any ->facts on this one?
It is not *intended* for multi-user! If you want multi-user, you also get
baggage: memory swapping, security layers, and so on. For a *personal*
OS these are a heavy -- and unnecessary -- penalty.
Obviously this guy doesn't realize that different OSs serve different
needs. If you want to serve 100 users, use Unix, or [urghhh] Windows NT
-- something with firewalls and heavy memory management. And as fast
a processor and as much memory as you can afford... If you want a
powerful *personal* system that handles a lot of things at once fast,
use an Amiga.
I'm beginning to use OS/2 at the lab quite a lot at the moment. In general
I find it a very good system. Two deficiencies though compared to AmigaOS:
things seem to need 12 MB to run [my bigger Amiga is 6MB, and I haven't
come near to running it out of space yet!]; and that user-interaction
stuff is SLOW! [Admittedly it is a 486, not a Pentium...(:-/)]: windows,
even within an application, can take several seconds to open. This
afternoon I ran one too many programs at once, and ran out of swap space...
the system didn't crash [definitely stable! (:-)] but after I killed the
extra program it took just about *ten* minutes to recover itself! It
thrashed around madly -- popping open windows and closing them again,
and presumably swapping everything in and back out again until it was
completely satisfied.
On the other hand, on my '030 Amiga, I have a system that processes MIDI in
real time. Typically I have 50 or 60 processes (i.e. separate programs)
active in memory, of which 15 or so are heavily active passing MIDI events
around. The only time I get a momentary hiccup is when I try to rearrange
windows at the same time (Intuition's priority is higher); otherwise I have
*no* problems. I don't think any other platform could come *close* to
doing this.
-- Pete --
Per Espen Hagen
> that the AmigaOS sucks on many points:
I don't know any OS that doesn't "suck on many points". And I've used at
least a dozen different ones -- AmigaOS, various Unixes, VMS, Oberon,
MS-DOS, OS/2, MacOS, CP/M, PRIMOS, SINTRAN, and so on. Every OS has its
flaws.
>Too unstable,
This was true about AmigaOS 1.x. OS 3.1 is very very stable. I don't
think I've ever had an OS instability crash or freeze OS 3.x. Its
stability is comparable to that of Unix or VMS.
The OS is stable, but *programs* can be unstable. A badly written program
can crash the Amiga easily -- in fact, you can write a two-line C program
that will crash the Amiga instantly when run. But that doesn't mean that
the OS is unstable.
The fact that bad programs can crash the Amiga is mainly due to the fact
that the OS doesn't have memory protection. One can argue that this is
actually a good thing -- it means that developers have to use more time to
debug their programs before releasing them, or use safer programming
languages like Modula-2 or Oberon instead of C/C++. Safer software is
better software. But that's a pretty weak argument, of course. Because it
also scares many developers away from the platform, and because large
programs almost never are bug-free anyway.
> Too insecure
> (no sourcetracking/process-control),
This can be a real problem. The lack of resource tracking means that a
failing program won't return its resources (memory, audio channels, etc).
But again, programs aren't supposed to fail in the first place... This is
mainly a problem for programmers and beta testers, and users who like to
run all sorts of unsafe patches and utilities. Knowledgeable users are
wary about new programs and patches, and rarely see finished software
failing.
> dumb multitasking (doesn't
> take low-cost tasks first to speed up user-interaction and so on),
The Amiga's multitasking is *simpler* than many other OS's. There is a
big advantage to the Amiga's priority-only based multitasking: It gives
the OS very good real-time capabilities. It's much easier to ensure that
task X gets the CPU when it wants it, not half a second later. Very
important for things like multimedia. The task switching overhead is also
extremely low.
In this respect, the Amiga is lightyears ahead of Windows and MacOS, and it
also beats many Unix dialects when it comes to real-time capability.
But again, a major problem with the Amiga task scheduling scheme is that
bad programs can hang the OS. If a high-priority task gets stuck in an
endless loop or some lock-up, lower priority tasks don't get any time at
all. So you can't even break or lower the priority of the offending task.
Once again, bad programs can cause bad things to happen.
> bad for multi-user purposes...
AmigaOS was never intended to be a multiuser operating system. Still, its
flexibility (plug-in filesystems, SetFunction, etc) means that a usable
multi-user system can be implemented by a 3rd party... actually, it has
been implemented, with MultiUser. Far from perfect for multiple
*simultaneous* users, although it does work -- I've been running MultiUser
on multiple Amigas, with remote logins through AmiTCP and telnetd. With a
well thought-out setup, it works quite well.
--
Per Espen Hagen per-esp...@ffi.no Tel: +47 63807653 //
Senior Scientist Image Processing Group NDRE, Norway \X/
Any resemblance between the above views and the views of my employer,
myself, or the view out of my window, is non-deterministic.
Fredrik Solenberg - HFB T d93
> > that the AmigaOS sucks on many points:
>
> He's right. But...
>
> > Too unstable,
Yes, he's right but there are many other OSes that are even more unstable.
Just look at anything MS have ever done.
> The main problem are unstable programs, since the AmigaOS doesn't have
> memory protection. And it is not simple to add it now.
That's their biggest mistake! I definitely agree.
> > dumb multitasking (doesn't take low-cost tasks first to speed up
> > user-interaction and so on),
>
> call it "simple multitasking". The scheduler is pretty simple compared
> to the more sophisticated algorithms used in other OSes. But for the
> main target audience it works well. And software can be written to
> take this account (e.g. a editor could run at priority 1, turning
> it down to 0 for lengthy operations such as searching).
I don't know that much about the history of scheduling algorithms, but
remember that AmigaOS was written some 12 years ago. It has had REAL
multitasking ever since (even if it's simple). It still works, with less
hardware requirements than any PC operating system with multitasking.
I run an A600 with KS 2.04 and 2 MB RAM. Of course it's slow, and I have
only 1260 kB RAM left after boot, with screenblanker and a couple of
nice commodities in the background. OS/2 takes 4MB to start (and then
it's not even possible to use it). Windows-NT takes 16MB or something.
I wonder what that "new" technology was?
And is there any sucessful implementation of the SJF algorithm in a
preemptive system yet?
> Of course. But that's not a problem. AmigaOS was *never* designed to be
> multi-user. MS-Windows is bad for multiuser purposes, too.
Absolutely.
> Why didn't your friend address the real problems? There are quite a few
> design problems... Forbid(), Hardware access, dos, RTG to name some of the
> more obvious ones :)
Using a PCB that memorizes all resources used by a process wouldn't hurt
either, would it?
CloseDevice();
/ Fredrik Solenberg
---
* All my typos or misspellings are Copyright (C) Fredrik Solenberg 1995.
* Unathourized duplication in any media what-so-ever is violation of
* applicable laws and thus subject to criminal prosecution.
* In other words: BE SURE TO SPELL IT RIGHT!
Anders Lindgren
-> > > A guy 'round here who knows pretty much about hardware said today
-> > > that the AmigaOS sucks on many points:
-> >
-> > He's right. But...
-> >
-> > > Too unstable,
->
-> Yes, he's right but there are many other OSes that are even more unstable.
-> Just look at anything MS have ever done.
You know I've heard 'MS' really isn't an abbreviation for 'MicroSoft' but
actually means simply 'Major Suck-up'... :-)
-> > The main problem are unstable programs, since the AmigaOS doesn't have
-> > memory protection. And it is not simple to add it now.
->
-> That's their biggest mistake! I definitely agree.
Yep. When multitasking memory-protection should be overall standard! At the
time we discussed AmigaOS we were comparing it and its multitasking-ability to
unix workstations since AmigaOS is said to have picked much of the goodies from
there... I don't know about OS3.1 though... Any improvements on these points?
-> > > dumb multitasking (doesn't take low-cost tasks first to speed up
-> > > user-interaction and so on),
-> >
-> > call it "simple multitasking". The scheduler is pretty simple compared
-> > to the more sophisticated algorithms used in other OSes. But for the
-> > main target audience it works well. And software can be written to
But I want memory-protection so I can work without having to worry about
the whole system going down the drain when a buggy task decides to crash...
Is there a commodity to do this? The A4000 sells a lot on the professional
video-market, and they're likely to be fuzzy about the reliability and smooth-
ness not so important to the 'main target audience'... Besides, I'm saving
for an A4000/030 for semi-professional use, and I too have become fuzzy after
having run like 10 tasks simultaneously without problems on these SUN3 Sparcs.
I guess OS3.1 is much more stable than my A500/1.3 :-) But how good is the
multitasking?
-> > take this account (e.g. a editor could run at priority 1, turning
-> > it down to 0 for lengthy operations such as searching).
Problem is software developers usually don't... IMHO it is not something
developers should have to bother themselves with.
-> I don't know that much about the history of scheduling algorithms, but
-> remember that AmigaOS was written some 12 years ago. It has had REAL
-> multitasking ever since (even if it's simple). It still works, with less
Real multitasking would require parallell processors, no? :-)
But I agree that AmigaOS is really great, especially when taking its age
in account. Although I know almost nothing about the OS's functions on
lower level, I do love the appearance of OS3.1 and except the unstability
of OS1.3, I've never had any problems with it... My 1.3 has always worked
smooth and fine on my 1Mb machine (I'd like to see a PC,Mac or whatever do
that!), although lack of memory becomes a constant pain in the a**!
-> hardware requirements than any PC operating system with multitasking.
-> I run an A600 with KS 2.04 and 2 MB RAM. Of course it's slow, and I have
-> only 1260 kB RAM left after boot, with screenblanker and a couple of
-> nice commodities in the background. OS/2 takes 4MB to start (and then
-> it's not even possible to use it). Windows-NT takes 16MB or something.
-> I wonder what that "new" technology was?
Yeah, really. Although Windows is not an operating-system it still sucks...
I'll take OS3.1 before Windows, MacOS or whatever (except perhaps unix) or
anything... But there are some annoying flaws. I heard resourcetracking was
supposed to be in it but they cancelled it to save speed n' stuff. Arrgh.
-ali-
Michael van Elst
>But I want memory-protection so I can work without having to worry about
>the whole system going down the drain when a buggy task decides to crash...
You mean like OS/2 that crashed 3 times during installation ?
>Real multitasking would require parallell processors, no? :-)
No :)
>anything... But there are some annoying flaws. I heard resourcetracking was
>supposed to be in it but they cancelled it to save speed n' stuff.
Resource tracking might have been in in the first design that was never
completed. But I don't consider resource tracking to be important.
Kevin Paul Kubish
>A guy 'round here who knows pretty much about hardware said today
>take low-cost tasks first to speed up user-interaction and so on),
>bad for multi-user purposes... Anyone have any ->facts on this one?
It sounds as if he knows nothing about it.
And what is he comparing it to? None of the other OS's do all of that.
With Good multitasking there is no "first", the CPU time should be spread out equally so that the user doesn't notice a slowdown in any of the programs running.
Kk..
My feelings
--
Kevin Kubish Ai...@detroit.freenet.org
Carl Laurence Gonsalves
Anders Lindgren <dat9...@ludat.lth.se> wrote:
>A guy 'round here who knows pretty much about hardware said today
>that the AmigaOS sucks on many points: Too unstable, Too insecure
>(no sourcetracking/process-control), dumb multitasking (doesn't
>take low-cost tasks first to speed up user-interaction and so on),
The Amiga's scheduling makes a heck of a lot more sense that some other
systems I've seen. Windows-NT tries to give more priority to whichever task
has the user's focus. This is *really* annoying sometimes.
Once I had two command prompts open and I started a build in one. I could
see it compiling each file, taking about 2 or three seconds per C file
(this was a fairly fast machine, and the C files were pretty small).
I then moved the pointer over to the other window, because I wanted to find
a file. The instant the other window became the active one (even though I
wasn't typing anything else), the compile slowed down to a virtual stop in
comparison. I couldn't believe it. Clicking between the two windows would
drastically alter the speed of the compile, even though the other window
just had a command prompt that wasn't doing anything.
>bad for multi-user purposes... Anyone have any ->facts on this one?
>Experienced OS-folk's opinions also welcome!
Well, it never was meant to be a multi-user OS. It was designed for a
single user, and that's what it's generally used for. Hmm, makes sense...
--
Carl Laurence Gonsalves - clgo...@undergrad.math.uwaterloo.ca
http://www.undergrad.math.uwaterloo.ca/u/clgonsal/
Computer Science, University of Waterloo
Dennis Lee Bieber
Unstable? I've had WfW die while trying to INSTALL a comm program --
repeatedly! And that was on a 486 running in "enhanced mode".
Insecure? It's supposed to be a "personal" computer! Not some
central server in a corporate environment.
"Dumb multitasking": While it doesn't dynamically adjust task
priorities, it does permit tasks to change their own priorities; using a
multi-priority round-robin PREEMPTIVE scheduling algorithm. Windows, in the
three weeks I've been looking at it appears to only have TWO priority levels,
foreground and background -- and plays some tricks within those priorities to
allow for some tasks to get more or less time in the scheduler...
Multi-user? see "Insecure"
It would be nice if it supported memory protection, but that would
also mean that it would not be able to run on machines without an MMU -- ie,
no 68000, 68010, 68020 machines...
--
> ================================================================== <
> This | Wulfraed Dennis Lee Bieber KD6MOG <
> Space |------------------------------------ <
> Under | wulf...@netcom.com <
> Construction | D.Bi...@GEnie.GEIS.com <
> ================================================================== <
> PGP key: Finger wulf...@netcom.com <
Jonas Elfström
> In article <3k6sp3$k...@nic.lth.se>,
> Anders Lindgren <dat9...@ludat.lth.se> wrote:
> >A guy 'round here who knows pretty much about hardware said today
> >that the AmigaOS sucks on many points: Too unstable, Too insecure
> >(no sourcetracking/process-control), dumb multitasking (doesn't
> >take low-cost tasks first to speed up user-interaction and so on),
>
> The Amiga's scheduling makes a heck of a lot more sense that some other
> systems I've seen. Windows-NT tries to give more priority to whichever task
> has the user's focus. This is *really* annoying sometimes.
>
> Once I had two command prompts open and I started a build in one. I could
> see it compiling each file, taking about 2 or three seconds per C file
> (this was a fairly fast machine, and the C files were pretty small).
>
> I then moved the pointer over to the other window, because I wanted to find
> a file. The instant the other window became the active one (even though I
> wasn't typing anything else), the compile slowed down to a virtual stop in
> comparison. I couldn't believe it. Clicking between the two windows would
> drastically alter the speed of the compile, even though the other window
> just had a command prompt that wasn't doing anything.
LView from me. I installed it and started to view a jpeg picture. He had a
Pentium90 just like me and to show the picture took much longer! I noticed he ran
NT and, asked him why it was slower.
-"Oh I have a DOS program running in the background"
I thought that DOSprogram was doing something. It wasn't, it was just waiting for a
keystroke...
----8<----
> --
> Carl Laurence Gonsalves - clgo...@undergrad.math.uwaterloo.ca
> http://www.undergrad.math.uwaterloo.ca/u/clgonsal/
> Computer Science, University of Waterloo
>
>
--
Jonas Elfstroem !The more you suffer !ECS...@klecs1.ericsson.se
ERICSSON MOBILE !The more it shows you! ->voice: +46 19 584455<-
COMMUNICATIONS !really care Right?! /*amigafreak, R.E.M. */
This is my point of view not Ericsson's /*Offspring, SOM, DM */
Lars Duening
>In article <1995Mar16....@t.hfb.se>, d93...@t.hfb.se (Fredrik Solenberg - HFB T d93) writes:
>-> > take this account (e.g. a editor could run at priority 1, turning
>-> > it down to 0 for lengthy operations such as searching).
>
>Problem is software developers usually don't... IMHO it is not something
>developers should have to bother themselves with.
This is almost an religious issue, but: who else but the developers
should (and _can_) bother with the priority their program runs on?
After all they are the ones who know exactly how much resources their
program will need for how long time.
--
Lars Duening; due...@ibr.cs.tu-bs.de
Michael van Elst
>-"Oh I have a DOS program running in the background"
>I thought that DOSprogram was doing something. It wasn't, it was just waiting for a
>keystroke...
That's what DOS programs usually do, and they work like a horse not to
miss any stroke.
Iljitsch van Beijnum
: >-> > take this account (e.g. a editor could run at priority 1, turning
: >-> > it down to 0 for lengthy operations such as searching).
: >Problem is software developers usually don't... IMHO it is not something
: >developers should have to bother themselves with.
: This is almost an religious issue, but: who else but the developers
: should (and _can_) bother with the priority their program runs on?
: After all they are the ones who know exactly how much resources their
: program will need for how long time.
I beg to differ.
The developer must always give the user control. TOTAL control on single
user machines. So there should be a way for the user to adjust the
priority the programs runs at. Of course a sensible default should be
provided.
To the original poster: there is a program that ups the priority of the
program that's active so in essence you get exactly what you asked for:
your editor runs fast when you type but doesn't hog the CPU when you're
doing something else when it's doing something lengthy.
--
// Iljitsch van Beijnum, Defender of Lost Causes. Or are they?
\X/ ilji...@xs4all.nl - http://www.xs4all.nl/~iljitsch/
Christian Stieber
> multitasking ever since (even if it's simple). It still works, with less
> hardware requirements than any PC operating system with multitasking.
> I run an A600 with KS 2.04 and 2 MB RAM. Of course it's slow, and I have
> only 1260 kB RAM left after boot, with screenblanker and a couple of
> nice commodities in the background. OS/2 takes 4MB to start (and then
> it's not even possible to use it). Windows-NT takes 16MB or something.
> I wonder what that "new" technology was?
Just for the record: do not forget that other OSes tend to have features
that AmigaOS doesn't have. And remember: *every* feature needs memory.
I'm not trying to defend memory-hungry PC OSes since I can't tell whether
they need it due to bad programming or due to great features. But it
could be the features :)
Osma Ahvenlampi
>Smart scheduling is mainly for machines with many users or background
>jobs. It is not that important for personal computers and the Amiga _is_
>a personal computer.
>Smart scheduling is also slow, to get reasonably low overhead you need
>either large time slices or very fast machines.
Hmm. I use a program that, among other things, has a priority manager
that adjusts task priorities between -3..+3 according to their use of
the given CPU quantums, and I have to say that while it does create
somewhat of an overhead (unnoticeable to me, though), I greatly prefer
it over the normal static priorities..
(sorry, that program is beta, so I can't give it to anyone)
--
<A HREF="http://www.hut.fi/~oahvenla/">My home page</A>
Anders Lindgren
[snip my article 'bout AmigaOS]
-> And what is he comparing it to? None of the other OS's do all of that.
AFAIC, Unix does a pretty good job@that...
Well, at the time we were talking about what we wanted an operatingsystem to be like,
and the discussion turned into a comparison between Unix on workstations and AmigaOS.
Of course AmigaOS is no multi-user OS but it's still known for its smooth multitasking
with low hardware requirements. That's where he didn't quite agree.
-> With Good multitasking there is no "first", the CPU time should be spread out equally so that the user doesn't notice a slowdown in any of the programs running.
I don't quite agree. Heavy tasks should be background jobs only active when the user isn't
doing anything i.e. the processor's not doing anything sensible anyway. If I'm rendering a
24bit raytrace and at the same time using a wordprocessor, I'd want the wordprocessor to
have first priority so that it won't be slowed down by the raytrace. A wordprocessor leaves
plenty of processor-time for the raytrace when I stop writing to think and such. That way the
wordprocessor will work smooth, and the raytrace will still get rendered without to much loss
of time...
-ali-
Lars Duening
>Lars Duening (due...@ibr.cs.tu-bs.de) wrote:
>
>: >-> > take this account (e.g. a editor could run at priority 1, turning
>: >-> > it down to 0 for lengthy operations such as searching).
>
>: >Problem is software developers usually don't... IMHO it is not something
>: >developers should have to bother themselves with.
>
>: This is almost an religious issue, but: who else but the developers
>: should (and _can_) bother with the priority their program runs on?
>: After all they are the ones who know exactly how much resources their
>: program will need for how long time.
>
> I beg to differ.
>
> The developer must always give the user control. TOTAL control on single
> user machines. So there should be a way for the user to adjust the
> priority the programs runs at. Of course a sensible default should be
> provided.
You don't contradict me. Of course the user should have a say in how
the program alters its priorities (or if it should at all), that's
what configuration files are for.
But it's still the developer which implements the feature of automatic
priority alteration for specific ops.
--
Lars Duening; due...@ibr.cs.tu-bs.de
Hans-Joerg Frieden
that. They almost always turn out to be complete idiots, or just don't know what they
are talking about ("I don't know the amiga, but it must be crap!"). Dunno what it is in
your case, but...
AmigaOS isn't unstable anymore. It is insecure, but security (memory protection and
stuff) is only an exuce for lazy programming. At least it HAS multitasking, and by all
means it isn't dump. What the hell are low-cost tasks, and why should you give computing
time to a process that is waiting for user interaction (mind you, WAITING!!). OS/2 and
Windows and MSDOS and MacOS aren't suited for Multiuser purposes too - that's what
PERSONAL COMPUTER stands for. Go to a unix Box if you need this.
You want fact? Do you use an Amiga or not? If you use one, you should know that it isn't
true...
Regards, Hans-Joerg.
--
---Hans-Joerg Frieden (in...@uni-trier.de)-------------------------------------
Q: Why doesn't Quicksort work on a Pentium CPU
A: You can only Conquer, not divide.
-------------------------------------------------------------------------------
Hans-Joerg Frieden
>>
>> > Too unstable,
>Yes, he's right but there are many other OSes that are even more unstable.
>Just look at anything MS have ever done.
>> The main problem are unstable programs, since the AmigaOS doesn't have
>> memory protection. And it is not simple to add it now.
>That's their biggest mistake! I definitely agree.
I disagree. Memory protection is for dump programmers. And what's the use, anyway. If a
program you're running does a faulty memory access, you get a core dump. Your work is
gone, like it would be in a complete crash. On the Amiga, you _sometimes_ have the
chance to recover work.
>> > dumb multitasking (doesn't take low-cost tasks first to speed up
>> > user-interaction and so on),
>>
>> call it "simple multitasking". The scheduler is pretty simple compared
>> to the more sophisticated algorithms used in other OSes. But for the
>> main target audience it works well. And software can be written to
>> take this account (e.g. a editor could run at priority 1, turning
>> it down to 0 for lengthy operations such as searching).
What sophisticated algorithms? In what OSes? The only OSes I know that do multitask is
AmigaOS, UNIX and OS/2. Windoze and MacOS use cooperative crap, that doesn't count as
Multitasking. Everyone knowing something about scheduling algorithms will tell you that
a scheduler MUST be simple, so that task switching is FAST. Look at Linux, which always
steps down its complete task tree when sheduling, resulting in a dead slow system when
many tasks are alive.
Hans-Joerg Frieden
>completed. But I don't consider resource tracking to be important.
I think that resource tracking makes people go and allocate lots of stuff, and never
free it until the end of the application. I think this is the way the Mac does it, also
I don't know for sure. With dynamic allocation and de-allocation, you'll have the most
of free system resources.
Lars Garden
: A guy 'round here who knows pretty much about hardware said today
: that the AmigaOS sucks on many points:
I guess I'll add my 0.2 NKR also.
: Too unstable,
Used Windows lately? ;-)
Was he talking about the OS, or the applications? I don't think I've
ever had a crash that was caused by the OS since I upgraded to v3.0.
Applications, on the other hand, are a different matter. Since you
don't have memory protection, a single typo in a program can take down
the whole system.
: Too insecure
: (no sourcetracking/process-control),
This is Nr. 1 on my list of 'I wish AmigaOS had..'.
One of the basic flaws of AmigaOS is that they did not make it possible
to easily add memory protection and resource tracking later on.
(I'd kill for an AmigaOS work-alike with MP and RT added ;-))
: dumb multitasking (doesn't
: take low-cost tasks first to speed up user-interaction and so on),
Let's do a little test.
1) Take a Mac, a Windows PClone and an X/Unix workstation and place them
besides an Amiga.
2) Equip them with similar amounts of RAM, CPU power, disks, etc..
3) Run a raytracer or similar "CPU hogger" on each machine.
4) Run an interactive application (Text editor, word processor...)
Which computer has best response time to user-interaction?
The AmigaOS multitasking is not 'dumb', it is simple and *fast*. Fast
user-interaction is handled by giving those "low-cost" tasks higher
priorities than application tasks.
: bad for multi-user purposes...
Is that guy a Unix advocate? Please remind him that different OS'es
are targetted at different uses. AmigaOS is an excellent *single user*
OS. It is designed to be fast and responsive to a single user, not
to be bullet-proof against buggy programs and hacker-attacks.
--
// Lars Gaarden. Student at Trondheim College of Engineering.
\X/ la...@stud.idb.hist.no http://colargol.edb.tih.no/~larsg/ IRC: Lynet
På kjøttmarkedet hører hjernen hjemme blant innvollene.
Anders Lindgren
[snip my article about a pal's criticism of AmigaOS]
-> Insecure? It's supposed to be a "personal" computer! Not some
-> central server in a corporate environment.
What could possibly be wrong with having very high reliability on a personal computer!
-> "Dumb multitasking": While it doesn't dynamically adjust task
-> priorities, it does permit tasks to change their own priorities; using a
-> multi-priority round-robin PREEMPTIVE scheduling algorithm. Windows, in the
So he's wrong there...
-> three weeks I've been looking at it appears to only have TWO priority levels,
-> foreground and background -- and plays some tricks within those priorities to
-> allow for some tasks to get more or less time in the scheduler...
Nobody ever said Windows (not even an operating-system to start with!) was any
good whatsoever! :-)
-> Multi-user? see "Insecure"
If someone wants to network Amigas, he'd probably think it nice if the OS made
it easy for him. Personally I have no idea as to how AmigaOS works...
If it was good for multi-user systems as well, they might sell some as
workstations too...
-> It would be nice if it supported memory protection, but that would
-> also mean that it would not be able to run on machines without an MMU -- ie,
-> no 68000, 68010, 68020 machines...
Now that's a problem, I agree.
/ali
Alfred Fent
|> Anders Lindgren (dat9...@ludat.lth.se) wrote:
|> : A guy 'round here who knows pretty much about hardware said today
|> : that the AmigaOS sucks on many points:
|>
|> : take low-cost tasks first to speed up user-interaction and so on),
|>
|> user-interaction is handled by giving those "low-cost" tasks higher
|> priorities than application tasks.
|>
Let me ask a short question: What is a "low-cost" task? How do you (or the OS)
calculate the costs of a task? How much memory it has allocated? How long it
is in the system? How much disk-I/O it has got? Or whatever?
I think it's pretty senseless to do such cost-calculation. The task that's
running for 5 hours could end the next microsecond, or it could continue for
a year. Same for the other things (memory allocation, disk-I/O,...). The only
solutions would be either to give a hint to the system ("this task will run
for about 10 seconds") - this was used in the 60's or so, I think - or to
build a computer that can calculate the future - but this computer would be
used for other purpose (soccer, lottery, who will buy C=, ...) ;-)
Alfred
--
-------------------------------------------------------------------------------
-- multae causae sunt bibendi (Lat. Sprichwort) -- Alfred Fent ---
-- ergo bibamus! (Papst Martin IV) -- fe...@fmi.uni-passau.de ---
-------------------------------------------------------------------------------
Thomas Frieden
>A guy 'round here who knows pretty much about hardware said today
^^^^^^^^ :-) !
>that the AmigaOS sucks on many points: Too unstable, Too insecure
Try Windows. Every now and then you get this stupid request that there was an error. Its not that
stable. OS/2 is somewhat better, but from time to time the system hangs and needs 30-40 seconds to
recover....
Security is sure not the big strength of the Amiga, but you don`t have that in Windows or OS/2.
Security is meant to protect multiple users from one another, and the Amiga (as well as Windows and
OS/2) is no multiuser-machine, but a Personal Computer....
>(no sourcetracking/process-control), dumb multitasking (doesn't
^^^^^^^^^^^^^^^
Huh ? You can kill tasks, change their priority, send them signals or messages, so what else do you
want?
>take low-cost tasks first to speed up user-interaction and so on),
Compared to Linux, the Amiga multitasking is pretty good. Linux makes some nasty stuff when
switching tasks, so the multitasking is somewhat slow (compensated by some 486 or so..).
Only OS/2 has really good task switching by implementing threats, but that is no invention of OS/2,
but of ther underlying MACH kernel (which is also availible on the Amiga).
As for user-interaction, the tasks with user-interaction are tasks which normaly have LOW priority,
because the machine waits most of the time (in the sceme of comupters, user inputs are as frequent
as getting money ;-( ). Apart from that, the Amiga uses a clever system that puts tasks to sleep
when they wait for user input, so other tasks can run.
>bad for multi-user purposes... Anyone have any ->facts on this one?
As bad as Windows, Dos or OS/0.5. It was not designed to be Multiuser. Thats why you call such
machines PC (PERSONAL Computer, not only applied to the DOS machines!).
>Experienced OS-folk's opinions also welcome!
IMHO your friend should stick to hardware, he is not that great in Software...
MfG Thomas
--
-- Thomas Frieden (in...@apollo23.uni-trier.de) - Finger for PGP --------------
"Why is it, that the years seem to fly by, but the nights seem to last
forever" - Elminster of Shadowdale, Sage of the Forgotten Realms
----------------------------------------------------- Amiga owner since 1988 --
Maxwell Daymon
: In article <wulfraedD...@netcom.com>, wulf...@kd6mog.netcom.com (Dennis Lee Bieber) writes:
: [snip my article about a pal's criticism of AmigaOS]
: -> Insecure? It's supposed to be a "personal" computer! Not some
: -> central server in a corporate environment.
: What could possibly be wrong with having very high reliability on a personal computer!
Really! Just because MY life is on it makes unreliability okay? By the
way, PERSONAL computer has nothing to do with "warm fire, dog sleeping on
the carpet scene" It's called a PERSONAL computer as opposed to a
client/server system with a mainframe and terminals (e.g. you have your
own processor, etc. PERSONAL computers are VERY often used in big business)
------------------
Maxwell Daymon
mda...@rmii.com
------------------
Rene Laederach
Carl Laurence Gonsalves hacked the keyboard on Fri, 17 Mar 1995 02:56:04 GMT about
`Re: AmigaOS sucks?' in comp.sys.amiga.misc and wrote:
CLG> I then moved the pointer over to the other window, because I wanted to find
CLG> a file. The instant the other window became the active one (even though I
CLG> wasn't typing anything else), the compile slowed down to a virtual stop in
CLG> comparison. I couldn't believe it. Clicking between the two windows would
CLG> drastically alter the speed of the compile, even though the other window
CLG> just had a command prompt that wasn't doing anything.
Is this cooperative multitasking? :) Or competitive multitasking? :)
Bye
Rene Laederach
FIDO: 2:301/723.4 | Mit Penn-Tiums faengt die neue Aera des
Internet: mu...@snoop.alphanet.ch | Schlafgenusses an...
Alfred Fent
|> fe...@vivilo.uni-passau.de (Alfred Fent) writes:
|> >Let me ask a short question: What is a "low-cost" task? How do you (or the OS)
|> >calculate the costs of a task? How much memory it has allocated? How long it
|> >is in the system? How much disk-I/O it has got? Or whatever?
|>
|> >I think it's pretty senseless to do such cost-calculation. The task that's
|> >running for 5 hours could end the next microsecond,
|>
|> time and each input event causes just a short burst of CPU activity.
|>
I can't see that. Take, for example, the input event "shift-key". Here
you are right: a short burst of CPU activity ("oh, shift pressed"). So I (or
the OS) could give the user interface task (in this example a shell) a low
cost-value. But if you press, say, RETURN, the shell might begin parsing what
you entered before, do some variable-substitution, start a program because you
used backticks ("delete `date`"), insert this again, and finally start a
backup of your harddisk, of course with compression. And that is NOT what
I call "just a short burst of CPU activity". So here we would wish to have a
high cost-value. So, is the shell a low- or a hight-cost task?
The thing is easier on uni*x-systems where a shell always creates a new process
for a program, no matter if it's in the background ("run backup" in Amiga-words,
"backup &" in uni*x-style) or not ("backup"), while the Amiga-shell runs
foreground-processes as a kind of subprogram without a new task-structure (or
am I wrong here?)
Michael van Elst
>|> But that's not true for the 'user interface task'. It runs all the
>|> time and each input event causes just a short burst of CPU activity.
>|>
>I can't see that. Take, for example, the input event "shift-key". Here
>you are right: a short burst of CPU activity ("oh, shift pressed"). So I (or
>the OS) could give the user interface task (in this example a shell) a low
>cost-value.
Well, that was a bit misleading. I thought about the task that produces
the immediate feedback. That's not the shell but the task moving the
cursor when you type in a shell.
>I call "just a short burst of CPU activity". So here we would wish to have a
>high cost-value. So, is the shell a low- or a hight-cost task?
The part of the shell that parses and executes commands is high cost.
That's why shells that also do the presentation (like csh that manages
the command line editing) does not behave well under load. The
distiniction between command line editor (user interface at high
priority) and parsing/executing (high cost task at low priority)
works much more smoothly.
>The thing is easier on uni*x-systems where a shell always creates a new process
>for a program, no matter if it's in the background ("run backup" in Amiga-words,
>"backup &" in uni*x-style) or not ("backup"), while the Amiga-shell runs
>foreground-processes as a kind of subprogram without a new task-structure (or
>am I wrong here?)
While the description is true, why would it make it easier on UNIX
systems ? You cannot set the priority for UNIX tasks. UNIX however
does a reasonable job as it puts programs waiting for terminal I/O
at a high priority itself (and the priority decays for each process
after some time). UNIX gets unresponsive if there are too many
terminal I/O processes or when the system starts paging.
Michael van Elst
>Let me ask a short question: What is a "low-cost" task? How do you (or the OS)
>calculate the costs of a task? How much memory it has allocated? How long it
>is in the system? How much disk-I/O it has got? Or whatever?
Of course how much CPU load it generates (load = percentage of available
CPU time).
>I think it's pretty senseless to do such cost-calculation. The task that's
>running for 5 hours could end the next microsecond,
But that's not true for the 'user interface task'. It runs all the
time and each input event causes just a short burst of CPU activity.
Regards,
J.T.Vermeulen
Fredrik Solenberg - HFB T d93 <d93...@t.hfb.se> wrote:
>> > A guy 'round here who knows pretty much about hardware said today
>And is there any sucessful implementation of the SJF algorithm in a
>preemptive system yet?
Sure--it's called SRTF! :-)
Problem is, you're still only guessing what will be the "Shortest Job"
or the one with the "Shortest Remaining Time". The user or programmer
can sometimes do a better job of that (such as having floppy drivers
and GUI managers running at a consistently high priority even if they
do use up their quanta all the time).
Jeroen
Carl Laurence Gonsalves
Anders Lindgren <dat9...@ludat.lth.se> wrote:
>In article <wulfraedD...@netcom.com>, wulf...@kd6mog.netcom.com (Dennis Lee Bieber) writes:
>
>[snip my article about a pal's criticism of AmigaOS]
>
>-> Insecure? It's supposed to be a "personal" computer! Not some
>-> central server in a corporate environment.
>
>What could possibly be wrong with having very high reliability on a
>personal computer!
security != reliability
In fact, security features (in general) only make something less
convenient. Since 99% of Amiga users don't need security features, why
inconvenience them by having such things in place?
BTW, NT is *really* secure, especially with that "CTRL-ALT-DELETE to log
on" thing. Geez, nobody but Micro$oft could override the three finger
salute...
(note sarcasm)
--
Carl Laurence Gonsalves - clgo...@undergrad.math.uwaterloo.ca
http://www.undergrad.math.uwaterloo.ca/~clgonsal
Martin Hauner
> And where's your problem here? I do that all the time; once I started
> the renderjob I set it to a low priority (somewhere below 0, i. e.) So
> none of my other programs gets slowed down at all and the render
> engine takes all the free CPU time there is. What else could I want?
That this is done automatically...
Either by the OS or by the process itself. The second is the easier
solution. The process could lower his priority when it has to do
longer calculations, just by a call to exec.SetTaskPri.
The multitasking would be much 'smoother'.
--
// MfG Martin Hauner (dri...@trashcan.escape.de)
\\/
Bernd Sieker
>
> -> With Good multitasking there is no "first", the CPU time should be spread out equally so that the user doesn't notice a slowdown in any of the programs running.
>
> I don't quite agree. Heavy tasks should be background jobs only active when the user isn't
> doing anything i.e. the processor's not doing anything sensible anyway. If I'm rendering a
> 24bit raytrace and at the same time using a wordprocessor, I'd want the wordprocessor to
> have first priority so that it won't be slowed down by the raytrace. A wordprocessor leaves
> plenty of processor-time for the raytrace when I stop writing to think and such. That way the
> wordprocessor will work smooth, and the raytrace will still get rendered without to much loss
> of time...
And where's your problem here? I do that all the time; once I started
the renderjob I set it to a low priority (somewhere below 0, i. e.) So
none of my other programs gets slowed down at all and the render
engine takes all the free CPU time there is. What else could I want?
>
> -ali-
Bernd
--
Bernd Sieker \\ email: bsi...@techfak.uni-bielefeld.de
IRC: Pink \\ HAM-Radio: DG6YHI (@DB0BQ.#NRW.DEU.EU)
--
"Bruno Heinz Jaja, unlike Strawinsky, has never been guilty of
composing harmony in all his life!"
Tim Wendt
In article <1995Mar16....@t.hfb.se>, d93...@t.hfb.se (Fredrik
Solenberg - HFB T d93) writes:
-> > memory protection. And it is not simple to add it now.
->
-> That's their biggest mistake! I definitely agree.
>Yep. When multitasking memory-protection should be overall standard! At the
>time we discussed AmigaOS we were comparing it and its multitasking-ability
to
>unix workstations since AmigaOS is said to have picked much of the goodies
from
>there... I don't know about OS3.1 though... Any improvements on these
points?
But you guys need to remember when the AmigaOS was written the target
processor was the 68000 with no MMU and the base machine had 256K. Memory
protection would have to be written completely in software like UNIX. Given
that the base machine had so little memory, it was a good decision to skip
memory protection. And given that no *mainstream* personal computers at the
time even could pretend to multitask...
On a related subject...has anyone seen Win95? It has vastly improved
multitasking capabilities over Windows 3.1 however it is still nowhere near as
efficient as the Amiga OS. It is very Intuition-ish though. The old program
groups are gone...and you can drill down through directories like in
Workbench. It's pretty sharp looking...but not impressive enough to switch
machines!
Tim Wendt
tim....@daytonoh.ncr.com
Alfred Fent
|> fe...@vogelweide.uni-passau.de (Alfred Fent) writes:
|> >|> But that's not true for the 'user interface task'. It runs all the
|> >|> time and each input event causes just a short burst of CPU activity.
|> >|>
|>
|> >I can't see that. Take, for example, the input event "shift-key". Here
|> >you are right: a short burst of CPU activity ("oh, shift pressed"). So I (or
|> >the OS) could give the user interface task (in this example a shell) a low
|> >cost-value.
|>
|> Well, that was a bit misleading. I thought about the task that produces
|> the immediate feedback. That's not the shell but the task moving the
|> cursor when you type in a shell.
OK, accepted.
|>
|> >The thing is easier on uni*x-systems where a shell always creates a new process
|> >for a program, no matter if it's in the background ("run backup" in Amiga-words,
|> >"backup &" in uni*x-style) or not ("backup"), while the Amiga-shell runs
|> >foreground-processes as a kind of subprogram without a new task-structure (or
|> >am I wrong here?)
|>
|> While the description is true, why would it make it easier on UNIX
|> systems ? You cannot set the priority for UNIX tasks.
What I thought of was that on a unix-system you know "this is my shell", it has
got process-ID 28128, and I can lower it's priority if I want to. If I start a
program it gets another ID, a new "task-structure", and if I higher the
priority of this process this doesn't affect the shell. On the Amiga it would
also increase the shell's priority iff the program wasn't started using "run".
NB: You can set the priority of unix processes. Ever heard of nice-values? First
line of man-pages says:
nice - run a command at low priority
renice - alter priority of running processes
|> UNIX gets unresponsive if there are too many
|> terminal I/O processes or when the system starts paging.
Or when another one uses a lisp-compiler that uses 99.21% of CPU-time ;-(
Michael van Elst
>I think that resource tracking makes people go and allocate lots of stuff, and never
>free it until the end of the application.
Sort of. With the Mac, every program gets a user assign chunk of memory.
If you want to load multiple programs you have to limit the amount of
memory they get before starting them.
Asko Tontti
>A guy 'round here who knows pretty much about hardware said today
>that the AmigaOS sucks on many points: Too unstable, Too insecure
What I think it is stable!
>(no sourcetracking/process-control), dumb multitasking (doesn't
Use SAS/C and make custom code plus amiga.lib :) And multitasking
in Amiga works very well if you don't count threads and new boopsi
system which don't work well in AmigaDOS 3.x (input.device is too
busy to handle user interface)
>take low-cost tasks first to speed up user-interaction and so on),
>bad for multi-user purposes... Anyone have any ->facts on this one?
MultiUser FileSystem is for that purpose and it is also very good.
>Experienced OS-folk's opinions also welcome!
With Regards, Asko
--
Asko Tontti
ato...@snakemail.hut.fi
Asko_...@llauta.fipnet.fi
Asko Tontti
>Yes, he's right but there are many other OSes that are even more unstable.
>Just look at anything MS have ever done.
>
>> The main problem are unstable programs, since the AmigaOS doesn't have
>> memory protection. And it is not simple to add it now.
>That's their biggest mistake! I definitely agree.
Originally Amiga's Exec did have support for adding MMU with protections
but it was removed because there would have not been any programs to run
with it including Workbench.
>> Why didn't your friend address the real problems? There are quite a few
>> design problems... Forbid(), Hardware access, dos, RTG to name some of the
>> more obvious ones :)
By the way what is wrong with Amiga's dos. Only thing I don't like is
remains of BCPL-language.
Michael van Elst
>What I thought of was that on a unix-system you know "this is my shell", it has
>got process-ID 28128, and I can lower it's priority if I want to. If I start a
>program it gets another ID, a new "task-structure", and if I higher the
>priority of this process this doesn't affect the shell. On the Amiga it would
>also increase the shell's priority iff the program wasn't started using "run".
Yes, but that just means that the program has to restore its priority
before exiting. The shell cannot do anything for synchronous commands,
wether UNIX or AmigaOS.
>NB: You can set the priority of unix processes. Ever heard of nice-values? First
>line of man-pages says:
>nice - run a command at low priority
>renice - alter priority of running processes
That's not the priority. It is a measure how fast priority deteriorates.
A task at nice 20 can still preempt a task at nice 0 if its priority
is higher. The priority is set by the kernel at each event and is then
decreased after a time slice.
>|> UNIX gets unresponsive if there are too many
>|> terminal I/O processes or when the system starts paging.
>Or when another one uses a lisp-compiler that uses 99.21% of CPU-time ;-(
No. It will execute commands slowly, it will execute commands very slow
because the LISP compiler probably eats all memory and every new command
will cause swapping. But it will respond fast to your typing.
Asko Tontti
>But I want memory-protection so I can work without having to worry about
>the whole system going down the drain when a buggy task decides to crash...
>Is there a commodity to do this? The A4000 sells a lot on the professional
>video-market, and they're likely to be fuzzy about the reliability and smooth-
>ness not so important to the 'main target audience'... Besides, I'm saving
>for an A4000/030 for semi-professional use, and I too have become fuzzy after
>having run like 10 tasks simultaneously without problems on these SUN3 Sparcs.
>I guess OS3.1 is much more stable than my A500/1.3 :-) But how good is the
>multitasking?
It works better because bugs have been fixed (yes, there were major
bugs in the code of scheduler in 1.3)
>in account. Although I know almost nothing about the OS's functions on
>lower level, I do love the appearance of OS3.1 and except the unstability
AmigaOS is great OS from the point of view of programmers. Only minus is
lack of resource tracking but I have diceded(?) to write my own custom
library for that purpose.
Asko Tontti
>doing anything i.e. the processor's not doing anything sensible anyway. If I'm rendering a
>24bit raytrace and at the same time using a wordprocessor, I'd want the wordprocessor to
>have first priority so that it won't be slowed down by the raytrace. A wordprocessor leaves
>plenty of processor-time for the raytrace when I stop writing to think and such. That way the
>wordprocessor will work smooth, and the raytrace will still get rendered without to much loss
>of time...
That is why there is ChangeTaskPri in C-directory.
Asko Tontti
>>> The main problem are unstable programs, since the AmigaOS doesn't have
>>> memory protection. And it is not simple to add it now.
>>That's their biggest mistake! I definitely agree.
>Originally Amiga's Exec did have support for adding MMU with protections
>but it was removed because there would have not been any programs to run
>with it including Workbench.
Sorry, but I was not thinking what I wrote. I meant Exec did have support
for adding code for supporting MMU and protections.
Alfred Fent
|> fe...@piligrim.uni-passau.de (Alfred Fent) writes:
|>
|> >Or when another one uses a lisp-compiler that uses 99.21% of CPU-time ;-(
|>
|> No. It will execute commands slowly, it will execute commands very slow
|> because the LISP compiler probably eats all memory and every new command
|> will cause swapping. But it will respond fast to your typing.
Then "my" SparcStation 5 here isn't a Unix-machine as it doesn't respond fast.
Maybe I should't have used XWindows and all those beautiful xterms and work
on the pure console. But that doesn't belong in this newsgroup...
Jukka Marin
>|> : take low-cost tasks first to speed up user-interaction and so on),
>|>
>|> The AmigaOS multitasking is not 'dumb', it is simple and *fast*. Fast
>|> user-interaction is handled by giving those "low-cost" tasks higher
>|> priorities than application tasks.
>|>
>Let me ask a short question: What is a "low-cost" task? How do you (or the OS)
>calculate the costs of a task? How much memory it has allocated? How long it
>is in the system? How much disk-I/O it has got? Or whatever?
Nah. It _is_ possible to monitor how much a task uses CPU time. The tasks
that use only a small portion of their time slice every time they get a
chance to run should have a higher priority. Also, tasks that use their
whole time slice when they get the CPU should have a lower priority. It
has nothing to do with memory usage or disk I/O (although doing disk I/O
usually means that the task will not use up its time slice).
This system lets editors, shells etc. run at a higher priority, because they
usually consume very little CPU time and only when the user is typing in
tect or commands. Compilers, ray-tracing etc. use as much CPU time as they
are given, so they should be running at a lower priority. This all results
in fast interactive operations while the more time-consuming tasks run in
the background.
AmigaOS gives every task the same time slice and never adjusts the task
priorities by itself.
The worst thing I usually run into is having one task running in the
background, eating all CPU time it can possibly get (printing from
FinalWriter, running a compiler etc) and trying to load another program
at the same time: Most Amiga programs consist of tens or hundreds of
small program chunks. Only one chunk is loaded at once, then it is
relocated, the next chunk is loaded etc. until the whole program has
been loaded into memory. Every disk operation causes several task
switches, stopping the loader process temporarily.
This is all OK as long as there's no other task running at the same
priority. If there is, the program loading slows down tremendously.
The problem is caused by the scheduler which first lets the busy-
looping task run it's whole time slice, then switches in the loader
process which posts a read request to the filesystem and goes back
to sleep (ie. runs only a very short period of time). Then the busy-
looping task get one whole time slice, after which the loading process
gains the CPU, relocates one chunk in RAM, and posts another read
request to the filesystem, letting the busy task run again. Thus,
the CPU time is not distributed evenly between the two processes.
In UNIX, the scheduler monitors the CPU times used by the processes and
lets the "fast" processes (which usually are interactive processes) run
first. This makes UNIX feel much faster when there's heavy loading on
the system - but slower when there is no load (because the task switching
and the whole scheduler are much more complicated than those of AmigaOS).
>I think it's pretty senseless to do such cost-calculation. The task that's
>running for 5 hours could end the next microsecond, or it could continue for
>a year. Same for the other things (memory allocation, disk-I/O,...). The only
>solutions would be either to give a hint to the system ("this task will run
>for about 10 seconds") - this was used in the 60's or so, I think - or to
>build a computer that can calculate the future - but this computer would be
>used for other purpose (soccer, lottery, who will buy C=, ...) ;-)
IMHO, you're missing the point. ;-) I'm not saying the AmigaOS multitasking
was bad. I'm just saying it could work better - at least on the fast CPU's.
On a 7.09 MHz 68000 a complex scheduler could easily waste 50% of the CPU
power..
-jm
--
---> http://www.jmp.fi/~jmarin <---
Michael van Elst
>Then "my" SparcStation 5 here isn't a Unix-machine as it doesn't respond fast.
Or it has not enough memory :)
Alfred Fent
|> fe...@piligrim.uni-passau.de (Alfred Fent) writes:
|> >Then "my" SparcStation 5 here isn't a Unix-machine as it doesn't respond fast.
|>
|> Or it has not enough memory :)
System Model : SPARCstation 5
Main Memory : 56 MB
Virtual Memory : 268 MB
I know why I love my amiga...
Mike Nielsen
>Fredrik Solenberg - HFB T d93 (d93...@t.hfb.se) wrote:
>Just for the record: do not forget that other OSes tend to have features
>that AmigaOS doesn't have. And remember: *every* feature needs memory.
>I'm not trying to defend memory-hungry PC OSes since I can't tell whether
>they need it due to bad programming or due to great features. But it
>could be the features :)
That may be so but 90% of users don't need 90% of the featurs, so
a modular approach, where you can add features dynamically as you need them
is so much more sensible, rather than the approach that all users will
need these functions. Why not use a small kernel operating system,
that will do the basic OS operations, and have add on's that can expand
the system to what you need, sure it makes implementation a little more
difficult, but with todays software standards moving towards an object
oriented approach, this seems to make eminently more sense, than to have
an OS that has all the bells and whistles that only some people wants.
This would allow access to all the features that OS/s have now
but reduce the requirements on the machine significantly. Thus as with
Amiga OS you can add nearly every feature that systems such as OS/2,
windows (and NT) have, but in a object kind of fashion, allowing us to
run systems with a very minimal configuration, using the same OS as the
larger machines have.
Personally I don't mind the features, but I would love to be able
to cut the system down to a minimal configuration, that could run on a
very minimal machine - or free up memory for some heavy duty application. I
known that virtual memory is available, and is used by a lot of OS/s such
as windows, os/2, windows NT etc etc etc. However virtual memory is just
too slow for some applications.
all with IMHO of course :->
mike
--
-----------------------------------------------------------------
Michael Nielsen #include <stddisclaimer>
Philips Public Telecommunications Systems Phone: +61 3 5743732
Melbourne, Australia Fax: +61 3 5743577
norman_henry
> AmigaOS gives every task the same time slice
^^^^^^^^^^
Time slice? As this is the first time I see it mentioned that Amiga OS is
a timesharing OS, giving "equal slices of time to each task," can someone
tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
"pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
way I thought Amiga OS works is that, given no higher priority task, when
a process gets the CPU, it will stay there until a) it waits voluntarily,
or b) a higher priority task becomes ready. What is this "same time slice"
stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
Henry Norman
------------------------------------------------------------------
__o __o st...@hotcity.com /W\ Strix Merx Mitis:
-\<,-\<, henry....@cup.portal.com (Ovo) Usus Tandem, Nisi
(*)/=-=/(*) norman...@tandem.com ))#)) Sententi Ego Ipse
-------------------------------------------m-m--------------------
James Cooper
In article <3kuugj$3...@mercury.cpd.tandem.com>, hen...@storage.tandem.com (norman_henry) writes:
>jma...@metso.jmp.fi (Jukka Marin) writes:
>> AmigaOS gives every task the same time slice
> ^^^^^^^^^^
>Time slice? As this is the first time I see it mentioned that Amiga OS is
>a timesharing OS, giving "equal slices of time to each task," can someone
>tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
>"pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
>way I thought Amiga OS works is that, given no higher priority task, when
>a process gets the CPU, it will stay there until a) it waits voluntarily,
>or b) a higher priority task becomes ready. What is this "same time slice"
>stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
By that algorithm, tasks with the same priority couldn't run together,
since the first task at that priority that got the CPU would keep it
until a higher priority task came along.
The more complete description of exec is a "priority drive pre-emptive
multitasking kernel, with round-robin scheduling."
This means that tasks with a higher priority get the CPU first, lower
priority tasks get it next, etc. Tasks at the same priority level,
though, get equal amounts of CPU time in a circular fashion. The
pre-emptive part comes in because the tasks themselves don't have any
say over when the task-switch occurs (that's cooperative multitasking),
exec simply switches one task out when its time is up, and starts the
next task going.
The "time slice" being talked about is actually referred to (on the
Amiga) as a "quantum," and by default, the quantum is (if I remember
right) about 65 milliseconds.
WHAT DOES ALL THAT MEAN???
Well, suppose you have 4 tasks, all with the same priority. They are in
an exec list, so exec can tell which one is ready, which one is next,
which one is currently running, etc. The list is conceptually like this
1
2
3
4
Now, task one, at the top of the list, is the currently running task.
It runs happily along, not even realizing it is in a multitasking system
at all. However, its quantum of time passes, and it isn't finished yet,
so exec moves it to the bottom of the list, and gives the next task a
chance to do something. Now the list looks like:
2
3
4
1
If at any time a running task exits, it is simply removed from the list,
and the rest keep going around and around (round-robin) until either all
the tasks are finished, a higher priority task needs the CPU, or the
machine gets reset.
Does that clear it up for you?
--
---------------
Jim Cooper
(ja...@unx.sas.com) bix: jcooper
Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!),
and not necessarily those of my employer.
"That's me alright. Roadkill on the Information Superhighway."
Pete Goodeve
Anders Lindgren <dat9...@ludat.lth.se> wrote:
> ... Besides, I'm saving
>for an A4000/030 for semi-professional use, and I too have become fuzzy after
>having run like 10 tasks simultaneously without problems on these SUN3 Sparcs.
*10* tasks?? (:-)) I typically run 50 or 60 at once on my A2000! (Sure
they're event-driven, so they spend a lot of time waiting, but there's no
slowdown.)
[...and "fuzzy"...? (Sorry -- couldn't help it. (:-) Guess you mean "fussy".]
-- Pete --
Pete Goodeve
James Cooper <ja...@cdevil.unx.sas.com> wrote:
>In article <3kuugj$3...@mercury.cpd.tandem.com>,
> hen...@storage.tandem.com (norman_henry) writes:
>>jma...@metso.jmp.fi (Jukka Marin) writes:
>>> AmigaOS gives every task the same time slice
>> ^^^^^^^^^^
>>Time slice? As this is the first time I see it mentioned that Amiga OS is
>>a timesharing OS, giving "equal slices of time to each task," can someone
>>tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
>>"pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
>>way I thought Amiga OS works is that, given no higher priority task, when
>>a process gets the CPU, it will stay there until a) it waits voluntarily,
>>or b) a higher priority task becomes ready. What is this "same time slice"
>>stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
>
>By that algorithm, tasks with the same priority couldn't run together,
>since the first task at that priority that got the CPU would keep it
>until a higher priority task came along.
>
>The more complete description of exec is a "priority drive pre-emptive
>multitasking kernel, with round-robin scheduling."
>
>
>Does that clear it up for you?
Well -- not quite (:-/)... Norman and Jim each seem to have got hold
of one side of a slightly more complex situation.
Jim is quite right that if you have several tasks at the same priority
that are *compute-bound* (i.e. running continuously) they will each get
a defined time slice in round-robin fashion, and will be summarily yanked
from execution when their time is up.
On the other hand, this isn't often the case in the Amiga environment
(at least it isn't for me!). Most tasks spend most of their time *waiting*
for some external event to happen -- Intuition waiting for a mouse-action
or key-click, the disc device waiting for a completion interrupt, and so on
-- so a time-slice doesn't enter into it at all. A task in a wait-state
doesn't take part in the round-robin; it only gets put in the queue (if there
is one at that priority at the time) when it is woken up. Sure, it gets
put at the end of the queue, but very likely the currently running task
will itself get suspended on some event, so the new one will get its turn
very quickly. If the new task doesn't get suspended again before its
time slice runs out it will of course go to the end of the queue, but
I suspect this case is rare.
The only sort of jobs I can think of that typically use up their time
slices are things like compilers and renderers. Even then, they probably
spend a lot of time waiting for disc access.
The important thing about Priority is of course that a task with a high
one that is woken up will always immediately displace any that is currently
running at a lower one, without going through any round-robin.
-----------
Going back to the earlier post that started this sub-thread:
In <3kp5u1$j...@muikku.jmp.fi> (22 Mar),
Jukka Marin (jma...@metso.jmp.fi) writes:
>
> Nah. It _is_ possible to monitor how much a task uses CPU time. The tasks
> that use only a small portion of their time slice every time they get a
> chance to run should have a higher priority. Also, tasks that use their
> whole time slice when they get the CPU should have a lower priority.
Because of the situation that I described above, this is really rather
irrelevant on the Amiga. Few tasks actually *do* use up their time slices,
and probably spend much more than the 'round-robin time' in waiting for
something to happen, so I doubt you'd see any gain. Such a scheme wouldn't
hurt, I guess, except that the extra calculation needed would slow down
task-switch times, but it wouldn't help much either.
> The worst thing I usually run into is having one task running in the
> background, eating all CPU time it can possibly get (printing from
> FinalWriter, running a compiler etc) and trying to load another program
> at the same time: Most Amiga programs consist of tens or hundreds of
> small program chunks. Only one chunk is loaded at once, then it is
> relocated, the next chunk is loaded etc. until the whole program has
> been loaded into memory. Every disk operation causes several task
> switches, stopping the loader process temporarily.
>
I don't think you're seeing quite what you think you are. (If you *are*
finding that a background task is slowing down a load, say, simply
reduce the priority of the background! The system can't tell that you
consider the load more important than the compile. This is why the user
should set priority, not the scheduler.)
One *major* problem with the AmigaOS is that it has no idea of scheduling
disc accesses. If two (or more) processes are trying to talk to the disc
at the same time, each gets its turn for a single access, and the poor
thing goes crazy swinging its head back and forth to find the different
little pieces. It would be much better if LoadProc for example could
say "Look, I've got a whole bunch of sectors to load here -- it'll be
much more efficient if you let me do them all *first*!"
And I hope all *that* helps! (:-))
-- Pete --
Michael van Elst
>Because of the situation that I described above, this is really rather
>irrelevant on the Amiga. Few tasks actually *do* use up their time slices,
>and probably spend much more than the 'round-robin time' in waiting for
>something to happen, so I doubt you'd see any gain. Such a scheme wouldn't
>hurt, I guess, except that the extra calculation needed would slow down
>task-switch times, but it wouldn't help much either.
Well, tasks do not use their time slices then it is unlikely that the
CPU is busy all the time. Then there is no problem with the user
interface because the machine is not overloaded.
But there are such tasks. Usually you assign a lower their priority
but it would be nice to have that automated. Actually, you would want
any task responding to text entry (say an editor) to run at the
priority of the CON-Handler (and lowering its priority while it is
busy for things like searching or loading). You also want tasks that
run silently in the background to run at low priorities.
>I don't think you're seeing quite what you think you are. (If you *are*
>finding that a background task is slowing down a load, say, simply
>reduce the priority of the background! The system can't tell that you
>consider the load more important than the compile. This is why the user
>should set priority, not the scheduler.)
Well, the user could set preferences and let the scheduler handle
things automatically.
>One *major* problem with the AmigaOS is that it has no idea of scheduling
>disc accesses. If two (or more) processes are trying to talk to the disc
>at the same time, each gets its turn for a single access, and the poor
>thing goes crazy swinging its head back and forth to find the different
>little pieces.
Well, there is no real solution to that problem. The only thing you can
do is to use larger reads or writes. A simple disk cache with readahead
and delayed write does that.
Regards,
--
Michael van Elst
Internet: mle...@serpens.rhein.de
Michael van Elst
>tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
>"pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
>way I thought Amiga OS works is that, given no higher priority task, when
>a process gets the CPU, it will stay there until a) it waits voluntarily,
>or b) a higher priority task becomes ready. What is this "same time slice"
>stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
When a process get the CPU, it will stay there until a) it
waits voluntarily, or b) a higher priority task becomes ready ...
... or c) when a task with the same priority is ready and a specific
time quantum (time slice) has elapsed.
So yes, time slicing happens for a group of tasks with the same
priority. Otherwise you wouldn't be able to run a CPU intensive
task and any other normal process at the same time. 'Normal'
processes all run at priority 0.
b) and c) are features of preemptive multitasking.
Pete Goodeve
Well, I hate to have to swallow my words (:-/), but...
In <3kp5u1$j...@muikku.jmp.fi> (22 Mar),
Jukka Marin (jma...@metso.jmp.fi) wrote:
> The worst thing I usually run into is having one task running in the
> background, eating all CPU time it can possibly get (printing from
> FinalWriter, running a compiler etc) and trying to load another program
> at the same time: Most Amiga programs consist of tens or hundreds of
> small program chunks. Only one chunk is loaded at once, then it is
> relocated, the next chunk is loaded etc. until the whole program has
> been loaded into memory. Every disk operation causes several task
> switches, stopping the loader process temporarily.
>
> This is all OK as long as there's no other task running at the same
> priority. If there is, the program loading slows down tremendously.
> The problem is caused by the scheduler which first lets the busy-
> looping task run it's whole time slice, then switches in the loader
> process which posts a read request to the filesystem and goes back
> to sleep (ie. runs only a very short period of time). Then the busy-
> looping task get one whole time slice, after which the loading process
> gains the CPU, relocates one chunk in RAM, and posts another read
> request to the filesystem, letting the busy task run again. Thus,
> the CPU time is not distributed evenly between the two processes.
and I replied:
> I don't think you're seeing quite what you think you are. [....]
...Then I actually went and did some experiments [always a good idea! (:-/)].
I wrote two one-line programs, one a simple endless `busy loop':
while(TRUE) {};
and the other a printout loop:
while (TRUE) printf("a line of text %d\n", i++);
and was slightly surprised to find that starting the busy-loop (at the same
priority) slowed the printout down about *six times*!
Of course what I'd forgotten is that the I/O is a different task (at a
higher priority) than the loop itself, so each time around, the printout
loop would do a very short calculation, pass it off to CON: and go to the
back of the queue. CON: would take very little time at all, but the
printout task still had a (relatively) long wait before its next turn.
So, yes, Jutta is right: processes that do very little between I/O calls,
where the I/O is also fast, can be penalized by others at the same priority
that hog CPU time.
On the other hand, simply changing priority for such tasks doesn't quite
do it either. If, for instance, I set the priority of the busy-loop to -1,
it ceased to run at all while the printout loop was running, because then
both that and the I/O were higher priority and between them took all the
CPU. If both jobs were continuous (or even lengthy), it would be better to
have the slowdown than to block one job completely.
So if you do have to optimise such a situation, you have to have dynamic
adjustment of scheduling in some fashion. Unix does, with many users
sharing, but I'm not really convinced that it's the case for AmigaOS.
The thing is that the situation I set up above is really not one that's
very common in the Amiga environment. You can nearly always just reduce
the priority of a CPU hog to get back to top speed in the foreground.
And as long as all your background jobs have the same priority, they
will round-robin properly, and -- as long as they are all hogs! -- won't
even suffer the problem of my rather artificial test. Foreground (i.e.
interactive or other I/O bound tasks) don't hog anyway, so everything
runs well.
As I said before, though, I think the user (or the programmer, where
appropriate) can better make decisions regarding priority than the OS.
The CPU hog might be much more important to you than the job that doesn't
use much of its time slice: you may think it more important to complete
the compilation fast than to get a program loaded quickly.
Then...
In <3l15ne$p...@serpens.rhein.de> (25 Mar),
Michael van Elst (mle...@serpens.rhein.de) writes:
>
> [.....]
> But there are such tasks. Usually you assign a lower their priority
> but it would be nice to have that automated. Actually, you would want
> any task responding to text entry (say an editor) to run at the
> priority of the CON-Handler (and lowering its priority while it is
> busy for things like searching or loading). You also want tasks that
> run silently in the background to run at low priorities.
Yes, but... (:-)) Exactly *how* would you give the system power to
make such decisions 'correctly'? Again, *you* may want searches and loads
in an editor to run at low priority: *I* would probably want them to be
as fast as possible to minimize user-fidget time... And how do you know
that a task without output is not 'urgent'?
There's actually little need to bump the priority of text entry either,
I've found. When I used my usual editor (DME) with the 'busy-loop' running
at the same priority, I got very little slowdown. Let's say it was
perceptible, but not annoying.
Certainly if it *is* desirable to make that sort of adjustment, I'd
say it was the editor programmer's job, not the system's, to decide
what's suitable.
>
[regarding disc-thrashing with mutiple accessors]
> Well, there is no real solution to that problem. The only thing you can
> do is to use larger reads or writes. A simple disk cache with readahead
> and delayed write does that.
I'm not sure this is true. 'Smart' disc-drivers can, for example, look
ahead at the queue of sectors to be accessed, and optimize the sequence
to reduce head movement. Program loading is more of a special case: I
think you essentially always would prefer each LoadSeg() to complete
before beginning another one; the overall time to load multiple programs
should always be faster that way (at least if the disc is not totally
fragmented) than trying to load them in parallel.
-- Pete --
Michael van Elst
>Yes, but... (:-)) Exactly *how* would you give the system power to
>make such decisions 'correctly'? Again, *you* may want searches and loads
>in an editor to run at low priority: *I* would probably want them to be
>as fast as possible to minimize user-fidget time... And how do you know
>that a task without output is not 'urgent'?
You cannot make it correctly, but you can make it better than nothing.
It would be already nice if jobs that eat more than a second CPU time
would drop their priority. You can make priority classes, so that just
the 'normal' jobs are affected (say jobs between priority -20 and 0).
>There's actually little need to bump the priority of text entry either,
>I've found. When I used my usual editor (DME) with the 'busy-loop' running
>at the same priority, I got very little slowdown. Let's say it was
>perceptible, but not annoying.
Might be true. But it wouldn't be too hard for the _editor_ to play
with its priorities.
>Certainly if it *is* desirable to make that sort of adjustment, I'd
>say it was the editor programmer's job, not the system's, to decide
>what's suitable.
I'd say that the system can do that for 'normal' programs. You do not
want to change all programs.
>I'm not sure this is true. 'Smart' disc-drivers can, for example, look
>ahead at the queue of sectors to be accessed, and optimize the sequence
>to reduce head movement.
Unfortunately they cannot do that. This just works with a couple of
tasks accessing the disk simultaneously. Even with 3 tasks there is
little effect and with 2 tasks there is no effect.
Thomas Boerkel
James Cooper wrote:
JC> The more complete description of exec is a "priority drive pre-emptive
JC> multitasking kernel, with round-robin scheduling."
JC> This means that tasks with a higher priority get the CPU first, lower
JC> priority tasks get it next, etc. Tasks at the same priority level,
JC> though, get equal amounts of CPU time in a circular fashion. The
Hmmm, I thought, it is done in such a way, but I have a question about
this, too:
Most of the tasks run at priority 0, sometimes there are over 40 on
my system. If I start now a new task with priority 0, which wants
to take 100% CPU-time (eg the FinalWriter printing-task), the whole
system slows down. If I'm now starting to work with another task
(maybe a directory tool), then there are 2 tasks which want to use
100% CPU-time.
So, I thought, each of them should now get 50% CPU-time (assuming
no other task needs the CPU). OK, so each of both should run on my
A4000/040 faster than one of them alone on my A3000, because the
040 is more than twice as fast than the 030.
But that is not the case. The directory-tool (namely SID2) is now
much slower (scrolling the lists for example) than on my A3000.
The same thing is it, if one program on my A3000 needs 100% CPU
(eg LhA). Another task then is much slower than it should
be (assuming it now should have a 12.5 MHz 68030 to work with).
Well, to be honest, those slowdowns of the whole system only
occure with real 100% CPU-consuming tasks (eg LhA).
Is this all normal or am I just imagining things?
Bye,
Thomas
Zoltan Kocsi
> AmigaOS gives every task the same time slice
^^^^^^^^^^
Time slice? As this is the first time I see it mentioned that Amiga OS is
a timesharing OS, giving "equal slices of time to each task," can someone
tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
"pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
way I thought Amiga OS works is that, given no higher priority task, when
a process gets the CPU, it will stay there until a) it waits voluntarily,
or b) a higher priority task becomes ready. What is this "same time slice"
stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
Henry Norman
As far as I know, if there are more than one equal priority ready processes
and this very priority is the highest then the OS will simply round robin
between them. In this special case the Amiga OS works as a simple
time-sharing system.
Zoltan
--
Zoltan Kocsi <zol...@research.canon.oz.au>
Iljitsch van Beijnum
: The "time slice" being talked about is actually referred to (on the
: Amiga) as a "quantum," and by default, the quantum is (if I remember
: right) about 65 milliseconds.
Hm, when I run the "PS" program it says "quantum size 4 msec" or "quantum
size 2 mseq" (seems to depend on the number of tasks) on my 1200 or 3000.
--
// Iljitsch van Beijnum, Defender of Lost Causes. Or are they?
\X/ ilji...@xs4all.nl - http://www.xs4all.nl/~iljitsch/
Iljitsch van Beijnum
: One *major* problem with the AmigaOS is that it has no idea of scheduling
: disc accesses. If two (or more) processes are trying to talk to the disc
: at the same time, each gets its turn for a single access, and the poor
: thing goes crazy swinging its head back and forth to find the different
: little pieces. It would be much better if LoadProc for example could
: say "Look, I've got a whole bunch of sectors to load here -- it'll be
: much more efficient if you let me do them all *first*!"
There is an excellent algorithm for these situations: elevator seeking.
It works like this:
If there are 5 disk access request pending, say for sectors 5, 1, 7, 3
and 9, AmigaDOS will service them in that order. But the elevator
algorithm will move the disk head in one direction at a time. So if it's
at 4, it will read 5, 7 and 9. After that, the head will start to move in
the other direction, so it will read 3 and 1.
I've read reports that this algorithm will not only speed up disk access
but also greatly reduce the noise. :-)
I think it would be possible to make an "elevator.device" that implements
this algorithm and then calls "scsi.device" or what have you to actually
access the disk.
Chris Akers
> Anders Lindgren (dat9...@ludat.lth.se) wrote:
> > A guy 'round here who knows pretty much about hardware said today
> > that the AmigaOS sucks on many points:
Maybe your "guy" needs help extracting his head out from his arse :)
---
.signature under construction
Chris Akers
That's crap. The only reason it's bad is because people don't make the software
or boards for it. The Amiga (I even heard once the os was based on
UNIX..comfirm anyone?) is just as capable at networking as a PC/MAC...so
there.
--
.signature under construction
John Verhoeven
> jma...@metso.jmp.fi (Jukka Marin) writes:
> > AmigaOS gives every task the same time slice
> ^^^^^^^^^^
> Time slice? As this is the first time I see it mentioned that Amiga OS is
> a timesharing OS, giving "equal slices of time to each task," can someone
> tell me if this is correct (no offense meant, Jukka)? In my vocabulary, a
> "pre-emptive" dispathing algorithm is _not_ a time-slicing algorithm: The
> way I thought Amiga OS works is that, given no higher priority task, when
> a process gets the CPU, it will stay there until a) it waits voluntarily,
> or b) a higher priority task becomes ready. What is this "same time slice"
> stuff? Can someone who _knows_ (are you reading this, Hazy?) enlighten me?
Their is a third condition upon which a task will be suspended by Exec:
(from the V2 Libraries RKM page 430)
> * A higher priority task becomes ready, so the OS preempts the current
> task and switches to the higher priority task.
>
> * The currently running task needs to wait for an event, so it goes to
> sleep and Exec switches to the highest priority task in Exec's ready
> list.
>
> * The currently running task has had control of the CPU for at least a
> preset time period called a quantum and there is another task of
> equal priority ready to run. In this case, Exec will preempt the
> current task for the ready one with the same priority. This is known
> as time-slicing. When there is a group of tasks of equal priority on
> the top of the ready list, Exec will cycle through them, letting each
> one use the CPU for a quantum (a slice of time).
--
_--_|\ John Verhoeven (jo...@acix.DIALix.oz.au or jo...@DIALix.oz.au)
/ \ Phone: +61 9 478 1406 or Mobile 015 779 745 (GMT+8)
*_.--._/ Address: 8 Belinda Avenue, Cloverdale, W.A. 6105
v The attention span of a computer is as long as its electrical cord.
Michael van Elst
>But that is not the case. The directory-tool (namely SID2) is now
>much slower (scrolling the lists for example) than on my A3000.
That's a problem. What happens is that the directory tool itself
does not need much CPU time. It will voluntarily release the CPU
quickly (to Intuition but which doesn't need much time either).
So the CPU bound task gets a time slice and the dirtool and intuition
get only a fraction of a time slice.
Michael van Elst
>There is an excellent algorithm for these situations: elevator seeking.
>If there are 5 disk access request pending, say for sectors 5, 1, 7, 3
>and 9
That precondition isn't met very often. In most situations you just
have 2 or rarely 3 clients. The elevator algorithm doesn't work well
with few clients.
It would be easier if a client announces what data it wants in
subsequent accesses. But then a simple read-ahead or delayed-write
is a good approximation.
Michael van Elst
>size 2 mseq" (seems to depend on the number of tasks) on my 1200 or 3000.
It probably should say 4 or 2 ticks. With 1.3 each tick was a vblank
time (16 or 20ms). Dunno what >=2.0 uses.
Niels Keurentjes
Amiga-DOS was loosely based on UNIX: it took the best points of OS's on
the market in the early 80's and expanded on them.
--
*+-----------------------------+*+------------------------------------+*
+ Marco & Niels Keurentjes + "...And the Answer, to the Ultimate +
| EMail: ma...@sandman.iaehv.nl | question of Life, the Universe and |
+ Coding/Musix/MIDI/Guitar + Everything, is, uuhhh.... 42!" +
*+-----------------------------+*+------------------------------------+*
Iljitsch van Beijnum
: >There is an excellent algorithm for these situations: elevator seeking.
: >If there are 5 disk access request pending, say for sectors 5, 1, 7, 3
: >and 9
: That precondition isn't met very often. In most situations you just
: have 2 or rarely 3 clients. The elevator algorithm doesn't work well
: with few clients.
I don't see why the elevator algorithm would do any harm. Unless data is
scattered across the disk, but that is a situation you would like to
avoid anyway.
: It would be easier if a client announces what data it wants in
: subsequent accesses.
Easy for the file system, not for the application... :-)
: But then a simple read-ahead or delayed-write is a good approximation.
I don't agree. Cache always helps, but when you have to access the disk
you had better do it in as sensible a way as possible.
Michael van Elst
>I don't see why the elevator algorithm would do any harm. Unless data is
>scattered across the disk, but that is a situation you would like to
>avoid anyway.
Oh, it doesn't do any harm. It is just not effective.
>Easy for the file system, not for the application... :-)
Yes :)
>: But then a simple read-ahead or delayed-write is a good approximation.
>I don't agree. Cache always helps, but when you have to access the disk
>you had better do it in as sensible a way as possible.
Yes, that's what read-ahead and delayed-write is all about: to cluster
accesses so that seeks are minimized.
Jason S Birch
>
> The OS is stable, but *programs* can be unstable. A badly written program
> can crash the Amiga easily -- in fact, you can write a two-line C program
> that will crash the Amiga instantly when run.
Hell, that's nothing. I can crash a Windows NT 3.5 box with one
command in a shell. :-) Try:
dir \\.\x: where "x" is the drive letter of your CDROM (and it must
have a CD in it at the time).
It will completely kill the system and cause a reboot. Ya gotta watch
those pesky dir's, I tell ya. ;-)
Also, unless you set the kernel up to limit the number of processes
per user, your average undergrad CS student learning how to use fork()
can bring a Unix box to it's knees in seconds.
I've yet to see an OS that is "uncrashable". Some are just easier than
others. :-)
> --
> Per Espen Hagen per-esp...@ffi.no Tel: +47 63807653 //
> Senior Scientist Image Processing Group NDRE, Norway \X/
>
> Any resemblance between the above views and the views of my employer,
> myself, or the view out of my window, is non-deterministic.
--
Mr Jason Birch _--_|\ Internet: jas...@cs.uwa.edu.au
Department of Computer Science / \ Tel (work): +61 9 380 1840
The University of Western Australia *_.--._/ Fax (work): +61 9 380 1089
Nedlands W. Australia 6009 v Tel (home): +61 9 386 8630
Christian Stieber
> By the way what is wrong with Amiga's dos. Only thing I don't like is
> remains of BCPL-language.
It's not just BCPL. In fact, I don't really care about that at all.
But, how would you, for example, create a file with a given set
of protection flags? DOS is pretty much a mess --- some functions
work on locks, some work on filehandles, some work on filenames.
Lots of race-conditions, since converting a "lock" into a "filename"
doesn't mean anything --- somebody could rename the file.
And some conversions aren't possible at all --- how do you get
a "lock" from an "exclusive filehandle"?
Christian
--
// Christian Stieber Sti...@Informatik.TU-Muenchen.de
\// Certified Amiga Developer http://www.leo.org/~stieber/
--------------------------------------------------------------------------
"Life starts at '030, fun starts at '040, impotence starts at '86"
keyboard not connected -- press F1 to continue
Chucky
PG> Anders Lindgren <dat9...@ludat.lth.se> wrote:
PG> ... Besides, I'm savingfor an A4000/030 for semi-professional use, and
PG> I too have become fuzzy afterhaving run like 10 tasks simultaneously
PG> without problems on these SUN3 Sparcs.
PG> *10* tasks?? (:-)) I typically run 50 or 60 at once on my A2000! (Sure
PG> they're event-driven, so they spend a lot of time waiting, but there's
PG> no slowdown.)
I currently have 75 tasks running without any problems.
10?? this is no PC :)
/ Regards
/\ ____________ ______ ___ Amiga 3000, 040, Piccolo POWER
\/ ___/ / _ / /__/ _ / / /__ USR V.Everything 28800 BPS
/ / / / / _ / / / / _ /
/ / / / / / / / /__ / / / Chucky of ViRTUAL - 680x0 Coder
/_____/_____/__/ /__/ //_//__/ / Chu...@Spray.CT.SE n' SYSOP
--------------/__/--/__/------/__/--- John Hertell 2:203/616.0@fidonet
... Pickupline: Do you spit or swollow?
( UUCP Dialup connection )
Thomas Boerkel
Michael van Elst wrote:
>> But that is not the case. The directory-tool (namely SID2) is now much
>> slower (scrolling the lists for example) than on my A3000.
MvE> That's a problem. What happens is that the directory tool itself does
MvE> not need much CPU time. It will voluntarily release the CPU quickly
MvE> (to Intuition but which doesn't need much time either). So the CPU
MvE> bound task gets a time slice and the dirtool and intuition get only a
MvE> fraction of a time slice.
Let's say, a time slice is 10 time-units (just to have something
to talk about).
You mean: The directory tool (and the related intuition-task) COULD
use 10 time-units, but NEEDS only 1 at the moment. So, control
is given to the CPU bound task, which uses all of his 10 time-units.
Next is again the dirtool (which uses again only 1 unit) and so on.
Problem: When the dirtool NEEDS again CPU-time (perhaps 3 time-units
after it gave up control), it has to wait, until the 10 time-units
of the CPU bound task have passed.
Is this correct?
If yes, it is now easy for me to understand, why my Amigas behaves
that way. In this example, the CPU bound task would get up to
10 times more real CPU-time than the dirtool.
Now, the question is: Is there a solution?
Bye,
Thomas
PS: Hmmm, since I heard, AmigaOS can switch hundreds of tasks
per second, this time slice can't be very long, I think...
Iljitsch van Beijnum
: Let's say, a time slice is 10 time-units (just to have something
: to talk about).
: You mean: The directory tool (and the related intuition-task) COULD
: use 10 time-units, but NEEDS only 1 at the moment. So, control
: is given to the CPU bound task, which uses all of his 10 time-units.
: Next is again the dirtool (which uses again only 1 unit) and so on.
: Problem: When the dirtool NEEDS again CPU-time (perhaps 3 time-units
: after it gave up control), it has to wait, until the 10 time-units
: of the CPU bound task have passed.
: Is this correct?
Not completely. The dirutil can't say "I only want 1 time unit per time
slice", it can only start using time units. If it has equal priority as
some CPU hog, that means both get the same amount of CPU usage.
But now:
The CPU hog is still going strong, but the dirutil wants to read 500
directory entries. Reading 1 directory entry takes 1 time unit for the
file system and 1 time unit for the dirutil. So, that makes for 1000 time
units. So you'd expect the dir util to finish in 2000 time units since
the CPU hog gets half of the CPU time.
But what actually happens is:
Dir util tells the file system it wants to read a directory entry. At
that moment the dir util will give up the rest of it's time slice,
because the file system has to do some disk accessing now. The file
system has a very high priority, so it will get the CPU and read the
disk. When it's finished (after 1 time unit) it will give up the CPU
because it doesn't have anything to do. And then it's the CPU hog's turn.
That one will use up all 10 time units after which the dir util gets it's
data from the file system, stores it and asks the file system for the
next directory entry. (1 time unit.) And so on...
This means that out of 12 time units the CPU hog will get 10, so it will
take 6000 time units for the dir util to finish, three times as long as
you'd expect.
: Now, the question is: Is there a solution?
Have the CPU hog run at a lower priority or the dirutil at a higher one.
Iljitsch
Michael van Elst
>doesn't mean anything --- somebody could rename the file.
Isn't that the case in all systems ? :) On other systems
you can even delete files while they are open.
Christian Stieber
> >doesn't mean anything --- somebody could rename the file.
> Isn't that the case in all systems ? :) On other systems
> you can even delete files while they are open.
UNix? The file is still there. It just doesn't have a name anymore.
Maybe the example wasn't very good. Consider setting protection bits
on new files (most amiga programs don't do that, and I really hate that).
They fixed some things in 2.0 --- they finally added ExamineFH(), for
example. But that means there's duplicate functionality, which is
something I personally don't like very much.
Also, there is no mechanism that lets you create a temporary file ---
no matter what filename you choose, you can always kill an important
file.
Btw, "other" operating systems (or, more specifically, their dos part)
may have problems, too. That doesn't mean that every dos must implement
the problems, just because other OSes have them.
Thomas Boerkel
Iljitsch van Beijnum wrote:
IvB> : Let's say, a time slice is 10 time-units (just to have something :
IvB> to talk about).
IvB> : You mean: The directory tool (and the related intuition-task) COULD
IvB> : use 10 time-units, but NEEDS only 1 at the moment. So, control : is
IvB> given to the CPU bound task, which uses all of his 10 time-units. :
IvB> Next is again the dirtool (which uses again only 1 unit) and so on.
IvB> : Problem: When the dirtool NEEDS again CPU-time (perhaps 3
IvB> time-units : after it gave up control), it has to wait, until the 10
IvB> time-units : of the CPU bound task have passed.
IvB> : Is this correct?
IvB> Not completely. The dirutil can't say "I only want 1 time unit per
IvB> time slice", it can only start using time units. If it has equal
IvB> priority as some CPU hog, that means both get the same amount of CPU
IvB> usage.
That's what I wanted to say. :-) Actually I had the scrolling of
the ListViews of the dirutil in mind and not disk access.
During scrolling, the dirutil would scroll one entry up and
then wait some time (otherwise scrolling would be too fast
for our eyes). Because of this, it would give up cpu-control
during its time slice (before the end of its slice).
IvB> But what actually happens is:
IvB> Dir util tells the file system it wants to read a directory entry. At
IvB> that moment the dir util will give up the rest of it's time slice,
IvB> because the file system has to do some disk accessing now. The file
IvB> system has a very high priority, so it will get the CPU and read the
IvB> disk. When it's finished (after 1 time unit) it will give up the CPU
IvB> because it doesn't have anything to do. And then it's the CPU hog's
IvB> turn. That one will use up all 10 time units after which the dir util
IvB> gets it's data from the file system, stores it and asks the file
IvB> system for the next directory entry. (1 time unit.) And so on...
Yes, I understand. That case seems to be the same, as the scrolling
case. The problem is, that the dirutil can't "store" and "restore"
unused time units.
IvB> : Now, the question is: Is there a solution?
IvB> Have the CPU hog run at a lower priority or the dirutil at a higher
IvB> one.
Seems to be the only solution, hmm?
But it is a bit annoying sometimes, to have to change task-priorities
while working. For example, while printing, FinalWriter should have
-1 and while entering text: 0. SID2 should have normally a pri of
0, but if a CPU hog is running, it should have 1.
Bye,
Thomas
Niels Keurentjes
> sti...@Informatik.TU-Muenchen.DE (Christian Stieber) writes:
>
> >doesn't mean anything --- somebody could rename the file.
>
> Isn't that the case in all systems ? :) On other systems
> you can even delete files while they are open.
Well, well genius, the reason you can't delete open files on Amiga's is that
it's a multitasking computer. Who knows what might happen if a task starts
writing in a file another task has just deleted? Yes, flashing lights, guru,
validating harddisk and most probably lost data. ):-(
Niels
Michael van Elst
>Well, well genius, the reason you can't delete open files on Amiga's is that
>it's a multitasking computer.
Oh. Tell that to the other multitasking computers in the world. :)
With UNIX you can delete a file while it is open. The process that
has the file open can still access the data but there is no more
directory entry. As soon as the file is closed the disk blocks used
are freed.
It needs special effort to block other tasks from accessing the file.
>Who knows what might happen if a task starts
>writing in a file another task has just deleted? Yes, flashing lights, guru,
>validating harddisk and most probably lost data. ):-(
Why ?
Lauri Aalto
> Hm, when I run the "PS" program it says "quantum size 4 msec" or "quantum
> size 2 mseq" (seems to depend on the number of tasks) on my 1200 or 3000.
AFAIK, they're not milliseconds but ticks. A tick was a VBlank (1/25 or
1/30 sec) with versions 1.x of the AmigaOS and default SysBase->Quantum
value was two. With the current versions of the OS the default Quantum
value is 4, I don't actually know about the tick duration, but it's
certainly shorter than a vblank..
--
(__) Lauri Aalto <lauri...@fipnet.fi>
w \@@/ Pronssitie 10, FIN-90250 Oulu, Finland
`/v/-e Tel. +358-81-330434
_/ \_ ...Intel inside--idiot outside...
Matthew Gumbley
: In article <3ldqlc$p...@serpens.rhein.de> mle...@serpens.rhein.de (Michael van Elst) writes:
: > sti...@Informatik.TU-Muenchen.DE (Christian Stieber) writes:
: >
: > >doesn't mean anything --- somebody could rename the file.
: >
: > Isn't that the case in all systems ? :) On other systems
: > you can even delete files while they are open.
: Well, well genius, the reason you can't delete open files on Amiga's is that
: it's a multitasking computer. Who knows what might happen if a task starts
: writing in a file another task has just deleted? Yes, flashing lights, guru,
: validating harddisk and most probably lost data. ):-(
On UNIX systems, if you delete a file that is open, the directory entry
gets removed, but not the actual data. The data gets removed when the last
program with the file open closes it. This is one way of implemeting
temporary files - not a terribly neat one, because not all filesystems
handle this action of deleting an open file in the same way. For instance,
if you're deleting an open file on an NFS filsystem, the file gets renamed
to .nfs923423437 or some such name, which has to get tidied up. This causes
a major headache if UNIX is paging in from an executable on an NFS
partition, and you delete it. There's no locking on open executables, so
the pager goes crazy. Great.
[I recommend "The UNIX-HATERS handbook" for more information on this
system. The technique is pronounced "klooj".]
So, you can delete open files in a multitasking OS, you just keep all the
data available for access by the tasks which have the file open, but
disallow any further opens to the file, by deleting it's directory.
--
Matt Gumbley a.k.a. u2...@keele.ac.uk Computer Science, Keele University
It don't mean a thing, if it ain't got that je ne sais quoi.
Iljitsch van Beijnum
Thomas Boerkel (Thomas_Boerkel@amiga_inside2.schiele-ct.de) wrote:
: IvB> Not completely. The dirutil can't say "I only want 1 time unit per
: IvB> time slice", it can only start using time units. If it has equal
: IvB> priority as some CPU hog, that means both get the same amount of CPU
: IvB> usage.
: That's what I wanted to say. :-) Actually I had the scrolling of
: the ListViews of the dirutil in mind and not disk access.
: During scrolling, the dirutil would scroll one entry up and
: then wait some time (otherwise scrolling would be too fast
: for our eyes). Because of this, it would give up cpu-control
: during its time slice (before the end of its slice).
Well, this _could_ work out satisfactory. Say if the dirutil needs 5 time
units to scroll a line, but the programmer only wants it to scroll a line
every 10 time units. So if he or she starts a timer for 10 time units,
then scrolls and then sleeps until the timer expires. That way, you will
never scroll too fast. But if the programmer only starts the timer when
the scrolling is done, you still have problems...
: Yes, I understand. That case seems to be the same, as the scrolling
: case. The problem is, that the dirutil can't "store" and "restore"
: unused time units.
Yes, it can only give away, it doesn't get anything back for that when it
needs the CPU.
: IvB> Have the CPU hog run at a lower priority or the dirutil at a higher
: IvB> one.
: Seems to be the only solution, hmm?
: But it is a bit annoying sometimes, to have to change task-priorities
: while working. For example, while printing, FinalWriter should have
: -1 and while entering text: 0. SID2 should have normally a pri of
: 0, but if a CPU hog is running, it should have 1.
There is a program called "Steamy Windows" that makes that the active
window run at a priority a bit higher than it normally runs. I think this
is what you need.
It's on Aminet in util/cdity as SteamyWindows.lha
Procyon
[snip]
:Dir util tells the file system it wants to read a directory entry. At
:that moment the dir util will give up the rest of it's time slice,
:because the file system has to do some disk accessing now. The file
:system has a very high priority, so it will get the CPU and read the
:disk. When it's finished (after 1 time unit) it will give up the CPU
:because it doesn't have anything to do. And then it's the CPU hog's turn.
:That one will use up all 10 time units after which the dir util gets it's
:data from the file system, stores it and asks the file system for the
:This means that out of 12 time units the CPU hog will get 10, so it will
:you'd expect.
:
:
:Have the CPU hog run at a lower priority or the dirutil at a higher one.
Alternativately, greedy processes get punished. If they steal too much
too long will their priority decrease and leave more room for others.
The problem is that OS processes (filesystems, I/O, etc) should not
be punished, but these processes are usually given a quite high
priority at start, so if we only pay attention to processes with
'normal' priority (-5 to 5 in AmigaOS) and promote/punish these
can the system behave good under normal conditions. The normal
user shouldn't raise/lower priority out of these bounds, at least
not if he is not familiar with the consequences of it.
If I now start a long time work (like raytracing) and it start off att
a initially high pritority will it's performance fade when it get older
(since it's greedy). This effect must in some way be handled. The
'fading' could only take effect if processes within the normal bounds
is competing for the CPU, and there's no competition could it be
given some more priority, until something else enters.
In this manner should it be possible to use the machine even if
something is busy-waiting. For example start some system monitor
to kill the CPU hog, without waiting for hours.
It should be possible to recognize CPU-hogs be looking at how long
time has passed since it didn't use up all it's CPU-quota. New
processes would then get a high initial priority, which means
fast responses.
/Henrik : hwe...@hermes.hv.se
x/|\x
((`- -')) "Hacking on sandman's door..."
__.oOo.__(_)__.oOo.__
John Hendrikx
MVE> nob...@sandman.iaehv.nl (Niels Keurentjes) writes:Well, well genius,
MVE> the reason you can't delete open files on Amiga's is thatit's a
MVE> multitasking computer.
MVE> Oh. Tell that to the other multitasking computers in the world. :)
MVE> With UNIX you can delete a file while it is open. The process that has
MVE> the file open can still access the data but there is no more directory
MVE> entry. As soon as the file is closed the disk blocks used are freed.
MVE> It needs special effort to block other tasks from accessing the file.
Well, IMHO it is a good thing that you can't delete a file if it is in use by
another task. Accessing a file should have priority over Deleting a file.
I think the FFS filesystem does this pretty well, although there are some
flaws. For example, while reading a dir with a directory utility
(Examine/ExNext) you can delete that same dir with another directory utility.
The program reading the dir will however continue scanning the dir (using
blocks which are marked free by the FileSystem), even though the entire dir
doesn't exist anymore. If you write some files to that same device during the
dir-reading then you get a nice crash.
Grtz John
-- Via Xenolink 1.95, XenolinkUUCP 1.1
Michael van Elst
>priority at start, so if we only pay attention to processes with
>'normal' priority (-5 to 5 in AmigaOS) and promote/punish these
>can the system behave good under normal conditions.
Yes. But I'd suggest that 'normal' process are more in the -100..0
range. Positive priorities are already in the 'important' area
such as the workbench task or device drivers (at pri 5).
The Famous Brett Watson
[deletia]
>If yes, it is now easy for me to understand, why my Amigas behaves
>that way. In this example, the CPU bound task would get up to
>10 times more real CPU-time than the dirtool.
>Now, the question is: Is there a solution?
The general solution to this kind of problem is to change the
priority of the various tasks. The Amiga doesn't have an impressive
array of software for automatically handling this kind of thing, but
it has enough to do a reasonable manual job. Some programs allow you
to select a priority for their cpu-intense parts, some lower their
priority automatically. If a cpu-intense program (archiver, renderer,
etc) is operating in the background, lower its priority to -1 (minus
one). This will put it at a lower priority than your interactive (user
bound) tasks such as directory tools, terminal emulations etc.
When the interactive program is running at a higher priority than the
cpu-intense one, it (a) gets the CPU for as long as it needs while the
cpu-intense program waits and (b) preempts the cpu-intense program as
soon as it has something to do again.
This simple procedure has startling results, I promise. It's a pity
that there aren't more conventions for programs to chose their own
priority.
--
/ The Famous Brett Watson <br...@abc.gov.au> x=sin(t), y=cos(3t) \
/ Small fish in the pond at the Australian Broadcasting Corporation. \
\ ~ No PGP key, no WWW home page, so un-hip it's a wonder that my bu ~ /
\ Disclaimer: The ABC thinks I'm mad - I have pay slips to prove it. /
Iljitsch van Beijnum
: [I recommend "The UNIX-HATERS handbook" for more information on this
: system. The technique is pronounced "klooj".]
Hey! I want that. Where can I find it? ;-)
Iljitsch van Beijnum
: :Have the CPU hog run at a lower priority or the dirutil at a higher one.
: Alternativately, greedy processes get punished. If they steal too much
: too long will their priority decrease and leave more room for others.
: The problem is that OS processes (filesystems, I/O, etc) should not
: If I now start a long time work (like raytracing) and it start off att
: a initially high pritority will it's performance fade when it get older
: (since it's greedy). This effect must in some way be handled. The
: 'fading' could only take effect if processes within the normal bounds
: is competing for the CPU, and there's no competition could it be
: given some more priority, until something else enters.
I can see where you're coming from, but is all of this really necessary?
Building a little something into the raytracer that will make it render
at a slightly lower priority will be just as good. Or using a commodity
like Steamy Windows.
The trouble is, that when you build this into the OS it will be more
complex, larger and slower. Hardly the road we want AmigaOS to take.
I see more in a change in the file system so that it will take into
account the priority of the taks doing the disk requests. That way my BBS
won't become dog-slow when the mail is handled, while leaving the CPU
virtually idle.
Iljitsch van Beijnum
: >priority at start, so if we only pay attention to processes with
: >'normal' priority (-5 to 5 in AmigaOS) and promote/punish these
: >can the system behave good under normal conditions.
: Yes. But I'd suggest that 'normal' process are more in the -100..0
: range. Positive priorities are already in the 'important' area
: such as the workbench task or device drivers (at pri 5).
I'd say 1 - 4 are "normal" too. For instance, I use 2 for TrapDoor
(Fidonet mailer) so it has a slightly higher priority than the workbench
and certainly a higher priority than any tasks with the default priority
of 0.
Michael van Elst
>Well, IMHO it is a good thing that you can't delete a file if it is in use by
>another task. Accessing a file should have priority over Deleting a file.
Well, the UNIX approach solves both. But the question was that a
multitasking computer would crash when you delete a file in use which
isn't true.
>The program reading the dir will however continue scanning the dir (using
>blocks which are marked free by the FileSystem), even though the entire dir
>doesn't exist anymore. If you write some files to that same device during the
>dir-reading then you get a nice crash.
That's one of the problems of the FFS, but it is, if you think about it,
a bug in the implementation. The new FFS versions do not crash anymore
but the ExNext operation might fail or not show all files.
James Cooper
In article <aalto...@spit.fipnet.fi>, aa...@spit.fipnet.fi (Lauri Aalto) writes:
>Mere mortals! Listen in awe as Iljitsch van Beijnum speaks:
>> Hm, when I run the "PS" program it says "quantum size 4 msec" or "quantum
>> size 2 mseq" (seems to depend on the number of tasks) on my 1200 or 3000.
>
>AFAIK, they're not milliseconds but ticks. A tick was a VBlank (1/25 or
>1/30 sec) with versions 1.x of the AmigaOS and default SysBase->Quantum
>value was two. With the current versions of the OS the default Quantum
>value is 4, I don't actually know about the tick duration, but it's
>certainly shorter than a vblank..
From <dos/dos.h>:
-----------------------------------------------------------------------
#define TICKS_PER_SECOND 50 /* Number of ticks in one second */
-----------------------------------------------------------------------
So, 1/50 = 0.02 == 20 Milliseconds, times 4 == 80 Milliseconds/Quantum
--
---------------
Jim Cooper
(ja...@unx.sas.com) bix: jcooper
Any opinions expressed herein are mine (Mine, all mine! Ha, ha, ha!),
and not necessarily those of my employer.
"That's me alright. Roadkill on the Information Superhighway."
Marc Espie
Check your facts !!!
In article <3lus96$s...@serpens.rhein.de>,
Michael van Elst <mle...@serpens.rhein.de> wrote:
>
>>How about tasks that have an handle for the file, which is their OWN handle,
>>in their OWN memory, and which contains references to data blocks and index
>>blocks? Guess what, they write to the file, write to block X, block X was
>>just taken by another task, tasks conflict, get wrong data, so you have
>>your 2 hanging tasks, your lost data (both files are lost!), and since you
>>left two files open during crashing the HD will indeed validate itself.
>
>Does not happen. Besides, the UNIX filesystem has no 'validator'.
What is fsck in that case ? Ever seen an unix box that crashed boot up ?
(Yes, unix does crash from time to time. And anyway, I don't know about any
system that can survive power failure)
Minor nitpick maybe... oh, well. What the heck, this is a flamewar, isn't it ?
--
[nosave]<http://acacia.ens.fr:8080/home/espie/index.html>
`Ayuka no koto... suki dayo.' (KOR, Ano Hi ni kaeritai)
`鮎川 のことー好きだよ。' (あの日に帰りたい)
Marc Espie (Marc....@ens.fr)
Erik van Roode
>Check your facts !!!
>In article <3lus96$s...@serpens.rhein.de>,
>Michael van Elst <mle...@serpens.rhein.de> wrote:
>>
>>>How about tasks that have an handle for the file, which is their OWN handle,
>>>in their OWN memory, and which contains references to data blocks and index
>>>blocks? Guess what, they write to the file, write to block X, block X was
>>>just taken by another task, tasks conflict, get wrong data, so you have
>>>your 2 hanging tasks, your lost data (both files are lost!), and since you
>>>left two files open during crashing the HD will indeed validate itself.
>>
>>Does not happen. Besides, the UNIX filesystem has no 'validator'.
>What is fsck in that case ? Ever seen an unix box that crashed boot up ?
>(Yes, unix does crash from time to time. And anyway, I don't know about any
>system that can survive power failure)
Yep, when a UNIX machine boots, it does validate file system. Certainly after
a crash, guess it's done after normal reboot too, but I don't see UNIX
machines being rebooted that often. Uptimes > 60 days are not rare.
Erik
--
Erik van Roode Q : Did you ever use MSDOS ?
University of Amsterdam A : Yes, but I did not inhale !
Dept. of Computer Science
Email: ro...@fwi.uva.nl
Matthias Fleischer
>
>Is it ?
>
Probably not more stable than ANY other OS. But if somebody plugs the power
off I hope for you that you don't run a Un*x box or any other system
with a write cache for the HD :-).
>
>Does not happen. Besides, the UNIX filesystem has no 'validator'.
>
Matthias
--
Ever noticed that %=0/0=NaN?
Th.Huber
>In article <3lus96$s...@serpens.rhein.de>,
>>Does not happen. Besides, the UNIX filesystem has no 'validator'.
>>
>It has a 'filesystem check'.
Funny joke.... But something like file-locks must be missing then.
Never tried to edit a file someone else is getting by FTP right now ?
(Very funny, all .ZIP archives seemes to contain rubbish..)
In my opinion Unix is the most Beta system there is.But it`s called safe
and professional, just because it`s used on big machines.
bye
Maxwell Daymon
: >Probably not more stable than ANY other OS. But if somebody plugs the power
: >off I hope for you that you don't run a Un*x box or any other system
: >with a write cache for the HD :-).
Use a UPS. Better yet, get a network UPS and see about hooking it up
through AmiTCP. Then not only does a power loss not affect your machine,
but your machine is NOTIFIED when power loss occurs and finishes disk
transactions, spins the drives down, and powers down.
There are even UPS systems that should fit okay inside A2000 and A3000T
models.
I know this isn't what the original thread was about, but it's something
to think about if you DO face such a problem.
: Why ? One of the major improvements of the BSD FFS was to make all
: critical operations (open/close/link/unlink) synchronous. This ensures
: that you can check the filesystem and put it into a valid state easily.
: Data written to files might be lost, but the filesystem will survive the
: power failure.
------------------
Maxwell Daymon
mda...@rmii.com
------------------
Matthias Fleischer
Michael van Elst <mle...@serpens.rhein.de> wrote:
>Why ? One of the major improvements of the BSD FFS was to make all
>critical operations (open/close/link/unlink) synchronous. This ensures
>that you can check the filesystem and put it into a valid state easily.
>Data written to files might be lost, but the filesystem will survive the
>power failure.
I know (from my own expiriences with SUNOS, a BSD derivative) that this
policy is even more dangerous than just caching everything. Instead
of a currupted directory tree (a filesystem check can remove this easily)
you get corrupted files without even knowing it and suddenly find
parts of other people's files where they don't belong.
This can raise big security holes you don't even know about.
>You can't say that for the Amiga filesystem. There are some critical
>operations that put the disk in an invalid state and the 'validator'
>does not even detect them (or is started at all because the disk is
>still marked as valid).
True. You can currupt any filesystem (especially when crashing the
machine while writing). The point is that the filesystem of my amiga
survives many crashes per week (I'm a programmer, you know) - and this
for years. While the filesystem of our SUN didn't even survive the first
crash after 3 months running constantly.
Now tell me what is more crash-resistant.