C++ accurately do action in "every" 100 microsecond without pausing - c++

I writing a program that needs to loop regularly 100 microsecond for one loop. I have found the to loop regularly in a fixed time. But I find a problem when the time for looping is set to be too small.
The following demo code (not complete code) is to:
Increment the count every 100 microsecond.
Show the count every 1 second.
The expected result is showing approximately 10000 every second.
But the result shows about four thousand a second.
void f2(int input)
{
auto start = std::chrono::system_clock::now();
auto displayStart = std::chrono::system_clock::now();
while(true){ //keep looping quickly
auto now = std::chrono::system_clock::now();
auto interval = std::chrono::duration_cast<std::chrono::microseconds>(now - start);
if ( interval.count() > input){ //if 100 microsecond do
count++;
start = std::chrono::system_clock::now();
}
auto displayNow = std::chrono::system_clock::now();
auto displayInterval = std::chrono::duration_cast<std::chrono::microseconds>(displayNow - displayStart);
if ( displayInterval.count() > 1000000){ //if 1 second do
std::cout<< "1 second count: "<<count<<std::endl;
count=0;
displayStart = std::chrono::system_clock::now();
}
}
}
After that I think CPU scheduling may be the problem for this. I have checked the program works normally in every loop . Each iteration takes about 100 microseconds which is accurate. But problem may occur when program/thread is paused and wait for CPU rescheduling.
For example, and lets magnify the value for clearer illustration. The thread paused for 1 second. Normally it will increment for 10000 times. But now, for next iteration it check for >100 microsecond, so count++ and counter is reset as 1 second is passed. For this case, the count incremented only for 1.
With the following code I modified, I can finish 10000 count++ in a second. But the problem is those 10000 count is not evenly distributed in one second. Because this is only the demo program for testing. The action I actually want is to accurately do action in every 100 microsecond. But due to the pausing of thread, I still not find the solution to solve this.
void f2(int input)
{
auto start = std::chrono::system_clock::now();
auto displayStart = std::chrono::system_clock::now();
while(true){ //keep looping quickly
auto now = std::chrono::system_clock::now();
auto interval = std::chrono::duration_cast<std::chrono::microseconds>(now - start);
if ( interval.count() > input){ //if 100 microsecond do
for(int i=0;i<interval.count()/input;i++){ //modified part
count++;
}
start = std::chrono::system_clock::now();
}
auto displayNow = std::chrono::system_clock::now();
auto displayInterval = std::chrono::duration_cast<std::chrono::microseconds>(displayNow - displayStart);
if ( displayInterval.count() > 1000000){ //if 1 second do
std::cout<< "1 second count: "<<count<<std::endl;
count=0;
displayStart = std::chrono::system_clock::now();
}
}
}
Is there any way like:
eg. make process non pause. Keep it in CPU (not so possible)
to make the counting action in demo program works every 100 microseconds?
Thank you very much

Have N buckets, where N is large enough that scheduling delay won't be a problem.
Keep track of the last time your decay code ran.
When a new packet "goes out", put it in a bucket based on the last time your decay code ran (if less than 100 ms, bucket 0, if 200 ms, bucket 1, etc).
When your decay code runs, calculate the current value after decaying everything properly and update the timestamp.
Note that contention (the thread updating and the thread decaying) will remain a problem. You can fix this to some extent with double or triple buffering of the counters, atomic flags and pointers, and busy-loops in the non-performance-sensitive code (say, the decay code).
Alternatively, instead of recording counts, record time stamps. Consume the buffer of time stamps, doing decay at that point. Similar issues involving size of buffer and multiple threads remain, with similar solutions.
Alternatively, do the decay math in the code that is doing the counting.

Related

Why am I not getting a test_time close to 5 seconds?

I'am trying to make a time meter. My OS is Windows.Here is a small piece of code that gives a strange result. If a thread sleeps for 1ms and does this 5000 times, then I would expect it to take roughly 5 seconds. But I get as a result that test_time = 12.8095
Do not understand why?
How can I fix the code so that I get a time meter that can measure durations of about 1 millisecond?
std::atomic_bool work = true;
size_t cnt{};
std::chrono::duration<double> operation_time;
double test_time;
auto start_time_ = std::chrono::high_resolution_clock::now();
std::thread counter_ = std::thread([&work, &cnt]() {
while (work) {
std::this_thread::sleep_for(std::chrono::milliseconds(1));
cnt++;
if (cnt >= 5000)
work = false;
}
});
if (counter_.joinable())
counter_.join();
operation_time = std::chrono::duration<double>(std::chrono::high_resolution_clock::now() - start_time_);
test_time = operation_time.count();
std::cout << "test_time = " << test_time << std::endl;
As previously stated, sleep_for
Blocks the execution of the current thread for at least the specified sleep_duration.
The answer to your question would be to use sleep_until
Blocks the execution of the current thread until specified sleep_time has been reached.
That means, take the current timestamp, add 1 ms and sleep until that time.
See:
https://en.cppreference.com/w/cpp/thread/sleep_for
https://en.cppreference.com/w/cpp/thread/sleep_until

std::this_thread::sleep_until timing is completely off by about a factor of 2, inexplicably

Ok, I really have no idea why this is happening. I'm currently implementing a thread container which runs an infinite loop in a detached manner, limited to a certain speed between each iteration.
Header:
class timeloop
{
public:
std::thread thread = { };
bool state = true;
void (*function_pointer)() = nullptr;
double ratio = 1.0f;
std::chrono::nanoseconds elapsed = { };
timeloop(
void (*function_pointer)() = nullptr
);
void function();
};
Definition:
void timeloop::start()
{
this->thread = std::thread(
&loop::function,
this
);
}
void timeloop::function()
{
std::chrono::steady_clock::time_point next;
std::chrono::steady_clock::time_point start;
std::chrono::steady_clock::time_point end;
while (
this->state
)
{
start = std::chrono::high_resolution_clock::now();
next = start + std::chrono::nanoseconds(
(long long) (this->ratio * (double) std::chrono::nanoseconds::period::den)
);
if (
this->function_pointer != nullptr
)
{
this->function_pointer();
}
/***************************
this is the culprit
***************************/
std::this_thread::sleep_until(
next
);
end = std::chrono::high_resolution_clock::now();
this->elapsed = std::chrono::duration_cast<std::chrono::nanoseconds>(
end - start
);
}
}
Calling code:
timeloop* thread_draw = new timeloop(
&some_void_function
);
thread_draw->ratio = 1.0 / 128.0;
thread_draw->start();
thread_draw->thread.detach();
The definition code is behaving weirdly, specifically std::this_thread::sleep_until. With this->ratio = 1.0 / 128.0 I'm expecting a framerate of around 128, the computed values of start and next reinforce this, yet it inexplicably hovers at around 60. And yeah, I tried just dividing next by 2, but that actually made it drop to around 40.
Extra code to verify the normal time to sleep for:
auto diff = std::chrono::nanoseconds(
next - start
).count() / (double) std::chrono::nanoseconds::period::den;
auto equal = diff == this->ratio;
where equal evaluates to true.
Frame rate calculation:
double time = (double) thread_draw->elapsed.count() / (double) std::chrono::nanoseconds::period::den;
double fps = 1.0 / time;
Though I also used external FPS counters to verify (NVIDIA ShadowPlay and RivaTuner/MSI Afterburner), and they were in a range of about +-5 of the calculated value.
And I know it's std::this_thread::sleep_until because once I comment that out, the frame rate jumps up to around 2000. Yeah...
I'm truly baffled at this, especially seeing how I can't find any evidence of anybody else ever having had this problem. And yes, I'm aware that sleep functions aren't perfectly accurate, and there's bound to be hiccups every now and then, but consistently sleeping for pretty much double the scheduled time is just absurd.
Did I perhaps misconfigure a compiler option or something? It's definitely not a performance problem, and I'm reasonably sure it's not a logic error either (seeing how all the calculations check out) [unless I'm abusing chrono somewhere].
There are no guarantees on resolution of sleep_until, you are only guaranteed the thread will not be woken before the timepoint. If you are implementing the main game loop, read Fix your timestep.
Using sleep to guarantee timing is a terrible way to do it. You are at mercy of OS scheduler and e.g. Windows has a minimal sleep amount about 10 milliseconds I believe. (If the implementation actually asks the OS to put the thread to sleep and the OS decides to do a context switch.)
The lag might also be caused by VSync in the drawing thread if you are calling glfwSwapBuffers or similar. That would explain why your are limited to 60FPS, but not why commenting sleep solves the problem.
So my guess is the OS's sleep above. I would recommend to remove the sleep and rely on VSync, that's the right frequency you want to draw at anyway. Synchronization with logic threads will be a pain in... but that's always the case.
I think your problem is you are not using absolute timing because you keep resetting your absolute time point next relative to the current time now().
Try changing this:
while (
this->state
)
{
start = std::chrono::high_resolution_clock::now();
next = start + std::chrono::nanoseconds(
(long long) (this->ratio * (double) std::chrono::nanoseconds::period::den)
);
// ...
to this
// before the loop
next = std::chrono::high_resolution_clock::now();
while (
this->state
)
{
// keep the timing absolute by adding to the absolute time point
next = next + std::chrono::nanoseconds(
(long long) (this->ratio * (double) std::chrono::nanoseconds::period::den)
);
// ...
That way you call now() only once and then all your subsequent timings are absolutely (as opposed to relatively) calculated from that point.
Edited to add:
Additionally, I would avoid using std::chrono::high_resolution_clock. It is often just an alias of std::chrono::system_clock which is subject to random time alterations as the system clock attempts to remain synchronized with internet time.
Use std::chrono::steady_clock.

Inconsistent chrono::high_resolution_clock delay

I'm trying to implement a MIDI-like clocked sample player.
There is a timer, which increments pulse counter, and every 480 pulses is a quarter, so pulse period is 1041667 ns for 120 beats per minute.
Timer is not sleep-based and running in separate thread, but it seems like delay time is inconsistent: period between samples played in a test file is fluctuating +- 20 ms (in some occasions period is OK and steady, I can't find out dependency of this effect).
Audio backend influence is excluded: i've tried OpenAL as well as SDL_mixer.
void Timer_class::sleep_ns(uint64_t ns){
auto start = std::chrono::high_resolution_clock::now();
bool sleep = true;
while(sleep)
{
auto now = std::chrono::high_resolution_clock::now();
auto elapsed = std::chrono::duration_cast<std::chrono::nanoseconds>(now - start);
if (elapsed.count() >= ns) {
TestTime = elapsed.count();
sleep = false;
//break;
}
}
}
void Timer_class::Runner(void){
// this running as thread
while(1){
sleep_ns(BPMns);
if (Run) Transport.IncPlaybackMarker(); // marker increment
if (Transport.GetPlaybackMarker() == Transport.GetPlaybackEnd()){ // check if timer have reached end, which is 480 pulses
Transport.SetPlaybackMarker(Transport.GetPlaybackStart());
Player.PlayFile(1); // period of this event fluctuates severely
}
}
};
void Player_class::PlayFile(int FileNumber){
#ifdef AUDIO_SDL_MIXER
if(Mix_PlayChannel(-1, WaveData[FileNumber], 0)==-1) {
printf("Mix_PlayChannel: %s\n",Mix_GetError());
}
#endif // AUDIO_SDL_MIXER
}
Am i doing something wrong in terms of an approach? Is there any better way to implement timer of this kind?
Deviation higher than 4-5 ms is too much in case of audio.
I see a large error and a small error. The large error is that your code assumes that the main processing in Runner consistently takes zero time:
if (Run) Transport.IncPlaybackMarker(); // marker increment
if (Transport.GetPlaybackMarker() == Transport.GetPlaybackEnd()){ // check if timer have reached end, which is 480 pulses
Transport.SetPlaybackMarker(Transport.GetPlaybackStart());
Player.PlayFile(1); // period of this event fluctuates severely
}
That is, you're "sleeping" for the time you want your loop iteration to take, and then you're doing processing on top of that.
The small error is presuming that you can represent your ideal loop iteration time with an integral number of nanoseconds. This error is so small that it doesn't really matter. However I amuse myself by showing people how they can get rid of this error too. :-)
First lets correct the small error by exactly representing the idealized loop iteration time:
using quarterPeriod = std::ratio<1, 2>;
using iterationPeriod = std::ratio_divide<quarterPeriod, std::ratio<480>>;
using iteration_time = std::chrono::duration<std::int64_t, iterationPeriod>;
I know nothing of music, but I'm guessing the above code is right because if you convert iteration_time{1} to nanoseconds, you get approximately 1041667ns. iteration_time{1} is intended to be the precise amount of time you want each iteration of your loop in Timer_class::Runner to take.
To correct the large error, you need to sleep until a time_point, as opposed to sleeping for a duration. Here's a generic utility to help you do that:
template <class Clock, class Duration>
void
delay_until(std::chrono::time_point<Clock, Duration> tp)
{
while (Clock::now() < tp)
;
}
Now if you code Timer_class::Runner to use delay_until instead of sleep_ns, I think you'll get better results:
void
Timer_class::Runner()
{
auto next_start = std::chrono::steady_clock::now() + iteration_time{1};
while (true)
{
if (Run) Transport.IncPlaybackMarker(); // marker increment
if (Transport.GetPlaybackMarker() == Transport.GetPlaybackEnd()){ // check if timer have reached end, which is 480 pulses
Transport.SetPlaybackMarker(Transport.GetPlaybackStart());
Player.PlayFile(1);
}
delay_until(next_start);
next_start += iteration_time{1};
}
}
I ended up using #howard-hinnant version of delay, and reducing buffer size in openal-soft, that's what made a huge difference, fluctuations is now about +-5 ms for 1/16th at 120BPM (125 ms period) and +-1 ms for quarter beats. Leaves a lot to be desired, but i guess it's okay

Increasing a value every 5 seconds

I'm making a simple meteor and rocket game in the console. And I want to increase the spawnrate of the meteors every five seconds. I have already tried the Sleep() function but that will of course not work and sleep the whole application. So does a while loop.
I will only post the Logic() function where it must increase because it's a program
of like 100 lines and I didn't feel like posting it all in here. If you do need context just ask me and I will post everything.
void Logic() {
Sleep(5000); // TODO Increase meteors every Five seconds
nMeteors++;
}
I'm pretty stuck on this so it would be nice if someone could help me :)
There are mainly two ways to approach this problem. One would be to spawn a new thread and put the loop there. You can use C++11's standard libraries <thread> and <chrono. Putting the thread to sleep for 5 seconds is as simple as std::this_thread::sleep_for(std::chrono::seconds{5});
But dedicating an entire thread to such a trivial task is unnecessary. In a videogame you usually have some sort of time keeping variable.
What you'd want to do is probably have a variable like std::chrono::time_point<std::chrono::steady_clock> previous_time = std::chrono::steady_clock::now(); (or simply auto previous_time = std::chrono::steady_clock::now()) outside of your loop. Now you have a reference point you can use to know where you are in time while running your loop. Inside of your loop you create another variable like auto current_time = std::chrono::steady_clock::now();, this is your current time. Now it's a simple matter of calculating the difference between current_time and previous_time and check if 5 seconds have passed. If they have, increase your variable and don't forget to set previous_time = current_time; to update the time, if not then just skip and keep doing whatever else you need to do in your main game loop.
To check if 5 seconds have passed, you do if (std::chrono::duration_cast<std::chrono::seconds>(current_time - previous_time).count() >= 5) { ... }.
You can find a lot more info here for the chrono library and here for the thread library. Plus, Google is your friend.
The typical way to write a game is to have an event loop.
The event loop polls various inputs for status, updates the state of the game, and then repeats. Some clever event loops even sleep for short periods and get notifications when inputs change or state has to be updated.
In your meteor spawning code, keep track of a timestamp when the last increase in spawnrate occurred. When you check if a meteor should spawn or spawn meteors 5 seconds after that point, update the spawn rate and record a new timestamp (possibly retroactively, and possibly in a loop to handle more than 10 seconds passing between checks for whatever reason).
An alternative solution involving an extra thread of execution is possible, but not a good idea.
As an aside, most games want to support pausing; so you want to distinguish between wall-clock time and nominal game-play time.
One way you can do this is by making your value a function of elapsed time. For example:
// somewhere to store the beginning of the
// time period.
inline std::time_t& get_start_timer()
{
static std::time_t t{};
return t;
}
// Start a time period (resets meteors to zero)
inline void start_timer()
{
get_start_timer() = std::time(nullptr); // current time in seconds
}
// retrieve the current number of meteors
// as a function of time.
inline int nMeteors()
{
return int(std::difftime(std::time(nullptr), get_start_timer())) / 5;
}
int main()
{
start_timer();
for(;;)
{
std::this_thread::sleep_for(std::chrono::seconds(1));
std::cout << "meteors: " << nMeteors() << '\n';
}
}
Here is a similar version using C++11 <chrono> library:
// somewhere to store the beginning of the
// time period.
inline auto& get_time_point()
{
static std::chrono::steady_clock::time_point tp{};
return tp;
}
// Start a time period (resets meteors to zero)
inline void start_timing()
{
get_time_point() = std::chrono::steady_clock::now(); // current time in seconds
}
// retrieve the current number of meteors
// as a function of time.
inline auto nMeteors()
{
return std::chrono::duration_cast<std::chrono::seconds>(std::chrono::steady_clock::now() - get_time_point()).count() / 5;
}
int main()
{
start_timing();
for(;;)
{
std::this_thread::sleep_for(std::chrono::seconds(1));
std::cout << "meteors: " << nMeteors() << '\n';
}
}
I found this easier than using chrono
Open to feedbacks:
Code:-
include "time.h"
main(){
int d;
time_t s,e;
time(&s);
time(&e);
d=e-s;
while(d<5){
cout<<d;
time(&e);
d=e-s;
}
}

Interesting processing time results

I've made a small application that averages the numbers between 1 and 1000000. It's not hard to see (using a very basic algebraic formula) that the average is 500000.5 but this was more of a project in learning C++ than anything else.
Anyway, I made clock variables that were designed to find the amount of clock steps required for the application to run. When I first ran the script, it said that it took 3770000 clock steps, but every time that I've run it since then, it's taken "0.0" seconds...
I've attached my code at the bottom.
Either a.) It's saved the variables from the first time I ran it, and it's just running quickly to the answer...
or b.) something is wrong with how I'm declaring the time variables.
Regardless... it doesn't make sense.
Any help would be appreciated.
FYI (I'm running this through a Linux computer, not sure if that matters)
double avg (int arr[], int beg, int end)
{
int nums = end - beg + 1;
double sum = 0.0;
for(int i = beg; i <= end; i++)
{
sum += arr[i];
}
//for(int p = 0; p < nums*10000; p ++){}
return sum/nums;
}
int main (int argc, char *argv[])
{
int nums = 1000000;//atoi(argv[0]);
int myarray[nums];
double timediff;
//printf("Arg is: %d\n",argv[0]);
printf("Nums is: %d\n",nums);
clock_t begin_time = clock();
for(int i = 0; i < nums; i++)
{
myarray[i] = i+1;
}
double average = avg(myarray, 0, nums - 1);
printf("%f\n",average);
clock_t end_time = clock();
timediff = (double) difftime(end_time, begin_time);
printf("Time to Average: %f\n", timediff);
return 0;
}
You are measuring the I/O operation too (printf), that depends on external factors and might be affecting the run time. Also, clock() might not be as precise as needed to measure such a small task - look into higher resolution functions such as clock_get_time(). Even then, other processes might affect the run time by generating page fault interrupts and occupying the memory BUS, etc. So this kind of fluctuation is not abnormal at all.
On the machine I tested, Linux's clock call was only accurate to 1/100th of a second. If your code runs in less than 0.01 seconds, it will usually say zero seconds have passed. Also, I ran your program a total of 50 times in .13 seconds, so I find it suspicous that you claim it takes 2 seconds to run it once on your computer.
Your code incorrectly uses the difftime, which may display incorrect output as well if clock says time did pass.
I'd guess that the first timing you got was with different code than that posted in this question, becase I can't think of any way the code in this question could produce a time of 3770000.
Finally, benchmarking is hard, and your code has several benchmarking mistakes:
You're timing how long it takes to (1) fill an array, (2) calculate an average, (3) format the result string (4) make an OS call (slow) that prints said string in the right language/font/colo/etc, which is especially slow.
You're attempting to time a task which takes less than a hundredth of a second, which is WAY too small for any accurate measurement.
Here is my take on your code, measuring that the average takes ~0.001968 seconds on this machine.