> From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, 20 March 2024 15.39 > > On Wed, 20 Mar 2024 09:34:21 +0100 > Morten Brørup <m...@smartsharesystems.com> wrote: > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Wednesday, 20 March 2024 04.34 > > > > > > On Tue, 19 Mar 2024 17:13:35 +0100 > > > Morten Brørup <m...@smartsharesystems.com> wrote: > > > > > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > > > Sent: Tuesday, 19 March 2024 16.52 > > > > > > > > > > On Tue, 19 Mar 2024 08:37:30 +0100 > > > > > Morten Brørup <m...@smartsharesystems.com> wrote: > > > > > > > > > > > > static ssize_t > > > > > > > console_log_write(__rte_unused void *c, const char *buf, > size_t > > > > > size) > > > > > > > { > > > > > > > + struct timespec ts; > > > > > > > ssize_t ret; > > > > > > > > > > > > > > - /* write on stderr */ > > > > > > > - ret = fwrite(buf, 1, size, stderr); > > > > > > > + if (timestamp_enabled) { > > > > > > > + clock_gettime(CLOCK_MONOTONIC, &ts); > > > > > > > + ts.tv_sec -= log_started.tv_sec; > > > > > > > + ts.tv_nsec -= log_started.tv_nsec; > > > > > > > > > > > > Please log the absolute CLOCK_MONOTONIC instead of subtracting > > > > > log_started, so timestamps can be easily compared with > timestamps from > > > > > other processes. > > > > > > > > > > > > > > > No, was trying to do what kernel dmesg does. > > > > > > > > What do you mean? Doesn't the kernel output CLOCK_MONOTONIC > timestamps > > > (without offset)? > > > > > > > > And by "timestamps from other processes" I also mean timestamps in > log > > > messages from the kernel itself. > > > > > > > > > > If you look at dmesg command that formats the messages, it has lots > of > > > timestamp options. > > > Next version will support more of these. > > > > > > --time-format format > > > Print timestamps using the given format, which can be > ctime, > > > reltime, delta or iso. The first three formats are > aliases of > > > the time-format-specific options. The iso format is a > dmesg > > > implementation of the ISO-8601 timestamp format. The > purpose > > > of this format is to make the comparing of timestamps > between > > > two systems, and any other parsing, easy. The definition > of > > > the iso timestamp is: > > > YYYY-MM-DD<T>HH:MM:SS,<microseconds>←+><timezone offset > from > > > UTC>. > > > > That's formatting. > > > > I'm talking about the initial offset. > > > > The kernel's "log start time" is set to system start timestamp. > > > > Your "log start time" is set to application start timestamp: > > > > +void > > +eal_log_enable_timestamp(void) > > +{ > > + timestamp_enabled = true; > > + clock_gettime(CLOCK_MONOTONIC, &log_started); > > +} > > > > So, different offset. I prefer using the same offset. > > > Monotonic has no absolute zero time and can be quite large so offsetting > seemed most logical. Also, the kernel does not make boot time monotonic > clock value available. Other options are REALTIME or BOOTTIME. > But both of these get quite large.
I don't think that having a large tv_sec is a problem. I think the ability to correlate log timestamps with other applications is more important. If we choose one of the standard clocks, applications might choose the same clock. If we subtract the start time of this specific application, it's not in sync with anything else. The question really is: Which clock is most popular for debug logging to the console? We should use that clock.
