Linked by Thom Holwerda on Wed 3rd Oct 2007 06:44 UTC
Amiga & AROS Bill McEwen of Amiga, Inc. writes in a public letter: "Over the last several months and in fact couple of years, Amiga has continued our software and business development and generally kept quiet. This path of quietness was chosen so that we communicated only when there was a development that culminated in a product that could be purchased. In recent weeks, our being quiet has been interpreted as weakness or an open invitation to attempt harming our business relationships and opportunities with partners and customers."
Thread beginning with comment 276584
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Why?
by makfu on Sun 7th Oct 2007 07:17 UTC in reply to "RE[10]: Why?"
makfu
Member since:
2005-12-18

"Even simple infinite loop with normal priority will almost completely block the NT/W2k. Even mouse cursor will move jerkily. Actually RESET button saved a lot of my nerves"

Okay, let’s examine why your statement is incorrect. First we will define the two common scenarios were the AmigaOS Exec’s scheduler can get in trouble:

1. Large number of concurrent tasks (units of execution or threads in NT) consuming large amounts of CPU time

2. One or more tasks consuming large amounts of CPU time at a higher priority

Now, let’s examine number one and take a look at a screenshot ( http://i20.tinypic.com/303bczs.jpg ) of two extremely CPU intensive processes on NT (in this case Vista RTM running on a 3 ˝ year old socket 478 uniprocessor Pentium 4 Prescott 3.2Ghz). In this screenshot you can see one has launched a 256 worker threads while the other has just two. In all cases these are basically just loops performing basic integer math. This screenshot illustrates that even with a very large number of CPU intensive threads, the scheduler is distributing CPU time and that even the sidebar, for example, is getting CPU cycles. Clearly, your statement that a simple loop at normal priority can bring the system to its knees is patently false.

Now, as to WHY dynamic priorities are important; in the second screenshot ( http://i22.tinypic.com/2vvw02e.jpg ) I have actually displayed the individual threads in the heavily threaded process to illustrate that in order to make sure that the threads are not starved, the scheduler dynamically boosts their priority. In screenshot 3 (http://i22.tinypic.com/vfbk45.jpg ), you can see that even if the process is set to run at lowest base priority class (4) while the second CPU intensive process is running full tilt two classes above it (8) to make sure that threads still making some forward progress, the scheduler boosted the priority of the circled thread all the way to the high priority class at level 15. Additional scenarios also apply for interactive threads (threads waiting on input events like mouse and keyboard events are given significant boosts of up to 6 levels in priority upon that event occurring and waking up the thread). As the thread executes, for each full quantum, its priority will decay by 1 level so eventually it will return to its base priority. Furthermore, in NT 6, the actual process quantum accounting is now cycle exact, not clock based (and ISR/DPC time is not counted against a threads quantum).

Now, in the case of the AmigaOS Exec, because it is a simple round-robin scheduler, it is possible to bring the system to its knees by simply spawning a large number of CPU intensive tasks thus flooding the scheduler. Since no mechanism exists to boost priority for either interactive threads waking on an important event or those that are starved, getting to the point of unrecoverable responsiveness while everything is at the same default priority is fully possible (not the case as demonstrated here). Furthermore, even more effective is to launch a task with a priority of over say +64 and you will effectively gain the same effect. In fairness, there was an add on extension to AmigaOS called Executive that provided a policy based feedback loop to dynamically mange scheduling and the NT scheduler has a “realtime” priority class that can be used to monopolize the system since priority boosting never crosses the threshold into realtime priorities (24-32) (standard linux scheduler also had similar functionality, though this may have changed with CFS).

Regardless, scheduling in NT is much more advanced that the default AmigaOS Exec scheduler and no, not even 258 instances of a “simple loop” cpu intensive threads running at normal priority will bring the machine to its knees, as demonstrated in the provided screenshots (you might notice that even my dynamic wallpaper continued to update while I documented my assertions). By the way, the most common cause of a jumpy mouse cursor and poor responsiveness is the result of the cpu spending lots of time in a driver ISR at an IRQL higher than the mouse thus masking out the servicing of the lower priority interrupts, and subsequent ISR’s/DPC’s, as well as normal thread scheduling. This is usually due to either an incredibly bad bit of driver coding or failing hardware.

Reply Parent Score: 1

RE[12]: Why?
by Downix on Sun 7th Oct 2007 17:20 in reply to "RE[11]: Why?"
Downix Member since:
2007-08-21

-------------------------------------------------
"Even simple infinite loop with normal priority will almost completely block the NT/W2k. Even mouse cursor will move jerkily. Actually RESET button saved a lot of my nerves"

Okay, let’s examine why your statement is incorrect. First we will define the two common scenarios were the AmigaOS Exec’s scheduler can get in trouble:
-------------------------------------------------

This arguement is off-topic and pointless in this case, as the Amiga's mouse system and NT's are two different beasties. The Amiga's will continue to run when the rest of the OS is locked up not due to some miraculous scheduler, but becaue of the custom hardware, which is what actually drives the mouse pointer. The chipset gave the Amiga this ability, not the OS.

Reply Parent Score: 1

RE[13]: Why?
by makfu on Sun 7th Oct 2007 21:23 in reply to "RE[12]: Why?"
makfu Member since:
2005-12-18

"This arguement is off-topic and pointless in this case, as the Amiga's mouse system and NT's are two different beasties. The Amiga's will continue to run when the rest of the OS is locked up not due to some miraculous scheduler, but becaue of the custom hardware, which is what actually drives the mouse pointer. The chipset gave the Amiga this ability, not the OS."

My point was about the effectiveness of the NT and Amiga schedulers and a direct reply to blatant unsubstantiated FUD regarding responsiveness. That I addressed why the cursor on an NT box (same is true for other OS’s on conventional PC hardware) can become “jumpy” was an addendum at the end of the post. The post was not about device interrupt handling or how the mouse cursor gets drawn to the screen.

Reply Parent Score: 1

RE[12]: Why?
by viton on Sun 7th Oct 2007 23:52 in reply to "RE[11]: Why?"
viton Member since:
2005-08-09

Clearly, your statement that a simple loop at normal priority can bring the system to its knees is patently false.
I have experienced it several times in W2k in MY programs (1 thread, windowed directx).

Edited 2007-10-07 23:55

Reply Parent Score: 1

RE[13]: Why?
by makfu on Mon 8th Oct 2007 05:27 in reply to "RE[12]: Why?"
makfu Member since:
2005-12-18

"I have experienced it several times in W2k in MY programs (1 thread, windowed directx)."

Anecdotes don’t cut it; I want you to prove it. I want the binary for this single threaded, windowed directx app that, when running at normal priority, will elicit the behavior you are describing.

Reply Parent Score: 1