We had an interesting anomaly with GLUT/Intel/Linux this week.
After setting the CPU time back 2 minutes, our GLUT window would not update for 2 minutes.
Does GLUT use the CPU time for updating the display?
The freeglut git repo shows added support for CLOCK_MONOTONIC in 2012.
If you have a version of GLUT that uses gettimeofday instead of clock_gettime(CLOCK_MONOTONIC), code that is driven by fghCheckTimers would probably behave like you describe when setting the time back.
Related
I want to know is there any way to change Windows or Linux clock rate or the system clock rate (maybe via BIOS)? I mean accelerate or decelerate system clock!
For example every 24 hours in the computer lasts 12 hours or 36 hours in real!!!
NOTE :
Using the below batch file, I can decelerate Windows time. But I want something in a lower level! I want to change clock pace in a way that all time for all the programs and tool be slower or faster! not only Windows time!
#echo off
:loop
set T=%time%
timeout 1
time %T%
timeout 1
goto loop
So your CPU's clock is not actually programmable via system calls. It's actually working off of an oscillator w/ crystal. You cannot change during booting up. This is done intentionally so that your CPU is able time regardless of your power/wifi/general system status.
As commented by That Other Guy you might perhaps use adjtimex(2) syscall, but you first should be sure that no NTP client daemon -which uses adjtimex- is running (so stop any ntpd or chrony service).
I'm not sure it would work, and it might make your system quite unstable.
A more rude possibility might be to forcibly set the date(1) -or also hwclock(8)- quite often (e.g. in some crontab job running every 5 minutes).
I believe it (i.e. decelerating a lot the system clock) is a strange and bad thing to do. Don't do that on a production machine (or even on some machine doing significant requests on the Web). Be prepared to perhaps break a lot of things.
I'm using coreutils 8.13 and want to use the timeout command in combination with a python subprocess. If the system clock is changed during a long running call, will the timeout command work as expected? In other words, does the timeout command use absolute time (affected by changing system clock) or relative time (unaffected by changing system clock)?
Edit: After some digging, I've narrowed down that the answer is dependent on the behavior of "alarm" in unistd.h. Still digging through source...please save me.
Edit2: Older version of coreutils (<8.13) use alarm(2) with ITIMER_REAL to timeout. Newer versions (>=8.13) use timer_create(2) with CLOCK_REALTIME to timeout. This post tells me that my implementation should be affected by system clock changes. However, it is not. A simple test using a python script running a while loop shows me that changing the system clock does not affect the timeout. ???
Adjustments to the CLOCK_REALTIME clock have no effect on relative timers based on that clock.
At least, according to this answer of this somewhat similar question.
I have a question about changing kernel frequency.
I compiled kernel by using:
make menuconfig(do some changes in config)
(under Processor type and features->Timer frequency to change frequency)
1.fakeroot make-kpkg --initrd --append-to-version=-mm kernel-image kernel-headers
2.export CONCURRENCY_LEVEL=3
3.sudo dpkg -i linux-image-3.2.14-mm_3.2.14-mm-10.00.Custom_amd64.deb
4.sudo dpkg -i linux-headers-3.2.14-mm_3.2.14-mm-10.00.Custom_amd64.deb
then say if I want to change the frequency of kernel,
what I did is:
I replaced .config file with my own config file
(since I want to do this automatically without opening make menuconfig ui)
then I repeat the step1,2,3,4 again
Is there anyway I do not need repeat the above 4 steps?
Thanks a lot!!!!
The timer frequency is fixed in Linux (unless you build a tickless kernel - CONFIG_NO_HZ=y - but the upper limit will still be fixed). You cannot change it at runtime or at boot time. You can only change it at compile time.
So the answer is: no. You need to rebuild the kernel when you want to change it.
The kernel timer frequency (CONFIG_HZ) is not configurable at runtime - you will have to compile a new kernel when you change the setting and you will have to reboot the system with the new kernel to see the effects of any change.
If you are doing this a lot, though, you should be able to create a little shell script to automate the kernel configure/build/install process. For example it should not be too hard to automate the procedure so that e.g.
./kernel-prep-with-hz 100
would rebuild and install a new kernel, only requiring from you to issue the final reboot command.
Keep in mind though, that the timer frequency may subtly affect various subsystems in unpredictable ways, although things have become a lot better since the tickless timer code was introduced.
Why do you want to do this anyway?
Maybe this will help. As the articale says, you can change the frequency between the available frequency that your system supports. (Check if CPUfreq is already enabled in your system)
Example, mine.
#cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2000000 1667000 1333000 1000000
#echo 1000000 > cpu0/cpufreq/scaling_min_freq
http://www.ibm.com/developerworks/linux/library/l-cpufreq-2/
I've legacy code that uses SetWaitableTimer to perform some task at 10 sec after midnight.
SetWaitableTimer has the following feature, which is used in the code:
If the system time is adjusted, the
due time of any outstanding absolute
timers is adjusted.
I'm porting code to gcc/Linux. How I can simulate the above behaviour?
This is a pretty good overview of linux timer functions. You want the timer_create() / timer_delete() family with CLOCK_REALTIME, then timer_settime() with TIMER_ABSTIME. According to this FAQ it should be adjusted if there is a change to the system clock though I have never tested it.
Folks, in my application I'm using clock_gettime(CLOCK_MONOTONIC) in order to measure the delta time between frames (a typical approach in gamedev) and from time to time I'm facing a strange behavior of clock_gettime(..) - returned values occasionally are not monotonic (i.e prev. time is bigger than current time).
Currently, if such a paradox happens I simply skip the current frame and start processing the next one.
The question is how can this be possible at all? Is it a bug in Linux POSIX implementation of clock_gettime? I'm using Ubuntu Server Edition 10.04 (kernel 2.6.32-24, x86_64), gcc-4.4.3.
man clock_gettime says:
CLOCK_MONOTONIC_RAW (since Linux 2.6.28; Linux-specific)
Similar to CLOCK_MONOTONIC, but provides access to a raw hardware-based time that is not subject to NTP adjustments.
Since CLOCK_MONOTONIC_RAW is not subject of NTP adjustments, I guess CLOCK_MONOTONIC could be.
We had similar problems with Redhat Enterprise 5.0 with 2.6.18 kernel and some specific Itanium processor. We couldn't reproduce it with other processor on the same OS. It was fixed in RHEL 5.3 with slightly newer kernel and some Redhat patches.
Looks like an instance of
commit 0696b711e4be45fa104c12329f617beb29c03f78
Author: Lin Ming <ming.m.lin#intel.com>
Date: Tue Nov 17 13:49:50 2009 +0800
timekeeping: Fix clock_gettime vsyscall time warp
Since commit 0a544198 "timekeeping: Move NTP adjusted clock
multiplier to struct timekeeper" the clock multiplier of vsyscall is updated with
the unmodified clock multiplier of the clock source and not with the
NTP adjusted multiplier of the timekeeper.
This causes user space observerable time warps:
new CLOCK-warp maximum: 120 nsecs, 00000025c337c537 -> 00000025c337c4bf
See here for a patch. This was included into 2.6.32.19, but may not have been backported by the Debian team(?). You should check it out.
Try CLOCK_MONOTONIC_RAW.
Sure sounds like a bug to me. Perhaps you should report it in Ubuntu's bug tracker.
It's a linux bug. No ajustment in a monotonic clock can make it go backwards. You're using a very old kernel and a very old distribution.
Edit: are you sure you need to skip the frame ? If you call clock_gettime again, what happens ?