code segment as follows, code come frome chromium, why?
// Initilalize initial_ticks and initial_time
void InitializeClock() {
initial_ticks = TimeTicks::Now();
// Initilalize initial_time
initial_time = CurrentWallclockMicroseconds();
}// static
Time Time::Now() {
if (initial_time == 0)
InitializeClock();
// We implement time using the high-resolution timers so that we can get
// timeouts which are smaller than 10-15ms. If we just used
// CurrentWallclockMicroseconds(), we'd have the less-granular timer.
//
// To make this work, we initialize the clock (initial_time) and the
// counter (initial_ctr). To compute the initial time, we can check
// the number of ticks that have elapsed, and compute the delta.
//
// To avoid any drift, we periodically resync the counters to the system
// clock.
while (true) {
TimeTicks ticks = TimeTicks::Now();
// Calculate the time elapsed since we started our timer
TimeDelta elapsed = ticks - initial_ticks;
// Check if enough time has elapsed that we need to resync the clock.
if (elapsed.InMilliseconds() > kMaxMillisecondsToAvoidDrift) {
InitializeClock();
continue;
}
return Time(elapsed + Time(initial_time));
}
}
I assume your answer lies in the comment of the code you pasted:
// We implement time using the high-resolution timers so that we can get
// timeouts which are smaller than 10-15ms. If we just used
// CurrentWallclockMicroseconds(), we'd have the less-granular timer.
So Now gives a time value of high resolution, which is beneficial when you need higher resolution than 10-15ms, as they state in the comment. For instance, if you want to reschedule a task every 100 ns, you need the higher resolution, or if you want to measure the execution time of something - 10-15 ms is an eternity.
Related
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
This is my code using QueryPeformanceCounter as timer.
//timer.h
class timer {
private:
...
public:
...
double get(); //returns elapsed time in seconds
void start();
};
//a.cpp
void loop() {
timer t;
double tick;
double diff; //surplus seconds
t.start();
while( running ) {
tick = t.get();
if( tick >= 1.0 - diff ) {
t.start();
//things that should be run exactly every second
...
}
Sleep( 880 );
}
}
Without Sleep this loop would go on indefinitely calling t.get() every time which causes high CPU usage. For that reason, I make it sleep for about 880 milliseconds so that it wouldn't call t.get() while not necessary.
As I said above, I'm currently using Sleep to do the trick, but what I'm worried about is the accuracy of Sleep. I've read somewhere that the actual milliseconds the program pauses may vary - 20 to 50 ms - the reason I set the parameter to 880. I want to reduce the CPU usage as much as possible; I want to, if possible, pause more than 990 milliseconds EDIT: and yet less than 1000 milliseconds between every loop. What would be the best way to go?
I don't get why you are calling t.start() twice (it resets the clock?), but I would like to propose a kind of solution for the Sleep inaccuracy. Let's take a look at the content of while( running ) loop and follow the algorithm:
double future, remaining, sleep_precision = 0.05;
while (running) {
future = t.get() + 1.0;
things_that_should_be_run_exactly_every_second();
// the loop in case of spurious wakeup
for (;;) {
remaining = future - t.get();
if (remaining < sleep_precision) break;
Sleep(remaining);
}
// next, do the spin-lock for at most sleep_precision
while (t.get() < future);
}
The value of sleep_precision should be set empirically - OSes I know can't give you that.
Next, there are some alternatives of the sleeping mechanism that may better suit your needs - Is there an alternative for sleep() in C?
If you want to pause more than 990 milliseconds, write a sleep for 991 milliseconds. Your thread is guaranteed to be asleep for at least that long. It won't be less, but it could be multiples of 20-50ms more (depending on the resolution of your OS's time slicing, and on the the cost of context switching).
However, this will not give you something running "exactly every second". There is just no way to achieve that on a time-shared operating system. You'll have to program closer to the metal, or rely on an interrupt from a PPS source and just pray your OS lets you run your entire loop iteration in one shot. Or, I suppose, write something to run in kernel mode…?
I am printing microseconds continuously using gettimeofday(). As given in program output you can see that the time is not updated microsecond interval rather its repetitive for certain samples then increments not in microseconds but in milliseconds.
while(1)
{
gettimeofday(&capture_time, NULL);
printf(".%ld\n", capture_time.tv_usec);
}
Program output:
.414719
.414719
.414719
.414719
.430344
.430344
.430344
.430344
e.t.c
I want the output to increment sequentially like,
.414719
.414720
.414721
.414722
.414723
or
.414723, .414723+x, .414723+2x, .414723 +3x + ...+ .414723+nx
It seems that microseconds are not refreshed when I acquire it from capture_time.tv_usec.
=================================
//Full Program
#include <iostream>
#include <windows.h>
#include <conio.h>
#include <time.h>
#include <stdio.h>
#if defined(_MSC_VER) || defined(_MSC_EXTENSIONS)
#define DELTA_EPOCH_IN_MICROSECS 11644473600000000Ui64
#else
#define DELTA_EPOCH_IN_MICROSECS 11644473600000000ULL
#endif
struct timezone
{
int tz_minuteswest; /* minutes W of Greenwich */
int tz_dsttime; /* type of dst correction */
};
timeval capture_time; // structure
int gettimeofday(struct timeval *tv, struct timezone *tz)
{
FILETIME ft;
unsigned __int64 tmpres = 0;
static int tzflag;
if (NULL != tv)
{
GetSystemTimeAsFileTime(&ft);
tmpres |= ft.dwHighDateTime;
tmpres <<= 32;
tmpres |= ft.dwLowDateTime;
/*converting file time to unix epoch*/
tmpres -= DELTA_EPOCH_IN_MICROSECS;
tmpres /= 10; /*convert into microseconds*/
tv->tv_sec = (long)(tmpres / 1000000UL);
tv->tv_usec = (long)(tmpres % 1000000UL);
}
if (NULL != tz)
{
if (!tzflag)
{
_tzset();
tzflag++;
}
tz->tz_minuteswest = _timezone / 60;
tz->tz_dsttime = _daylight;
}
return 0;
}
int main()
{
while(1)
{
gettimeofday(&capture_time, NULL);
printf(".%ld\n", capture_time.tv_usec);// JUST PRINTING MICROSECONDS
}
}
The change in time you observe is 0.414719 s to 0.430344 s. The difference is 15.615 ms. The fact that the representation of the number is microsecond does not mean that it is incremented by 1 microsecond. In fact I would have expected 15.625 ms. This is the system time increment on standard hardware. I've given a closer look here and here.
This is called granularity of the system time.
Windows:
However, there is a way to improve this, a way to reduce the granularity: The Multimedia Timers. Particulary Obtaining and Setting Timer Resolution will disclose a way to increase the systems interrupt frequency.
The code:
#define TARGET_PERIOD 1 // 1-millisecond target interrupt period
TIMECAPS tc;
UINT wTimerRes;
if (timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)
// this call queries the systems timer hardware capabilities
// it returns the wPeriodMin and wPeriodMax with the TIMECAPS structure
{
// Error; application can't continue.
}
// finding the minimum possible interrupt period:
wTimerRes = min(max(tc.wPeriodMin, TARGET_PERIOD ), tc.wPeriodMax);
// and setting the minimum period:
timeBeginPeriod(wTimerRes);
This will force the system to run at its maximum interrupt frequency. As a consequence
also the update of the system time will happen more often and the granularity of the system time increment will be close to 1 milisecond on most systems.
When you deserve resolution/granularity beyond this, you'd have to look into QueryPerformanceCounter. But this is to be used with care when using it over longer periods of time. The frequency of this counter can be obtained by a call to QueryPerformanceFrequency. The OS considers this frequency as a constant and will give the same value all time. However, some hardware produces this frequency and the true frequency differs from the given value. It has an offset and it shows thermal drift. Thus the error shall be assumed in the range of several to many microseconds/second. More details about this can be found in the second "here" link above.
Linux:
The situation looks somewhat different for Linux. See this to get an idea. Linux
mixes information of the CMOS clock using the function getnstimeofday (for seconds since epoch) and information from a high freqeuncy counter (for the microseconds) using the function timekeeping_get_ns. This is not trivial and is questionable in terms of accuracy since both sources are backed by different hardware. The two sources are not phase locked, thus it is possible to get more/less than one million microseconds per second.
The Windows system clock only ticks every few milliseconds -- in your case 64 times per second, so when it does tick it increases the system time by 15.625 ms.
The solution is to use a higher-resolution timer that the system time (QueryPerformanceCounter).
You still won't see .414723, .414723+x, .414723+2x, .414723 +3x + ...+ .414723+nx, though, because you code will not run exactly once every x microseconds. It will run as fast as it can, but there's no particular reason that should always be a constant speed, or that if it is then it's an integer number of microseconds.
I recommend you to look at the C++11 <chrono> header.
high_resolution_clock (C++11) the clock with the shortest tick period available
The tick period referred to here is the frequency at which the clock is updated. If we look in more details:
template<
class Rep,
class Period = std::ratio<1>
> class duration;
Class template std::chrono::duration represents a time interval.
It consists of a count of ticks of type Rep and a tick period, where the tick period is a compile-time rational constant representing the number of seconds from one tick to the next.
Previously, functions like gettimeofday would give you a time expressed in microseconds, however they would utterly fail to tell you the interval at which this time expression was refreshed.
In the C++11 Standard, this information is now in the clear, to make it obvious that there is no relation between the unit in which the time is expressed and the tick period. And that, therefore, you definitely need to take both into accounts.
The tick period is extremely important when you want to measure durations that are close to it. If the duration you wish to measure is inferior to the tick period, then you will measure it "discretely" like you observed: 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, ... I advise caution at this point.
This is because the process running your code isn't always scheduled to execute.
Whilst it does, it will bang round the loop quickly, printing multiple values for each microsecond - which is a comparatively long period of time on modern CPUs.
There are then periods where it is not scheduled to execute by the system, and therefore cannot print values.
If what you want to do is execute every microsecond, this may be possible with some real-time operating systems running on high performance hardware.
I thought I was jumping over a puddle, but have instead fallen into an ocean :/
I'm trying to implement a 5 second timer (don't need more than milliseconds).
My goal:
// I start the program in gamestate 0...
{
if (button_has_been_pressed == 1)
{
gamestate = 1;
}
}
if (gamestate==1)
{
//wait for 5 seconds and go to gamestate2
gamestate = 2;
}
I've tried the following:
GLUT_TIME_ELAPSED measures time from the beginning of my program. I am unable to 'reset' GLUT_TIME_ELAPSED after entering gamestate1. Otherwise, it would work wonderfully.
gettimeofday gives me much more resolution than I need. At most, milliseconds would be applicable.
Regardless of my resolution needs, I've tried Song Ho's method:
gamestate1_elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0; // sec to ms
gamestate1_elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0; // us to ms
// add that elapsed time together, and keep track of its total
//r_gamestate1_elapsedTime_total = gamestate1_elapsedTime;
//if (r_gamestate1_elapsedTime_total > 5 seconds) ...
However, the gamestate1_elapsedTime appears to have some variability to it. Because the output is seldom consistent. I guess it's b/c gettimeofday employs CPU time(?), and I am artificially clamping this with my fps clamp.
I've tried clock() as well, but that also appears to be CPU time - not wall time.
As mentioned above, GLUT_ELAPSED_TIME works well, except that I am unable to reset it midway through my program, and my 5-seconds is no longer dependent upon my initial button click.
I would deeply appreciate even a nudge in the right direction, if you could lend some advice. Thank you very much in advance.
-kropcke
You don't need to "reset" GLUT_ELAPSED_TIME, you just need to copy it somewhere that you can use as an offset. For example:
int timeAtReset = glutGet(GLUT_ELAPSED_TIME);
// I start the program in gamestate 0...
{
if (button_has_been_pressed == 1)
{
gamestate = 1;
timeAtReset = glutGet(GLUT_ELAPSED_TIME);
}
}
if (gamestate==1)
{
int timeSinceReset = glutGet(GLUT_ELAPSED_TIME) - timeAtReset;
// use timeSinceReset, instead of glutGet(GLUT_ELAPSED_TIME), to
// wait for 5 seconds and go to gamestate2
gamestate = 2;
}
Trying to understand the concepts of setting constant speed on game loop. My head hurts. I read the deWiTTERS page, but I can't see the why/how...when I get it...it slips.
while(true)
{
player->update() ;
player->draw() ;
}
This will run as fast as possible depending on how fast a processor is...I get that.
To run at the same speed on all computers, the logic is what I don't get. If I am trying to run at 60fps, then it means for every 16ms the objects move by a frame, yeah? What I don't get is how the update() or draw() may be too slow.
deWiTTERS example (I used 60):
const int FRAMES_PER_SECOND = 60;
const int SKIP_TICKS = 1000 / FRAMES_PER_SECOND;
DWORD next_game_tick = GetTickCount();
// GetTickCount() returns the current number of milliseconds
// that have elapsed since the system was started
int sleep_time = 0;
bool game_is_running = true;
while( game_is_running ) {
update_game();
display_game();
next_game_tick += SKIP_TICKS;
sleep_time = next_game_tick - GetTickCount();
if( sleep_time >= 0 ) {
Sleep( sleep_time );
}
else {
// Shit, we are running behind!
}
}
I don't understand why he gets the current time before the loop starts. And when he increments by SKIP_TICKS I understand he increments to the next 16ms interval. But I don't understand this part as well:
sleep_time = nextgametick - GetTickCount()
What does Sleep(sleep_time) mean? The processor leaves the loop and does something else? How does it achieve running 60fps?
In cases where the update_game() and display_game() functions complete in less time than a single frame interval at 60FPs, the loop tries to ensure that the next frame is not processed until that interval is up, by sleeping (blocking the thread) off the excess frame time. Seems like it is trying to ensure that the frame rate is capped to 60FPS, and no higher.
The processor does not 'leave the loop' but rather the thread in which your loop is running is blocked (prevented from continuing execution of your code) until the sleep time is up. Then it continues onto the next frame. In a multi-threaded game engine, sleeping the thread of the main game loop like this gives the CPU time to execute code in other threads, which may be managing physics, AI, audio mixing etc, depending on set up.
Why is GetTickCount() called before the loop starts?
We know from the comment in your code that GetTickCount() returns the milliseconds since system boot.
So lets say that the system has been running for 30 seconds (30,000ms) when you start your program,
and let's say that we didn't call GetTickCount() before entering the loop,
but instead initialized next_game_tick to 0.
We do the update and draw calls (as an example, they take 6ms) and then:
next_game_tick += SKIP_TICKS; // next_game_tick is now 16
sleep_time = next_game_tick - GetTickCount();
// GetTickCount() returns 30000!
// So sleep_time is now 16 - 30000 = -29984 !!!
Since we (sensibly) only sleep when sleep_time is positive,
the game loop would run as fast as possible (potentially faster than 60FPS),
which is not what you want.