I have a tcl/tk with c desktop application, and one of the requirements is to change the system time, in the background there are threads running from the c code, and "after" commands from the tcl code. Whenever I change the time to an earlier time the system hangs
i.e: 05:50:12 -> 05:45:12 also i get weird behavior when going forward in time. I'm running lubuntu. I'm not sure what to do in this situation, I made some test and it seems the after keeps on waiting after i change back in time.
to change the time i use : exec date --set="STRING" from the tcl code
Tcl depends on the system time (converted to seconds from the start of the Unix epoch) increasing fairly close to monotonically for the correct behaviour of a number of things, but most particularly anything in the after command. Internally, after computes the absolute time that an event should happen and only triggers things once that time is reached, so that things being triggered early (which can happen because of various OS events) don't cause problems. If you set the system time back a long way, Tcl will wait until the absolute time is reached anyway, which will look a lot like a hang.
Just synch your clock with NTP (i.e., switch on ntpd) and stop fiddling with the system clock by hand.
Related
I have an assignment where I am analyzing the runtime of various sorting algorithms. I have written the code but I think it's an unfair comparison.
My code basically grabs the the clock time before and after the sorting is finished to compute the elapsed time. However, what if the OS decides to interrupt more frequently during the runtime of a specific sorting algorithm, or if it rather decides that some other background application should be given more of the time domain when it's thread comes back up?
I am not a CS major so I may not be entirely correct here, but from what I've read previously I was concerned this might have an impact on the results.
I also realize that if OS scheduling is suspended and the program hangs then there might be a serious problem; I am just wondering if it possible.
Normally, there's no real reason for it. The scheduler will slightly increase the execution time, but if the code runs for a few seconds, the change will be tiny.
So unless you're running heavy applications on the same computer, the amount of noise this will add to your tests is negligible.
In Linux, you can use isolcpus parameter to mark CPUs that won't be used by the scheduler. You can find information here. I'm not sure what's the minimal kernel version.
If you use it, you'll need to use sched_setaffinity, to put your theread on an isolated CPU, because the scheduler won't put it there.
It is not possible, not in user space code. Otherwise, any malicious process could steal the CPU from others.
If you want precise time counting for your process only, I suggest using time command. You can read about it here: What do 'real', 'user' and 'sys' mean in the output of time(1)?
Quick answer: you are most likely interested in user time, assuming your code doesn't make a heavy use of syscalls (which would be rather strange for a sorting algorithm)
On an up-to-date POSIX system (basically Linux) you can use clock_gettime with CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID if you make sure the process doesn't migrate between CPUs (you can set its affinity for example).
The difference in times returned by clock_gettime with those arguments results in exact time the process/thread spent executing. Only pitfall as I mentioned is process migration as the man page says:
The CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID clocks are realized on many platforms using timers from the CPUs (TSC on i386, AR.ITC on Itanium). These registers may differ between CPUs and as a consequence these clocks may return bogus results if a process is migrated to another CPU.
This means that you don't really need to suspend all other processes just to measure the execution time of your program.
I want to measure my program exe startup time it
is the time from the moment of click or [enter]
if started from console or any other way till
the moment when program startup is done and
its code can execute with all structures set up
(probably it means when first commands in main()
are executed [?])
I want to measure it programmaticaly from
inside of my code - so i think a way to do it
would need to read an exact time of firing
the program then substract this time from
the time of first line of codes execution
(sorry for my bad english) How to do it?
Do you want to measure from the click or [enter], which includes the shell (cmd.exe or Windows Explorer) overhead, or from program startup?
Programatically you can only measure time from process creation, so that won't include finding, reading and mapping the .exe file or any DLLs. The timing will vary depending on what is already mapped in virtual memory. It will include initialisation of the C RTL, but not much else.
Probably the best you can do is GetProcessTimes.
The problem is that even the parent process does not necessarily wait for the child process initialisation to complete -- it could, using the WaitForInputIdle, but if you are using standard tools like Windows Explorer then you stuck with that. I can't see any way to measure the shell overhead without writing your own.
I have a GTK window with an image inside of it. I want this image to change. Let's say I have two images, "sun.png" and "moon.png". Once every second, I want to receieve the output of "date -f%l" to get the current hour. If the hour is between 7-19 (7 AM to 7 PM), I want to display sun.png. Else, I want to display moon.png.
Is it possible to have a seperate thread with a while loop in it, that changes the image as the program's running? How would I go about doing this?
I'm writing in C, by the way.
This isn't going to be a complete answer, but it's too long for a comment and it's important.
You definitely do not implement something like this by going into a loop sleeping for one second at a time and calling the external date command and parsing its output to determine what to do next. Not only is this a lot more work than is necessary; more importantly, it will eat your users' batteries for dinner.
Instead, you call gettimeofday or clock_gettime to determine the current time, then compute the next time in the future that the sun/moon image will need to be changed. Then, you sleep the whole interval until that time, i.e. up to 12 hours in a single sleep. If your thread wakes up early (perhaps from signals, etc.) then you just determine, on calling gettimeofday again, that it's not yet time to change, and compute a new duration of time to go back to sleep. This way, the CPU remains completely idle (and can go into powersaving mode) except when there's actually work to be done.
As for whether you can do this with a thread at all in GTK+, I'm pretty sure you can, but I'm not familiar with the GTK+ API.
As a part of my academic project I have to execute a C program.
I want to get the execution time of the program. For that I have to sleep all other processes in Linux for some seconds. Is there any method for doing that?
(I have tried using the time command in Linux but it is not working properly: it shows different execution time when I am executing the same program. So I am computing execution time by seeing the difference between start time and end time).
About the best way I can think of is to drop to single-user mode, which you get with
# init 1
on pretty much any distribution. This will also stop X, you'll be on a raw console. Handling interrupts from stray mouse movement is likely to be one of the reasons for whatever variability you're seeing, so that's a good thing.
When you want your full system back, init 3 is probably the one, that or init 5.
The usual way to do this is to try to quiesce the machine as much as possible, then take several measurements and average them. It's advisable to discard the first reading, as that's likely to involve population of caches.
It is impossible to get the exact time of execution of a process into a system in which the scheduler commutes from 1 process to the other.
The Intel processors inserted a register that counts the number of clocks, but even so it is impossible to measure the time.
There is a book that you can find as PDF on google, "Computer Systems: A Programmer's Perspective" -- In this book an whole chapter is dedicated to time measurements.
Use the time command. The sum user + sys will give you the time your programm used the CPU directly plus the time the system used the CPU on behalf of your program. I think it is what you want to know.
There will always be a difference in execution time for things no matter how many processes you shut down, polling, IO, background daemons all affect execution priority.
The academic approach would be to run a sizeable sample and take statistics, you might also want to take a look at sar to log the background. To invalidate any readings you might take
Try executing your application with nice -n 20. It may help to make the other processes quieter.
nice man page
I am currently using getrusage to tell me how much time I spend in my application's event loop.
I wonder how this will be affected by hibernating. Is hibernation time reported at all? Or perhaps as system time? Is this specified somewhere in Posix or is this system dependent?
Edit Asking the same question for Windows here.
I don't think POSIX mentions hibernation anywhere, so it is technically platform dependent.
I can only speak for Linux, but other UNIX variants - and perhaps even Windows - probably behave similarly, since this is what makes most sense.
In Linux, the exact details of what happens under the hood with hibernation are described in Documentation/power/swsusp.txt under the kernel source. In short, user processes are sent a fake signal that causes them to switch to TASK_UNINTERRUPTIBLE state. A process in the TASK_UNINTERRUPTIBLE state is taken out of the run queue and put to sleep until the condition it is waiting for comes true, so time spent in TASK_UNINTERRUPTIBLE is neither counted as user time nor as system time. If you were to measure runtimes with time(1), you would at most see that it contributes to wall clock time.
With getrusage(2), you won't see a difference in any of the reported CPU times because the process wasn't runnable.
So, to answer your question: hibernation time is not reported at all.