LimpidClock 68k - a clock cycle eater?

[paul1981]

I finally got around to spicing up my A1200's Workbench towards the end of last year, and I've almost finished and got everything how I like it (although things can always improve or change) but anyway, although I love the look and functionality of LimpidClock, it appears that it eats 1.5% of my CPU. So as of yet I'm not prepared to use it.
It's eating 1.5% even with the clock face removed (all I actually wanted it for was the calender) - so basically, it's sitting there on an 8 colour Workbench screen (yes, MWB!) and it's doing nothing but displaying a calander and despite this it's eating a lot of clock cycles (no pun intended) haha.

Now I think I know the reason why the default task priority is set to -20 on this program...

To me, it's unacceptible as I'm running an 060 at 66MHz.
Without LimpidClock running I get idle states of 0.2%-0.4%, then with it I get an idle state of 2% or more.
I've confirmed this with Scout, and Executive CPU Meters.

I've fiddled with all available options in the menu, and nothing seems to make any difference (other than getting rid of the clock face which I have already done...as with it enabled it eats even more of my CPU).

Does anyone know of a similar type of calander program that I can use instead of this (has to look good, be transparent etc). Or, does anyone know why it's so CPU heavy, or a possible solution?  I thought maybe it's doing transparency calculations or something, but that's not needed is it because I'm running AGA, not a 16 or 24 bit screen...

Any thoughts? Cheers...

[ChaosLord]

I have used LimpidClock for years.  Yes it is not programmed quite right and wastes huge amounts of cpu power

It has been this way for years, sadly

The only solution is to remove LimpidClock.

[bloodline]

Why not set it to -120 priority (or even lower if you are feeling fruity), that way almost everything on your system will block it from executing.

-Edit- just thought, it would be trivial to write a calendar app yourself... You could do it in BlitzBasic in a few minutes and set it to only update once every hour or something

[Daedalus]

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%...

[bloodline]

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%...

Yeah, as far as I know the 060 doesn't really have much in the way of power saving features, and certainly none that would be upset with 1.5% load... Just set the priority super low and be happy

[ChaosLord]

Originally LimpidClock was set to priority 0 in AmikitOS.

This was messing up the quadrascopes in TotalChaosAGA which run at priority -5

So I filed the following bug report (dug up out of my archives):

April 23, 2008:
Team Chaos presents:

A bug report AmiKitOS vs. Total Chaos AGA


* 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

[ChaosLord]

More data from my secret archives:

Hi,

I remember it was problem with multiple accessing of ttengine.library.
If two or more programs used it at the same time, crashes may
occurred. In AmiKit, LimpidClock and AmiStarted used ttengine at the
same time so I had to replace LimpidClock with no ttengine version.

Regards,
Jan

Jan spent years trying to get someone to fix ttengine.library but nobody did.

So the bottom line is:
Either don't use LimpidClock or if u insist on using it then use the nottengine version else your system will get corrupted.

[Daedalus]

* 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.

[paul1981]

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.

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.
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?

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

[Daedalus]

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...

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)

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.

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...

[paul1981]

I do know how it works, but I'm just reluctant to use software that  doesn't do it "the Amiga way", which to me has always meant efficiency.
TolleUhr for instance doesn't even nudge my CPU meters...you wouldn't  know it was running.  Shame it doesn't have a calender though.

Let's say for instance, that all the tasks running were eating more CPU  than they should be, let's say you have 40 or 50 tasks (I have 39 tasks  after a clean boot), just imagine if all of these were as inefficient as  LimpidClock...
Yes, I know that the majority of those tasks are waiting and doing  nothing, but I'm just trying to make a point that it's always better to  have better efficiency.

Maybe I'm being tight!  Or Silly even!  Amiga's are not quad cores, we  need efficient software, and I just want to let other Amiga users know  that LimpidClock has a problem.
Maybe Bloodline is right, I'll have to write my own! :crazy:

[paul1981]

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...

Try it on 0 or above, I'd guess your system would slow considerably. Your Amiga may even go backwards!

[Daedalus]

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