how to make process use all cpu time while sleeping (nice -n -20 not high enough priority)

threesc

New Member
Joined
Jul 5, 2021
Messages
7
Reaction score
2
Credits
80
Hello,

I have been running some tests using embedded linux (specifically raspberry pi) to switch a relay off and back on with specific timing. I have been having trouble with the timing being a bit unreliable and when I time my script there is huge different between the real time and user time + sleep time. Anyone have suggestions for improving this, even something like forcing the process to keep using the cpu even when it is in a sleep.

I have been using gpio and .sh scripts, but could use also python or whatever else (though I would prefer to avoid compilation) as long as it can get the result from sshing.

I'm putting this in the single board computer section since I think this is a terrible idea for anything outside of those, but if someone knows a better section for it let me know; I'm not entirely confident it is in the right place.

Thanks for any help.
 


Go to raspberry pi configuration from the preferences menu then click disable on screen blanking. that should keep the pi alive then manually turn off the screen when not in use and it will continue to run until you stop it. hope that helps.
Doing this will make it never sleep.
Also the interfaces right next to it will allow you to adjust settings for the remote GPIO.
 

Attachments

  • 20210819_014739.jpg
    20210819_014739.jpg
    5.8 MB · Views: 303
  • 20210819_015155.jpg
    20210819_015155.jpg
    6.1 MB · Views: 278
Go to raspberry pi configuration from the preferences menu then click disable on screen blanking. that should keep the pi alive then manually turn off the screen when not in use and it will continue to run until you stop it. hope that helps.
Doing this will make it never sleep.
Also the interfaces right next to it will allow you to adjust settings for the remote GPIO.

sorry, should have specified I am running command line only version of raspian (mostly because I didn't want to find a mouse and have no need for gui)
 
sudo raspi-config ?.....
 

Attachments

  • 20210819_021534.jpg
    20210819_021534.jpg
    8.6 MB · Views: 273
  • 20210819_021548.jpg
    20210819_021548.jpg
    8.7 MB · Views: 297
dpkg-query: no packages found matching xscreensaver

not sure, but I think the screen blanking isn't relevant on lite configuration from that. From google it seems there is similar thing for console blanking I can disable.
 
dpkg-query: no packages found matching xscreensaver

not sure, but I think the screen blanking isn't relevant on lite configuration from that. From google it seems there is similar thing for console blanking I can disable.
Hope that works for you sorry I mislead you on the command . just trying to make sense of all this myself.
 
The first thing I would say is Raspbian isn't a setup for real-time operations like say RT Linux with preemptive kernel enhancements. I believe someone has toyed around with the ability to run a Raspberry Pi with a preemptive kernel.

Couple of questions:
  • Can you explain exactly what you are doing?
  • If you're using a bash script, how are you handling time management? Python would probably be far better for this type of task.
  • What type of timing are you trying to accomplish? What frequency? Is it high frequency, or just at very specific times over longer delays. (seconds, minutes, or hours)
  • You might be able to connect a 555 timer to your GPIO and trigger off the 555 timer pulse, but really that depends on your task and the overhead of the job you are executing.
 
Basically I am wanting to run a test where I cut power to something for some time with the time ranging from 100's of ms to a few seconds. The unreliability is not a dealbreaker (as long as my python calls from sh script to get reasonable timing, which I should measure with oscilloscope sometime, I can just record the times and run it enough times that I eventually hit the times I want); but I was hoping it was reasonable to get more accurate timings especially for short manual tests of the same thing that it would take me a lot of time to repeat when they go wrong.

I have a relay set up for this and was considering using a microcontroller to control it and communicating with that. but I think the time to set up the communication interface wouldn't be worth it.

I could just put RT Linux on it though; though it isn't really clear to me how it is possible to have something that is an RTOS (?) that I can ssh into and do things with there. (and have multiple users for)
 
Hmm. Using a shell script to trigger a Python script will be inherently slow. Well, relatively speaking.

The main issue is when you run a Python program, there is a large startup overhead. You have to start the Python interpreter, which has to load all the libraries required to run it. Then you have to execute the script which initially must be compiled into bytecode (though after the first run, it may generate it's own pyc files) and then it must execute it.

A cleaner solution would be to replace the shell script with the Python script itself and just have the Python script act as both the trigger and the action. The Python script could act more as a daemon that also controlled the service that triggers the relays.

Though you were not clear as to what the shell script was doing that required it to trigger the python script.
 
Though you were not clear as to what the shell script was doing that required it to trigger the python script.
That is just the timing, as I was unable to get ms resolution with shell script I think. I could look more into that, I remember it was possible and didn't work, but I guess raspian should probably have that. I can try either that or just a python script then.
 
as an update I've used the timing as described here instead of python: https://stackoverflow.com/questions/16548528/command-to-get-time-in-milliseconds
(I wasn't using it before because one of the other linuxes I was working with doesn't support %N in date formatting)

it works much better, now I can get a fairly consistent 15-17 ms offset from what I put in the sleep which is good enough for my purposes, and if I use nice -n -20 I can get 9-11 ms offset from what I put in sleep

still isn't the kind of timing I would like; but it works well enough; I guess either python or the rt linux would work better but I have no need now
 

Members online


Top