[Questions] Realtime capabilities of libfaketime

[KUGA2]

Hi,

we have a realtime system and stumbled upon this library. We are investigation possibilities to speed up the execution for simulation, when the CPU is faster then the embedded one.

This is not an issue but a few questions (I could not see any other contact form):

• Is the faketime timer affected by settime calls (e.g. ntp) of the host?
• Which systemcalls are wrapped? Which objects are affected by faketime? I have a list of objects we use: pthread_mutex_t, sem_t, timer_t, mqd_t, fds (sockets), pthread_cond
• Can the speed be controlled at runtime? Can the speed be 0 and we do only steps with settime (-DFAKE_SETTIME)?
• Are threads, that already wait, affected by changing the timepoint and speed?

Thanks!

[wolfcw]

On Linux-like systems, libfaketime is typically LD_PRELOADed to individual processes, so intercepted system calls like clock_settime() are only handled locally within each process. However, for synchronisation of FAKETIME settings across processes, one can use environment variables, text files, or the timestamps of files.

libfaketime currently intercepts and handles system calls to

clock_get_time
clock_gettime
clock_nanosleep
epoll_pwait
epoll_wait
fstat
ftime
futimens
getentropy
getpid
getrandom
gettimeofday
lstat
nanosleep
poll
ppoll
pselect
pthread_cond_destroy
pthread_cond_init
pthread_cond_timedwait
select
sem_clockwait
sem_timedwait
sleep
stat
syscall
time
timerfd_gettime
timerfd_settime
timer_gettime
timer_settime
timespec_get
usleep
utime
utimensat
utimes

along with their respective parameters / types.

You can change the FAKETIME setting at run-time, typically in combination with disabling libfaketime's caching and using text files or file timestamps for FAKETIME specification. You can set frozen timestamps so time does not advance for the affected process, you can slow the progression of time down to a crawl, or you can let increment libfaketime the faked time automatically with each call to a time-related system call (which provides some sort of determinism and repeatability).

Given that libfaketime internally passes intercepted calls through to the original system calls (and then just fakes their return values), changes to FAKETIME settings have no effect while an original system call is waiting, e.g., for a long time-out. The actual effect will probably depend on how the application is implemented; if it uses short time-outs and, e.g., a loop for repeated calls until, e.g., a mutex becomes available, things should be fine, and otherwise it will probably wait for the originally specified time before picking up the new FAKETIME.

[KUGA2]

Thank you!

Comeback on first question: Is the faketime timer affected by settime calls (e.g. ntp) of the host?

Maybe a little example:

• I start my process with faketime (1x speed and the exact same time as the host).
• Then my process runs sem_timedwait(now + 1min).
• Then (while sem_timedwaitis waiting) i set the time of the host os to now + 2min.

Will the waiting sem_timedwait block (for 1min) for will it immediately return with timeout?

[wolfcw]

libfaketime passes intercepted system calls through to the original ones (and manipulates their result values afterwards).

So what you are asking really is whether the original system calls are affected by changes to the real system-wide time (at run-time, i.e., during a call to one of those system functions).

This probably depends on how the original system calls are implemented, e.g., as part of glibc and the operating system kernel. I can't give a one-size-fits-all answer to that and you probably have to try it out in your specific environment.

libfaketime pretty much just calculates an offset to add/subtract to/from the results of the original system calls based on the FAKETIME setting. It does not really care about the current system-wide time, and it does not implement any sleeping/waiting mechanisms on its own. It relies on the original system calls for that.

[wolfcw]

I assume your questions were answered sufficiently. Please feel free to re-open otherwise.