GIAMPAL@auvm.auvm.edu (11/08/90)
I've got a semi-simple question about the Scheduler and LoadSeg() under 2.0 of AmigaDOS. There seems to be a difference in the way the system handles a heavy load between 2.0 and 1.3 of the OS. For example, on an A3000, if you start a ray- trace with TurboSilver and pop back to workbench to start up something like DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back to life in little bursts. However, under 1.3 (on the same physical machine), there is no noticeable delay, and DeluxePaint (or anything for that matter) comes up just fine with no delays or jumps in performance (i.e. things run smoother). This type of performance also appears when just doing things like opening an icon on workbench or running other programs. Simply from looking at how things work (and without an 030 disassembler) it appears that either the scheduler has been changed or things like LoadSeg() are quite different. For the most part it looks like system calls are what cause hold ups under 2.0. When DPaint opens its initial screen there are delays of about 1-2 seconds as it opens, whereas under 1.3 of the OS the screen opens instantly. I'm curious to know what the differences are (without spilling _all_ the beans of course :-) Does anyone have a clue on this one? trying for good techie content, --dominic
peter@cbmvax.commodore.com (Peter Cherna) (11/10/90)
In article <90312.082534GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes: >I've got a semi-simple question about the Scheduler and LoadSeg() under >2.0 of AmigaDOS. > >There seems to be a difference in the way the system handles a heavy load >between 2.0 and 1.3 of the OS. For example, on an A3000, if you start a ray- >trace with TurboSilver and pop back to workbench to start up something like >DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back >to life in little bursts. Are you running a utility called "enforcer" when you're under 2.0? It finds certain program bugs and spits error reports out the serial port at 9600 baud -- the machine is suspended during that time. DPaint has a few such reports upon startup. That would explain what you're seeing. >trying for good techie content, >--dominic Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "She read him like a book: she liked to peek at his end."
GIAMPAL@auvm.auvm.edu (11/12/90)
In article <15756@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) says: >In article <90312.082534GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes: >>between 2.0 and 1.3 of the OS. For example, on an A3000, if you start a ray- >>trace with TurboSilver and pop back to workbench to start up something like >>DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back >>to life in little bursts. > >Are you running a utility called "enforcer" when you're under 2.0? Well unless "enforcer" is run in the startup-sequence by default, this isn't the case. The machine had basically been just pulled out of the box and set up. There is definitely something different going on, but I'm not quite sure what (time to buy ReSource '030 and figure out what you guys are doing in there :-) --dominic
amiga@ccwf.cc.utexas.edu (Paul) (11/13/90)
I have had the same problem with my A3000 seeming locked up while comming back in sperts. I seems do do this most of the time when I run D-Paint III. I also noticed you were running D-Paint. I was also running Amiga-Vision when this happend. -- Amiga@ccwf.cc.utexas.edu .....Paul...... Listen to what I mean, not what I say.
rwm@atronx.UUCP (Russell McOrmond) (11/13/90)
In a message posted on 9 Nov 90 16:22:26 GMT,
peter@cbmvax.commodore.com (Peter Cherna) wrote:
PC>Are you running a utility called "enforcer" when you're under 2.0?
PC>It finds certain program bugs and spits error reports out the serial
I asked earlier, and did not get an answer, but this reminded me again. Is
there any way to get the enforcer to 'share' the MMU with the Beta 2.0x
disk based Kickstart? As things are right now, I have to bring up Beta 5
in order to test software - I would very much like to run the enforcer all the
time, and place a terminal on the machine, but this is not an option at the moment,
as there is quite a bit of software that does not work under Beta 5.
Is there a method to run the enforcer under 2.02 BEFORE the ROMS are released?
:Later
---
Opinions expressed in this message are my Own. My Employer does not even
know what these networks ARE.
Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109bj@cbmvax.commodore.com (Brian Jackson) (11/13/90)
In article <39617@ut-emx.uucp> amiga@ccwf.cc.utexas.edu (Paul) writes: >I have had the same problem with my A3000 seeming locked up while comming back >in sperts. I seems do do this most of the time when I run D-Paint III. I also >noticed you were running D-Paint. I was also running Amiga-Vision when this >happend. I had this problem a while back and a bit of research showed the source of the problem to be a/some variant of the McCormick/DeVaughn 'LS' program which would, if asked to do a full, long and sorted listing of a *large* directory ( > 200 files or so ), hose something internal and cause this "spurts" behavior. Only a reboot would fix it. This is not to say that this *is* your problem, just that I was able to create the same symptoms this way. As mentioned before, use of Enforcer can cause this effect if the program in use is doing lots of reads/writes to/from out-of-bounds memory areas. bj >Amiga@ccwf.cc.utexas.edu .....Paul...... ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "Please Captain, not in front of the Klingons." | -----------------------------------------------------------------------
bryce@cbmvax.commodore.com (Bryce Nesbitt) (11/14/90)
In article <53869.658483147> rwm@atronx.UUCP (Russell McOrmond) writes: > >I asked earlier, and did not get an answer, but this reminded me again. Is >there any way to get the enforcer to 'share' the MMU with the Beta 2.0x >disk based Kickstart? Yes. Versions of _The Enforcer_ starting with 2.6 have that ability. NOTE! You should not be using "Beta 2.0x" Kickstarts. Release 2.02 Kickstart is available. As a bonus, the 2.02 A3000 Update Disk contains a copy of Enforcer version 2.6. > Russell McOrmond rwm@atronx.UUCP {fts1,alzabo}!atronx!rwm -- |\_/| . "ACK!, NAK!, EOT!, SOH!" "Lawyers: America's untapped export market." {X o} . Bryce Nesbitt, Operating Systems Group, Commodore-Amiga, Inc. (") BIX: bnesbitt U USENET: bryce@commodore.COM -or- uunet!cbmvax!bryce
bryce@cbmvax.commodore.com (Bryce Nesbitt) (11/14/90)
In article <90312.082534GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes: >I've got a semi-simple question about the Scheduler and LoadSeg() under 2.0... > >For example, on an A3000, if you start a ray- >trace with TurboSilver and pop back to workbench to start up something like >DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back >to life in little bursts. On the A3000 attempts to access illegal memory results in a "Bus Error". (For anything not otherwise filled, the A3000 Hardware asserts _BERR). Each illegal memory access takes 250 milliseconds. Programs like the ones you mention sometimes read/write/trash random areas of memory. Under 1.3 emulation on the A3000, the address space is mapped differently, hiding the feature. The only way to tell for sure would be to get the developer tool called "Enforcer", and check if the pauses are coincident with illegal memory hits. -- |\_/| . "ACK!, NAK!, EOT!, SOH!" "Lawyers: America's untapped export market." {X o} . Bryce Nesbitt, Operating Systems Group, Commodore-Amiga, Inc. (") BIX: bnesbitt U USENET: bryce@commodore.COM -or- uunet!cbmvax!bryce
hclausen@adspdk.UUCP (Henrik Clausen) (11/14/90)
In article <90316.091455GIAMPAL@auvm.auvm.edu>, GIAMPAL@auvm.auvm.edu writes: > > In article <15756@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter > Cherna) says: > >In article <90312.082534GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes: > >>between 2.0 and 1.3 of the OS. For example, on an A3000, if you start a ray- > >>trace with TurboSilver and pop back to workbench to start up something like > >>DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back > >>to life in little bursts. > There is definitely something different going on, but I'm not > quite sure what (time to buy ReSource '030 and figure out what you guys are > doing in there :-) I've found that Intuition under 2.0 seems to execute the OpenWindow() etc. etc. calls with the priority of the caller. If some task is eating away practically all CPU time at a higher priority, the mouse pointer and everything else will hang, though the system is certainly alive. I encounter this mostly when uniconifying my text editor while doing compiles - the OpenScreen() & OpenWindow() calls hang until the compiler accesses the disk, thus freeing up some CPU time. This was different under 1.3. So, it seems to be Intuition rather than the sceduler that has this change. Anyway, Exec wasn't changed much from 1.3 to 2.0 - it did a good job under 1.3 already. Intuition, on the other hand, has had much recoding. BTW, I also use the Kim Vaughan ls (the fixed one), but rarely list more than 200 files in one directory. Have a nice day -Henrik | Henrik Clausen, Graffiti Data | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Do not accept the heart that is the slave to reason" - Qawwali trad__/
GIAMPAL@auvm.auvm.edu (11/14/90)
In article <15822@cbmvax.commodore.com>, bj@cbmvax.commodore.com (Brian Jackson) says: >'LS' program which would, if asked to do a full, long and sorted >listing of a *large* directory ( > 200 files or so ), hose something >internal and cause this "spurts" behavior. Only a reboot would fix it. Any ideas what causes this sort of behavior? I mean how does a program doing something wrong internally (assuming no reads/writes to protected mem) mess up the rest of the system? Are we just talking about someone getting stuck in a tight loop for a little bit (or an infinite loop) and that bogging the system down? Still seems a little strange. BTW, I don't know if you can't talk about it, but no one who would know has said if the scheduler is changed under 2.0 or not. Well....? :-) --dominic
hamilton@intersil.uucp (11/15/90)
In article <90312.082534GIAMPAL@auvm.auvm.edu>, GIAMPAL@auvm.auvm.edu writes: > I've got a semi-simple question about the Scheduler and LoadSeg() under > 2.0 of AmigaDOS. > > There seems to be a difference in the way the system handles a heavy load > between 2.0 and 1.3 of the OS. For example, on an A3000, if you start a ray- > trace with TurboSilver and pop back to workbench to start up something like > DeluxePaint, the entire system _seems_ locked, but then suddenly jumps back > to life in little bursts. However, under 1.3 (on the same physical machine), > there is no noticeable delay, and DeluxePaint (or anything for that matter) > comes up just fine with no delays or jumps in performance (i.e. things run > smoother). This type of performance also appears when just doing things like > opening an icon on workbench or running other programs. I've seen the same thing. I was downloading a file while trying to do something else and the system got *extremely* slow and jerky, and the download kept failing. I was running some program (I can't remember which one now) that was number crunching or rendering or otherwise using every free cycle, but it was running at 0 priority, so I don't know why it would screw-up the inputdevice. -- Fred Hamilton Any views, comments, or ideas expressed here Harris Semiconductor are entirely my own. Even good ones. Santa Clara, CA
peter@cbmvax.commodore.com (Peter Cherna) (11/15/90)
In article <1834c248.ARN04024@adspdk.UUCP> hclausen@adspdk.UUCP writes: > I've found that Intuition under 2.0 seems to execute the OpenWindow() >etc. etc. calls with the priority of the caller. If some task is eating >away practically all CPU time at a higher priority, the mouse pointer and >everything else will hang, though the system is certainly alive. I >encounter this mostly when uniconifying my text editor while doing compiles >- the OpenScreen() & OpenWindow() calls hang until the compiler accesses >the disk, thus freeing up some CPU time. This was different under 1.3. Parts of Intuition run on the caller's task, but much of the interesting stuff runs on the input.device's task, which runs at priority 20. Whenever you call a function, you do start out on your own task of course. In OpenWindow(), for example, most of the checks and allocations happen on your task (some of it must: the message ports for example, must be created on your task, since they allocate signal bits from the running task!). But internally, Intuition is a bit like a device, so OpenWindow() eventually sends a message, which input.device (running as Intuition) picks up, and links your window in on its schedule. Some Intuition calls happen entirely on your task, some happen nearly entirely on input.device's task, and some are divided. Some are synchronous, and some aren't. We arrange things as design and historical constraints dictate. We let you know this information when it is relevant. (For example, after calling ActivateWindow(), your window isn't active until and unless you hear an ACTIVEWINDOW IDCMP message, because ActivateWindow() is asynch. Finally, all the stuff that's asynchronous to the clients of Intuition (such as moving the mouse, rearranging layers, and some refresh) happens on the input.device. > So, it seems to be Intuition rather than the sceduler that has this >change. Anyway, Exec wasn't changed much from 1.3 to 2.0 - it did a good >job under 1.3 already. Intuition, on the other hand, has had much recoding. Although Intuition has undergone substantial changes in 2.0 (thanks jimm!), the basic pattern of splitting the work between the caller and input.device has been in Intuition all along. Note also that the number of changes a module underwent wasn't strictly determined by how good a job or how well it was written. Support for the 2024 and ECS Denise, for example, meant a lot of work for graphics and Intuition. > Have a nice day -Henrik As Bryce mentioned earlier, the delays people have been experiencing are caused by bus errors generated in hardware on the Amiga 3000. The nature of the 1.3 SuperKickstart setup on A3000's allows us to supress these errors. (Each hardware bus error imposes a 1/4 sec pause). Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. I have found a proof for Fermat's theorem, but there is no room in the .sig!
hclausen@adspdk.UUCP (Henrik Clausen) (11/16/90)
In article <15887@cbmvax.commodore.com>, Peter Cherna writes: > Some Intuition calls happen entirely on your task, some happen nearly > entirely on input.device's task, and some are divided. Some are synchronous, > and some aren't. We arrange things as design and historical constraints > dictate. We let you know this information when it is relevant. (For example, > after calling ActivateWindow(), your window isn't active until and unless > you hear an ACTIVEWINDOW IDCMP message, because ActivateWindow() is > asynch. Well, I sortof figured as much. I've just noticed a change in behaviour in that mouse movement (definately a high-priority subject) can be blocked under 2.0 while OpenScreen()/OpenWindow() takes place. I did check that this is a change over 1.3, and I've also made sure that no _Enforcer_ hits take place in that code. > As Bryce mentioned earlier, the delays people have been experiencing > are caused by bus errors generated in hardware on the Amiga 3000. The > nature of the 1.3 SuperKickstart setup on A3000's allows us to supress > these errors. (Each hardware bus error imposes a 1/4 sec pause). These bus errors would be caught by Enforcer, right? I've noticed a few errors of this kind as well, but we're a few people talking about delays that only occur when some task is hogging the CPU at a priority similar to our own task. To be exact, the change I've noticed is that the mouse pointer will block if the lower priority task does an OpenWindow(), until the Window is done. This is the (minor) change I've met. I remember from Paris that the Intuition state machine was completely rewritten, which is far more that happened to Exec. Changes to side effects can be expected and should be identified. Don't get me wrong, Peter, I've done lots of Intuition work over the years, and my respect for those parts is very deep. Have a nice day -Henrik > I have found a proof for Fermat's theorem, but there is no room in the .sig! Fermat's last theorem? You may mail it to me, using the whole page! :-) | Henrik Clausen, Graffiti Data | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Do not accept the heart that is the slave to reason" - Qawwali trad__/
rhialto@cs.kun.nl (Olaf Seibert) (11/16/90)
In article <15887@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >As Bryce mentioned earlier, the delays people have been experiencing >are caused by bus errors generated in hardware on the Amiga 3000. The >nature of the 1.3 SuperKickstart setup on A3000's allows us to supress >these errors. (Each hardware bus error imposes a 1/4 sec pause). Why does it take so long? You must execute an awful lot of code to take 1/4 second. > Peter >I have found a proof for Fermat's theorem, but there is no room in the .sig! I found it too, but I didn't have a margin on this message to scribble it on. -- Olaf 'Rhialto' Seibert rhialto@cs.kun.nl How can you be so stupid if you're identical to me? -Robert Silverberg
waggoner@dtg.nsc.com (Mark Waggoner) (11/17/90)
In article <2455@wn1.sci.kun.nl> rhialto@cs.kun.nl (Olaf Seibert) writes: >In article <15887@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes: >> (Each hardware bus error imposes a 1/4 sec pause). > >Why does it take so long? You must execute an awful lot of code >to take 1/4 second. No code at all gets executed, bus errors are the result of a hardware timeout. The cpu starts a memory access and, after a while, nobody responds and a bus error occurs. At least that's my understanding of the way it works. -- Mark Waggoner Santa Clara, CA (408) 721-6306 waggoner@dtg.nsc.com Unofficially representing National Semiconductor Local Area Networks Group Officially misrepresenting myself.
jesup@cbmvax.commodore.com (Randell Jesup) (11/17/90)
In article <2455@wn1.sci.kun.nl> rhialto@cs.kun.nl (Olaf Seibert) writes: >>these errors. (Each hardware bus error imposes a 1/4 sec pause). > >Why does it take so long? You must execute an awful lot of code >to take 1/4 second. No, that's the hardware Bus Error timeout. It's waiting for an acknowlege of a bus xfer (DSACK/etc). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Thus spake the Master Ninjei: "If your application does not run correctly, do not blame the operating system." (From "The Zen of Programming") ;-)
kim@uts.amdahl.com (Kim E. DeVaughn) (11/17/90)
In article <90318.082800GIAMPAL@auvm.auvm.edu> GIAMPAL@auvm.auvm.edu writes: > > In article <15822@cbmvax.commodore.com>, bj@cbmvax.commodore.com (Brian Jackson) > says: > >'LS' program which would, if asked to do a full, long and sorted > >listing of a *large* directory ( > 200 files or so ), hose something > >internal and cause this "spurts" behavior. Only a reboot would fix it. > > Any ideas what causes this sort of behavior? I mean how does a program > doing something wrong internally (assuming no reads/writes to protected mem) > mess up the rest of the system? Are we just talking about someone getting > stuck in a tight loop for a little bit (or an infinite loop) and that bogging > the system down? Still seems a little strange. Yes, it *is* strange. The "ls" problem was isolated by Henrik Clausen, and found to be due to "something" in the custom startup code (mycres.o). It was eliminated simply by using the standard Lattice cres.o module. I still am not sure exactly *what* in the custom startup code was causing the problem, nor whether it was specifis to a 3000 running 2.0x, or if it showed up on 2x00 machines running 2.0x also (as I don't have either 2.0 or a 3000 yet). There were other manifestations of the problem which didn't cause the "slowdown" symptom, but did result in some other undesirable behavior (hang, crash, etc). My *hunch* is that something in there was trying to access some non-existant memory, and causing endless "bus errors", which would slow the system *way* down, but I can't confirm that suspicion. In any case, the beta version of v4.1k that I have sent to a number of people has eliminated the problems they were experiencing, but I have not yet released it, as I need to use the v5.10 version of cres.o (to fix a potential problem that showed up when a version using the v5.05 cres.o was run under a beta test copy of a 2.0 upgrade to a commercial product). I have v5.10, but haven't installed it yet, as I need to keep v5.05 around for awhile longer for reasons having nothing to do with "ls" (and I don't have the disk space to put up both versions right now). Soon, however. /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
peter@cbmvax.commodore.com (Peter Cherna) (11/20/90)
In article <1837886c.ARN04072@adspdk.UUCP> hclausen@adspdk.UUCP writes: > To be exact, the change I've noticed is that the mouse pointer will >block if the lower priority task does an OpenWindow(), until the Window is >done. This is the (minor) change I've met. I remember from Paris that the >Intuition state machine was completely rewritten, which is far more that >happened to Exec. Changes to side effects can be expected and should be >identified. I don't know how much of OpenWindow() was done on input.device's task under 1.3. There is a reasonable amount of work to be done in 2.0. We try to avoid putting too much burden on the input.device, but it is indeed possible that more stuff uses it. OpenWindow() doesn't seem to do much more than locking the layer_info, and creating the window layer. Most of the rest happens on your schedule. >| Henrik Clausen, Graffiti Data | >| ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. I have found a proof for Fermat's theorem, but there is no room in the .sig!