Replies: 1 comment
-
Hi @blshep, (You didn't include the information that is requested in https://github.com/axboe/fio/blob/fio-3.38/REPORTING-BUGS#L12-L19 / https://github.com/axboe/fio/blob/fio-3.38/.github/SUPPORT.md so I will make assumptions that are convenient for me in answering your question) The missing pieces of information are that fio will use a CPU clock as the clock source when possible (because that clock has the best granularity with the least overhead) and that clock does not start counting from the Unix epoch. Let's trace through fio's code: In hdr->time_sec = io_u->start_time.tv_sec;
hdr->time_nsec = io_u->start_time.tv_nsec; In if (!td->o.disable_lat)
fio_gettime(&io_u->start_time, NULL); In #ifdef FIO_DEBUG_TIME
void fio_gettime(struct timespec *tp, void *caller)
#else
void fio_gettime(struct timespec *tp, void fio_unused *caller)
#endif
{
#ifdef FIO_DEBUG_TIME
if (!caller)
caller = __builtin_return_address(0);
gtod_log_caller(caller);
#endif
if (fio_unlikely(fio_gettime_offload(tp)))
return;
__fio_gettime(tp);
} Finally we get to the definition of static void __fio_gettime(struct timespec *tp)
{
switch (fio_clock_source) { which shows that fio can indeed use different clocks. On Linux x86_64 the different clocks available are:
For comparison:
Here we only have timestamp of 0x074dfe95 nanoseconds (approximately 123 milliseconds) and this roughly represents the time since fio started.
Here the timestamp is 0x679e220e + 0x198ee090/1000**3 seconds which is 1738416654.428794 . Let's see what date that converts to if we interpret it as a Unix time:
Which is when I ran the job. |
Beta Was this translation helpful? Give feedback.
-
I am using verify=md5. Based on the structure in verify.h, the verify_header format is.....
The data written is shown below with the bytes that I think are the timestamp in seconds highlighted. Epoch and Unix timestamp converters don't work. What am I missing?
Beta Was this translation helpful? Give feedback.
All reactions