Welcome, Guest. Please login or register.

Author Topic: LimpidClock 68k - a clock cycle eater?  (Read 3277 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Daedalus

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 893
    • Show all replies
    • http://www.robthenerd.com
Re: LimpidClock 68k - a clock cycle eater?
« on: March 27, 2012, 10:44:57 AM »
As Bloodline said, set it to a much lower priority so that absolutely everything gets preferential treatment from Exec. Yes, it'll use CPU cycles, but only if another application doesn't need them. As soon as one does, LimpidClock will just stop working.

I don't see a problem with something using CPU cycles that nothing else needs.

Think of it how things like how Windows etc. treat memory: if the CPU is idle, then it's wasted. You can't throttle back the 68060, it's going to do however many cycles per second, regardless of whether you use them or not. Personally I think the full grunt of any CPU should be thrown at every task in order to get it done as quickly as possible, so you should really be getting extremely small spikes of 100% CPU usage... Actually, just thinking about it that's probably what's happening, just averaged out over a second or so to 1.5%...
Engineers do it with precision
--
http://www.robthenerd.com
 

Offline Daedalus

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 893
    • Show all replies
    • http://www.robthenerd.com
Re: LimpidClock 68k - a clock cycle eater?
« Reply #1 on: March 27, 2012, 01:19:03 PM »
Quote from: ChaosLord;685628

* BUG: Limpid Clock priority is way to high!  It kicks in every 2
seconds and steals all cpu power for .5 seconds.  It totally ruins the
quadrascopes of Total Chaos! :(
* SOLUTION:  Set LimpidClock priority to -128.  And please ask
  LimpidCLock coder to please please user timer.device and wait for 60
  seconds at a time.  Thank you.  I see no need for LimpidClock task to
  wake up in a panic every 2 seconds.  

-------------------------

After filing above bug report all that immediately happened was they set Pri = -20


LimpidClock can be configured to display the time including seconds, so it's reasonable for it to require CPU cycles every second in order to redraw the face. And given that it uses "fake" transparency, redrawing the clock face might actually be expensive on CPU time. Setting it to a low priority should sort it out though - per-second updates probably aren't critical when you're running something that requires lots of CPU time.
Engineers do it with precision
--
http://www.robthenerd.com
 

Offline Daedalus

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 893
    • Show all replies
    • http://www.robthenerd.com
Re: LimpidClock 68k - a clock cycle eater?
« Reply #2 on: March 27, 2012, 10:30:16 PM »
Quote from: paul1981;685714
Thank you all for some insight there.  I've just done some more tests.
I've found that if you use a bigger font for the calender (ie the window gets larger) then it eats more CPU than a smaller font (smaller window).
With a large font (size 20 something) it eats up to 5% of my CPU if the clock face is displayed as well.

Probably to do with the area which is being redrawn - larger fonts mean more pixels of transparency to render. You might get a similar effect with a larger face area too...

Quote

Earlier when I said the priority defaulted at -20, it doesn't (I apologise, I don't know where that came from) it actually defaults to +1.  Anyway, the priority doesn't seem to make any difference.


You see, I don't think you quite understand how the priority thing works with respect to CPU time. If a task needs 5% of the CPU time to run, and 5% is available, then it gets 5%, regardless of priority. Simple as that. In your case, nearly 100% of the CPU time is available, a task needs 5% and so it gets its 5%. Where priorities come into play is when there isn't enough CPU time available for every task. In these cases, higher priority tasks get more of the CPU time at the expense of lower priority tasks. But in your case, there's plenty of CPU time for every task with heaps to spare, so why can't every task have all it wants, e.g. 5%?

(That's a little simplified, but it gets the point across)

Quote

The strange thing is I did a real test rendering a Vista scene and it didn't appear to impact on the rendering time at all.  Maybe that's Executive doing it's magic?  Or maybe it's not really using 1.5% - 5% and it's a fake reading?  Or a misleading reading?


Executive is very good at redistributing CPU time across tasks, but it can't magically make more of them. What I suspect is happening here is that the Vista rendering process runs at a higher priority than LimpidClock, meaning that if it needs 100%, it pretty much gets 100%. The 5% that the clock needs is reallocated to Vista, so you should see the seconds skip sometimes or some similar effect. Executive might prevent this from happening by rationing LimpidClock some cycles (less than 5%) which gives a smoother overall experience at very little cost to Vista.

Quote

How does LimpidClock affect slower systems such as 020/030?  Is anyone using it on those configurations?


I run it here on an 030/50 and AGA. I run it at -20 IIRC, and it's never had any issues. I haven't measured how much CPU time it uses but it doesn't matter since whenever anything else needs those cycles, it gets them instead of the clock...
Engineers do it with precision
--
http://www.robthenerd.com
 

Offline Daedalus

  • Hero Member
  • *****
  • Join Date: Feb 2002
  • Posts: 893
    • Show all replies
    • http://www.robthenerd.com
Re: LimpidClock 68k - a clock cycle eater?
« Reply #3 on: March 28, 2012, 12:06:46 AM »
Yeah, I'm sure there are better ways of doing it - perhaps without faking the transparency it might be more efficient, or maybe run some lookup tables or a different timing mechanism (I don't know how it works internally). But I also think that if it doesn't actually cause any measurable problem, then it's grand...

As for the priorities, I've no doubt it would have bad effects alright - might even try it some day for a giggle and see how it gets on ;)
Engineers do it with precision
--
http://www.robthenerd.com