-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option in fio to log with the same epoch as CLOCK_MONOTONIC_RAW #1314
Labels
Comments
That sounds useful, please do feel free to work on that change. |
Thanks for the quick feedback. I'll try to get a PR fairly quickly - first time to build it so I'll be learning a bit. |
aggieNick02
added a commit
to PCPartPicker/fio
that referenced
this issue
Dec 15, 2021
Add options log_alternate_epoch and log_alternate_epoch_clock_id. This is similar to the log_unix_epoch option. This resolves the issue raised in Issue axboe#1314 log_alternate_epoch, if true, causes log files to use the same epoch used used by the clock_id parameter to the unix clock_gettime function, where clock_id is specified by the log_alternate_epoch_clock_id option. This is particularly useful as it allows us to specify a clock id like CLOCK_MONOTONIC_RAW, which is natural for synchronizing log files between processes. The current log_unix_epoch is problematic for that purpose because that clock is not monotonic or continuous. It turns out that log_unix_epoch is actually equivalent to log_alternate_epoch with log_alternate_epoch_clock_id set to CLOCK_REALTIME=0. Since this is the default value of the log_alternate_epoch_clock_id option anyways, we treat log_alternate_epoch and log_unix_epoch as equivalent in functionality, retaining the latter to avoid breaking existing clients. Signed-off-by: Nick Neumann <nick@pcpartpicker.com>
This was fixed by #1315 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now fio offers two options for the various bandwidth, latency, etc. log files. You can use an epoch that is very close to when fio starts running, or the unix epoch.
If you are trying to synchronize your fio logs with other data acquired from other processes during a fio run, neither of these is a great option. (A good example would be another process running to acquire temperature data from the disk being tested.)
The default epoch - when fio starts running - is private to fio. Other processes don't know what it is, and the logs all start with times close to 0. The unix epoch is obtained via gettimeofday(), and is subject to discontinuity and not guaranteed to be monotonic (e.g.,ntp adjustments)
For logs from two processes to be synchronized, they need to be able to speak in terms of a common epoch in a continuous and monotonic time system.
I'm pretty sure all that is needed to support synchronizing fio logs with other processes is to allow for a different epoch to be used - namely, whatever epoch is used by CLOCK_MONOTONIC_RAW (
clock_gettime(CLOCK_MONOTONIC_RAW,ts);
) .Would fio be open to this option? If so, I'd be happy to work on the PR. I'd expect it to only be a few lines of code.
The text was updated successfully, but these errors were encountered: