What is the best way to do the following in Linux
while(continue)
{
render(); //this function will take a large fraction of the framerate
wait(); //Wait until the full frame period has expired.
}
On windows, waitable timers seems to work pretty well (within 1 ms). One way of proceeding is to use a separate thread that just sleeps and triggers a sychronization mechanism. However I do not know how much overhead there are in this.
Note: Accuracy is more important than high frequency: A timer with frequency 1.000 kHz is preffered over a timer with 1 MHz.
Assuming you're looking for an answer in the C language:
I don't remember the precision, but I recall I used to use the setitimer() function when I needed good precision.
Here's an example of how to use it: http://docs.oracle.com/cd/E23824_01/html/821-1602/chap7rt-89.html
Related
We have a throttling implementation that essentially boils down to:
Semaphore s = new Semaphore(1);
...
void callMethod() {
s.acquire();
timer.recordCallable(() -> // call expensive method);
s.release();
}
I would like to gather metrics about the impact semaphore has on the overall response time of the method. For example, I would like to know the number of threads that were waiting for acquire, the time spend waiting etc., What, I guess, I am looking for is guage that also captures timing information?
How do I measure the Semphore stats?
There are multiple things you can do depending on your needs and situation.
LongTaskTimer is a timer that measures tasks that are currently in-progress. The in-progress part is key here, since after the task has finished, you will not see its effect on the timer. That's why it is for long running tasks, I'm not sure if it fits your use case.
The other thing that you can do is having a Timer and a Gauge where the timer measures the time it took to acquire the Semaphore while with the gauge, you can increment/decrement the number of threads that are currently waiting on it.
queue_delayed_work(struct workqueue_struct *wq,struct delayed_work *dwork,unsigned long delay)
In the above function, is it possible to give delay that is less than one jiffy?
You can give a delay of zero or more jiffies. To get delay, kernel internally uses a timer. The earliest timer can expire is on the closest next tick. therefore the smallest delay possible is of 1 jiffies. In case of zero jiffies, the delayed work (dwork) will immediately start without any delay.
queue_delayed_work internally calls __queue_delayed_work where implementation for configuring timer is done. The minimum expire time is jiffies + delay. Refer links for more information.
To schedule your work less than jiffiy timer, You can make use of hrtimers(high resolution timer).
For more information related to implementing hrtimer read followinf links :
hrtimer repeating task in the Linux kernel
https://www.ibm.com/developerworks/library/l-timers-list/
The only delay which would be less than one jiffy is 0 jiffies in case of queue_delayed_work.
delay has type unsigned long and it's specified as "number of jiffies to wait before queueing".
when we call wait_event_interruptible ( wq,
condition) is it mandatory to call wake_up function when we use wait_event_interruptible ?
I was using a hrtimer to implement a square wave output with a GPIO.
The System is AR9331 + openwrt, and it does not support PWM output.
The snippet is the following,
Initialization and Start
hrtimer_init(&(s_WS2812_control.send_timer), CLOCK_MONOTONIC, HRTIMER_MODE_REL);
s_WS2812_control.send_timer.function = send_timer_handler;
hrtimer_start(&(s_WS2812_control.send_timer), ktime_set(0, 1000), HRTIMER_MODE_REL); //timeout now
My timeout handler is
send_period = ktime_set(0, 1000); //next timeout period is 1us
gpio_level = ~gpio_level;
gpio_set_value(out_pin, gpio_level);
hrtimer_forward(&send_timer,
send_timer.base->get_time(),
send_period);
My result was not logical since its timeout period(state-switching time) is not fixed. (observed in oscilloscope)
Sometimes it was something like 3.6us, sometimes it was 15us.
I think even if the execution time of handler was larger than 1us, the waveform should be a shift compared to 1us, but not like this, since timer interrupt is high-priority for system just like other hardware interrupt in my thought.
My Waveform is like this, the short/long period is like the above. I really can not understand why the GPIO output was like this.
my waveform link
Please help if anyone know some clues about this, or any suggestion for timer tutorial/learning material is welcome.
Thanks.
What is the expected duration of a call to sleep with one as the argument? Is it some random time that doesn't exceed 1 second? Is it some random time that is at least one second?
Scenario:
Developer A writes code that performs some steps in sequence with an output device. The code is shipped and A leaves.
Developer B is advised from the field that steps j and k need a one-second interval between them. So he inserts a call to sleep(1) between those steps. The code is shipped and Developer B leaves.
Developer C wonders if the sleep(1) should be expected to sleep long enough, or whether a higher-resolution method should be used to make sure that at least 1000 milliseconds of delay occurs.
sleep() only guarantees that the process will sleep for at least the amount of time specified, so as you put it "some random time that is at least one second."
Similar behavior is mentioned in the man page for nanosleep:
nanosleep() suspends the execution of the calling thread until either at least the time specified in *req has elapsed...
You might also find the answers in this question useful.
my man-page says this:
unsigned int sleep(unsigned int seconds);
DESCRIPTION
sleep() makes the calling thread sleep until seconds seconds have
elapsed or a signal arrives which is not ignored.
...
RETURN VALUE
Zero if the requested time has elapsed, or the number of seconds left
to sleep, if the call was interrupted by a signal handler.
so sleep makes the thread sleep, as long as you tell it, but a signals awakes it. I see no further guarantees.
if you need a better, more precise waiting time, then sleep is not good enough. There is nanosleep and (sound funny, but is true) select is the only posix portable way to sleep sub-second (or with higher precision), that I am aware of.
I wonder if anyone of you know how to to use the function get_timer()
to measure the time for context switch
how to find the average?
when to display it?
Could someone help me out with this.
Is it any expert who knows this?
One fairly straightforward way would be to have two threads communicating through a pipe. One thread would do (pseudo-code):
for(n = 1000; n--;) {
now = clock_gettime(CLOCK_MONOTONIC_RAW);
write(pipe, now);
sleep(1msec); // to make sure that the other thread blocks again on pipe read
}
Another thread would do:
context_switch_times[1000];
while(n = 1000; n--;) {
time = read(pipe);
now = clock_gettime(CLOCK_MONOTONIC_RAW);
context_switch_times[n] = now - time;
}
That is, it would measure the time duration between when the data was written into the pipe by one thread and the time when the other thread woke up and read that data. A histogram of context_switch_times array would show the distribution of context switch times.
The times would include the overhead of pipe read and write and getting the time, however, it gives a good sense of big the context switch times are.
In the past I did a similar test using stock Fedora 13 kernel and real-time FIFO threads. The minimum context switch times I got were around 4-5 usec.
I dont think we can actually measure this time from User space, as in kernel you never know when your process is picked up after its time slice expires. So whatever you get in userspace includes scheduling delays as well. However, from user space you can get closer measurement but not exact always. Even a jiffy delay matters.
I believe LTTng can be used to capture detailed traces of context switch timings, among other things.