CPU usage steadily increases

[Colin Edwards]

I have a small program that monitors a camera, edits the image and sends it by FTP every ten minutes.
Almost all of the time it sits in a loop, waiting for the next cycle to start. This loop contains a SLEEP 1000, but the executable still is still using considerable CPU time.

This starts at 2% and over about two days rises until it reaches 100% and the system stops responding.

No other tasks are using anything worth mentioning. The memory usage doesn't change.

PBCC4 XP

Any suggestions please.

[Chris Holbrook]

Any suggestions please.

yes, post compileable source code, a sure step on the way to success!

[Michael Mattias]

Change SLEEP to 10000 and reboot every 20 days; or to 600000 (ten minutes) and reboot every 1200 days. That way you also don't even have to check the clock, because you know it's been ten minutes.

If you only want to "do something" every ten minutes, surely you don't need to check the time every second to see of that ten minutes is up yet, do you? (!!!)


It's probably a waste of time to suggest using a waitable timer object instead of this loop, but on the off-chance......there is a nice demo of same in Source Code Forum (search "waitable'"in subject)

Or set up Windows Scheduler to run program every ten minutes, ending when done.

[Michael Mattias]

Did you CreateProcess/ShellExecuteEx that FTP? Did you close the returned process/thread handles? (I can only assume you closed obvious handles if you did the FTP as demo'd here : WinInet FTP Upload (Overwrite or Append) Demo 3-10-08

[Colin Edwards]

I'm a hardware engineer, so my code isn't clever. I just use PowerBasic it implement designs. (For at least the last 20 years)

This setup uses a digital camera to take a photo every ten minutes, read a HID, write the data to the image and upload the image by FTP.
This is left running for years at a time and to keep the timing exact it is checked against a standard.
The result is here: http://www.playaparaiso.org/cam_fdt002.htm (just my test rig)

The problem is that even during a SLEEP command the .exe is using an ever increasing amount of CPU time.

I was about to put the code here, but suddenly realised that what's changed is the HID interface (joystick) so I unplugged it and the CPU ussage went to near zero.

To read the joystick I use this code. It uses win32api.inc and averages 50 readings. Is there something I'm not terminating?:

   'get temp.
   IF StickA(JS) = 0 THEN
       r$=FORMAT$(JS.dwXpos)
       SLEEP 100
       t1t!=0
       t2t!=0
       tl&=50
       FOR y&=1 TO tl&
          StickA(JS)
          r$=FORMAT$(JS.dwXpos)
          t1!=VAL(r$)
          t1!=t1!/((65535-t1!)/100000)
          t1!=((b0!*298.15)/(b0!-(298.15*LOG(r0!/t1!))))-273.15
          t1t!=t1t!+t1!+toff!
          SLEEP 200
          r$=FORMAT$(JS.dwYpos)
          t2!=VAL(r$)
          t2!=t2!/((65535-t2!)/100000)
          t2!=((b0!*298.15)/(b0!-(298.15*LOG(r0!/t2!))))-273.15
          t2t!=t2t!+t2!+toff!
          SLEEP 200
          ttp$=FORMAT$((t1t!/y&),"0.0")+"C"
          PRINT "Read temp. loop: ";y&;" : ";ttp$;
          LOCATE 0,1
       NEXT
END IF

[Chris Holbrook]

Colin, are you using a single thread? what does StickA() do?

[Colin Edwards]

Colin, are you using a single thread? what does StickA() do?

Thanks Chris

Yes it is a single thread.

As I understand win32api.inc it takes a reading from the joystick, which can then be read as JS.dwXpos etc. As a function it returns an error code if the joystick is not present.

[Jim Padgett]

Scheduled Task?

Why not run your app every 10 minutes via a scheduled task...
Start it up do your stuff then quit.

[Chris Holbrook]

As I understand win32api.inc it takes a reading from the joystick, which can then be read as JS.dwXpos etc

StickA does not exist in my WIN32API.INC so my guess is that you wrote it and it calls API functions... dunno... Have you used PROFILE to determine where your CPU is most used? Would driver CPU show up in your process or elsewhere? Do you have any options regarding drivers? I'm running out of ideas...

BTW does it make much difference to performance if you substitute variables for literals, both string and numeric? I don't know how good PowerBasic is at handling the literal values, I expect there is some sort of optimisation going on but it may be worth a pop.

[Bob Zale]

There is no reason to substitute variables for literals. That will not provide a benefit. You need to look closely at that StickA() function.

Best regards,

Bob Zale
PowerBASIC Inc.

[Michael Mattias]

>you used PROFILE to determine where your CPU is most used?

EXCELLENT SUGGESTION!!!

[Emil Menzel]

STICK is the name of the function in GWBASIC, QB & PBDOS that reads the joystick port. In my experience it did not work as reliably as other alternatives. STICKA is the name of a substitute (for reading only Stick #1) It is referred in one other thread on PB forums. See my posts (one in 2000 & another in 2005) in this thread:

http://powerbasic.com/support/pbforums/showthread.php?t=11990&highlight=StickA

Is this (or something like it) what you are using, Colin? Also, are you using PBDOS or PBWIN?

[Colin Edwards]

Thanks for the suggestions.

StickA() just calls joyGetPos() with the parameters set for joystick 0.

I am looking at all the processes and the compiled code is using almost all the CPU time.

It's PBCC 4.04

Because the CPU usage only increases by about 2% an hour it takes a long time to be sure if anything is having an effect.
I'm now running tests with sections of the code skipped, but this will take time.

[Chris Holbrook]

StickA() just calls joyGetPos() with the parameters set for joystick 0.

so if you write a little app that just loops calling StickA() and sleeping, does the CPU on that also creep up?

[Michael Mattias]

Add Process Memory Usage Report to any program 1-12-04

Put in each loop. Append to file.

You would think - well, I would think - if there is something sucking up CPU, it would show up as an increase in the amount of memory the program is using. If this were Win 98 (you said above it's XP), I know it would show up here, since there was (is?) a bug in Win/98 on the release of memory.

Then again, we have seen this "eating CPU percent" thing here many, many times when there is some kind of "tight loop" coded into the program. I think the correct solution is, "don't do that."

Eg, I don't see why you are doing 50 calls just to average them. That is, can't you average two or three if one is not enough? (Disclaimer: I do not know this equipment at all). I also don't understand why you bother with SLEEPs between in-memory calculations.

Or maybe you should do those calls in a separate thread of execution, letting the thread function run at a lower priority and ending normally after 50 loops.

Yes, I *am* grasping at straws here.

My best guess is you have a problem elsewhere in your program, but Mr. Holbrook's idea to write a separate program which does NOTHING BUT this joystick code should settle that.

[Colin Edwards]

Thanks again.

Oddly the memory usage is completely stable.

I have disabled the joystick reading part of the code and CPU usage seems stable, but as I said it takes hours to see what's happening.

Tomorrow I'll re-enable the joystick, put a SLEEP 60000 in the code and see what the CPU usage does during that.

[Kev Peel]

My guess is the driver for the device was not designed/intended to be called in such a frequency. Perhaps there is another method to do what you want without polling the driver/hardware so much.

[Michael Mattias]

>My guess is the driver

Another Good Thought.

I would think in that case getJoyPos would fail, maybe with a "too fast!!" error code.

Too bad the programmer is not testing for failure of this call in his code.

Return Values
Returns JOYERR_NOERROR if successful or one of the following error values.

Value Description
MMSYSERR_NODRIVER The joystick driver is not present.
MMSYSERR_INVALPARAM An invalid parameter was passed.
JOYERR_UNPLUGGED The specified joystick is not connected to the system.

Or maybe he's using the wrong function for this hardware...

Remarks
For devices that have four to six axes of movement, a point-of-view control, or more than four buttons, use the joyGetPosEx function

MCM

[Emil Menzel]

>>Then again, we have seen this "eating CPU percent" thing here many, many times when there is some kind of "tight loop" coded into the program. I think the correct solution is, "don't do that."

Of course the problem could also easily stem not from Colin's code as such but from some other Windows program or process that is running in the background. Too bad that PBCC/ PBWIN doesn't have a function to monitor and block (and unblock) multitasking. At the least it would keep old DOS programmers happy. I get by here, more or less, by using the shareware program "The Ultimate TroubleShooter", but that works on one machine only, and not more generally.

Colin:
I like Jim Padgett's suggestion of scheduling the task, rather than running it continuously. Have you tried it?

I'm intrigued by your program -- time lapse digital photography and data manipulation and transmission, the PB way. Can it also use events other than X seconds of time lapse (e.g., a keypress or mouse or joystick movement) to trigger the camera? Is the program for sale? Better yet, is the PB code available? My own interests are those of a retired professor of animal psychology and an amateur programmer, and I'd love to be able to work on such a program myself.

[Michael Mattias]

Too bad that PBCC/ PBWIN doesn't have a function to monitor and block (and unblock) multitasking

See PROFILE function earlier this thread; that tells you (more or less) how much time you spend in functions. There's also the GetProcessTimes() WinAPI call, although that will not isolate to the procedure level

FWIW you CAN change priorities of other programs assuming you have sufficient permissions. Plus, using Sleep[Ex] and WaitFor{singleobject|multipleobjects} forces your process to relinquish control to another thread of execution.

So you *can* control how much CPU time your program gets... but more importantly, you can control how much it *needs* based on your programming techniques.