<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/haproxy.git/include/haproxy/clock.h, branch master</title>
<subtitle>github.com: haproxy/haproxy.git
</subtitle>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/'/>
<entry>
<title>MINOR: clock: provide a function to automatically adjust now_offset</title>
<updated>2023-05-17T07:33:54+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-05-16T17:01:55+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=5345490b8e0a3c82587fd1ccf30244035cf0b1d5'/>
<id>5345490b8e0a3c82587fd1ccf30244035cf0b1d5</id>
<content type='text'>
Right now there's no way to enforce a specific value of now_ms upon
startup in order to compensate for the time it takes to load a config,
specifically when dealing with the health check startup. For this we'd
need to force the now_offset value to compensate for the last known
value of the current date. This patch exposes a function to do exactly
this.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Right now there's no way to enforce a specific value of now_ms upon
startup in order to compensate for the time it takes to load a config,
specifically when dealing with the health check startup. For this we'd
need to force the now_offset value to compensate for the last known
value of the current date. This patch exposes a function to do exactly
this.
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: measure the total boot time</title>
<updated>2023-05-17T07:33:54+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-05-17T07:02:21+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=da4aa6905c5524a30709eb4cdf25e22fc63eb86e'/>
<id>da4aa6905c5524a30709eb4cdf25e22fc63eb86e</id>
<content type='text'>
Some huge configs take a significant amount of time to start and this
can cause some trouble (e.g. health checks getting delayed and grouped,
process not responding to the CLI etc). For example, some configs might
start fast in certain environments and slowly in other ones just due to
the use of a wrong DNS server that delays all libc's resolutions. Let's
first start by measuring it by keeping a copy of the most recently known
ready date, once before calling check_config_validity() and then refine
it when leaving this function. A last call is finally performed just
before deciding to split between master and worker processes, and it covers
the whole boot. It's trivial to collect and even allows to get rid of a
call to clock_update_date() in function check_config_validity() that was
used in hope to better schedule future events.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some huge configs take a significant amount of time to start and this
can cause some trouble (e.g. health checks getting delayed and grouped,
process not responding to the CLI etc). For example, some configs might
start fast in certain environments and slowly in other ones just due to
the use of a wrong DNS server that delays all libc's resolutions. Let's
first start by measuring it by keeping a copy of the most recently known
ready date, once before calling check_config_validity() and then refine
it when leaving this function. A last call is finally performed just
before deciding to split between master and worker processes, and it covers
the whole boot. It's trivial to collect and even allows to get rid of a
call to clock_update_date() in function check_config_validity() that was
used in hope to better schedule future events.
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: replace the timeval start_time with start_time_ns</title>
<updated>2023-04-28T14:08:08+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-04-28T12:50:29+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=c05d30e9d8f55ff7f04741c7ae836f74c703822a'/>
<id>c05d30e9d8f55ff7f04741c7ae836f74c703822a</id>
<content type='text'>
Now that "now" is no more a timeval, there's no point keeping a copy
of it as a timeval, let's also switch start_time to nanoseconds, it
simplifies operations.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now that "now" is no more a timeval, there's no point keeping a copy
of it as a timeval, let's also switch start_time to nanoseconds, it
simplifies operations.
</pre>
</div>
</content>
</entry>
<entry>
<title>MEDIUM: clock: replace timeval "now" with integer "now_ns"</title>
<updated>2023-04-28T14:08:08+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-04-28T07:16:15+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=69530f59ae3a3b4db560a57139669737656b16c5'/>
<id>69530f59ae3a3b4db560a57139669737656b16c5</id>
<content type='text'>
This puts an end to the occasional confusion between the "now" date
that is internal, monotonic and not synchronized with the system's
date, and "date" which is the system's date and not necessarily
monotonic. Variable "now" was removed and replaced with a 64-bit
integer "now_ns" which is a counter of nanoseconds. It wraps every
585 years, so if all goes well (i.e. if humanity does not need
haproxy anymore in 500 years), it will just never wrap. This implies
that now_ns is never nul and that the zero value can reliably be used
as "not set yet" for a timestamp if needed. This will also simplify
date checks where it becomes possible again to do "date1&lt;date2".

All occurrences of "tv_to_ns(&amp;now)" were simply replaced by "now_ns".
Due to the intricacies between now, global_now and now_offset, all 3
had to be turned to nanoseconds at once. It's not a problem since all
of them were solely used in 3 functions in clock.c, but they make the
patch look bigger than it really  is.

The clock_update_local_date() and clock_update_global_date() functions
are now much simpler as there's no need anymore to perform conversions
nor to round the timeval up or down.

The wrapping continues to happen by presetting the internal offset in
the short future so that the 32-bit now_ms continues to wrap 20 seconds
after boot.

The start_time used to calculate uptime can still be turned to
nanoseconds now. One interrogation concerns global_now_ms which is used
only for the freq counters. It's unclear whether there's more value in
using two variables that need to be synchronized sequentially like today
or to just use global_now_ns divided by 1 million. Both approaches will
work equally well on modern systems, the difference might come from
smaller ones. Better not change anyhting for now.

One benefit of the new approach is that we now have an internal date
with a resolution of the nanosecond and the precision of the microsecond,
which can be useful to extend some measurements given that timestamps
also have this resolution.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This puts an end to the occasional confusion between the "now" date
that is internal, monotonic and not synchronized with the system's
date, and "date" which is the system's date and not necessarily
monotonic. Variable "now" was removed and replaced with a 64-bit
integer "now_ns" which is a counter of nanoseconds. It wraps every
585 years, so if all goes well (i.e. if humanity does not need
haproxy anymore in 500 years), it will just never wrap. This implies
that now_ns is never nul and that the zero value can reliably be used
as "not set yet" for a timestamp if needed. This will also simplify
date checks where it becomes possible again to do "date1&lt;date2".

All occurrences of "tv_to_ns(&amp;now)" were simply replaced by "now_ns".
Due to the intricacies between now, global_now and now_offset, all 3
had to be turned to nanoseconds at once. It's not a problem since all
of them were solely used in 3 functions in clock.c, but they make the
patch look bigger than it really  is.

The clock_update_local_date() and clock_update_global_date() functions
are now much simpler as there's no need anymore to perform conversions
nor to round the timeval up or down.

The wrapping continues to happen by presetting the internal offset in
the short future so that the 32-bit now_ms continues to wrap 20 seconds
after boot.

The start_time used to calculate uptime can still be turned to
nanoseconds now. One interrogation concerns global_now_ms which is used
only for the freq counters. It's unclear whether there's more value in
using two variables that need to be synchronized sequentially like today
or to just use global_now_ns divided by 1 million. Both approaches will
work equally well on modern systems, the difference might come from
smaller ones. Better not change anyhting for now.

One benefit of the new approach is that we now have an internal date
with a resolution of the nanosecond and the precision of the microsecond,
which can be useful to extend some measurements given that timestamps
also have this resolution.
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: add now_cpu_time_fast() function</title>
<updated>2023-04-19T09:03:31+00:00</updated>
<author>
<name>Aurelien DARRAGON</name>
<email>adarragon@haproxy.com</email>
</author>
<published>2023-04-04T15:21:40+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=df188f145bba955640a7cc9f34efb819fedddb1a'/>
<id>df188f145bba955640a7cc9f34efb819fedddb1a</id>
<content type='text'>
Same as now_cpu_time(), but for fast queries (less accurate)
Relies on now_cpu_time() and now_mono_time_fast() is used
as a cache expiration hint to prevent now_cpu_time() from being
called too often since it is known to be quite expensive.

Depends on commit "MINOR: clock: add now_mono_time_fast() function"
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Same as now_cpu_time(), but for fast queries (less accurate)
Relies on now_cpu_time() and now_mono_time_fast() is used
as a cache expiration hint to prevent now_cpu_time() from being
called too often since it is known to be quite expensive.

Depends on commit "MINOR: clock: add now_mono_time_fast() function"
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: add now_mono_time_fast() function</title>
<updated>2023-04-19T09:03:31+00:00</updated>
<author>
<name>Aurelien DARRAGON</name>
<email>adarragon@haproxy.com</email>
</author>
<published>2022-11-25T07:56:46+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=07cbd8e0741d141e19f7b11cbd873c142bb84cae'/>
<id>07cbd8e0741d141e19f7b11cbd873c142bb84cae</id>
<content type='text'>
Same as now_mono_time(), but for fast queries (less accurate)
Relies on coarse clock source (also known as fast clock source on
some systems).

Fallback to now_mono_time() if coarse source is not supported on the system.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Same as now_mono_time(), but for fast queries (less accurate)
Relies on coarse clock source (also known as fast clock source on
some systems).

Fallback to now_mono_time() if coarse source is not supported on the system.
</pre>
</div>
</content>
</entry>
<entry>
<title>BUG/MINOR: clock: do not mix wall-clock and monotonic time in uptime calculation</title>
<updated>2023-02-08T10:06:55+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2023-02-07T14:52:14+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=6093ba47c0b940df7ba60943dfb0ae88de47c323'/>
<id>6093ba47c0b940df7ba60943dfb0ae88de47c323</id>
<content type='text'>
We've had a start date even before the internal monotonic clock existed,
but once the monotonic clock was added, the start date was not updated
to distinguish the wall clock time units and the internal monotonic time
units. The distinction is important because both clocks do not necessarily
progress at the same speed. The very rare occurrences of the wall-clock
date are essentially for human consumption and communication with third
parties (e.g. report the start date in "show info" for monitoring
purposes). However currently this one is also used to measure the distance
to "now" as being the process' uptime. This is actually not correct. It
only works because for now the two dates are initialized at the exact
same instant at boot but could still be wrong if the system's date shows
a big jump backwards during startup for example. In addition the current
situation prevents us from enforcing an abritrary offset at boot to reveal
some heisenbugs.

This patch adds a new "start_time" at boot that is set from "now" and is
used in uptime calculations. "start_date" instead is now set from "date"
and will always reflect the system date for human consumption (e.g. in
"show info"). This way we're now sure that any drift of the internal
clock relative to the system date will not impact the reported uptime.

This could possibly be backported though it's unlikely that anyone has
ever noticed the problem.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've had a start date even before the internal monotonic clock existed,
but once the monotonic clock was added, the start date was not updated
to distinguish the wall clock time units and the internal monotonic time
units. The distinction is important because both clocks do not necessarily
progress at the same speed. The very rare occurrences of the wall-clock
date are essentially for human consumption and communication with third
parties (e.g. report the start date in "show info" for monitoring
purposes). However currently this one is also used to measure the distance
to "now" as being the process' uptime. This is actually not correct. It
only works because for now the two dates are initialized at the exact
same instant at boot but could still be wrong if the system's date shows
a big jump backwards during startup for example. In addition the current
situation prevents us from enforcing an abritrary offset at boot to reveal
some heisenbugs.

This patch adds a new "start_time" at boot that is set from "now" and is
used in uptime calculations. "start_date" instead is now set from "date"
and will always reflect the system date for human consumption (e.g. in
"show info"). This way we're now sure that any drift of the internal
clock relative to the system date will not impact the reported uptime.

This could possibly be backported though it's unlikely that anyone has
ever noticed the problem.
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: split local and global date updates</title>
<updated>2022-09-21T07:06:28+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2022-09-21T05:37:27+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=a70042067180b4fa068909a2bff48227bb8e3c98'/>
<id>a70042067180b4fa068909a2bff48227bb8e3c98</id>
<content type='text'>
Pollers that support busy polling spend a lot of time (and cause
contention) updating the global date when they're looping over themselves
while it serves no purpose: what's needed is only an update on the local
date to know when to stop looping.

This patch splits clock_pudate_date() into a pair of local and global
update functions, so that pollers can be easily improved.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pollers that support busy polling spend a lot of time (and cause
contention) updating the global date when they're looping over themselves
while it serves no purpose: what's needed is only an update on the local
date to know when to stop looping.

This patch splits clock_pudate_date() into a pair of local and global
update functions, so that pollers can be easily improved.
</pre>
</div>
</content>
</entry>
<entry>
<title>MINOR: clock: move the clock_ids to clock.c</title>
<updated>2021-10-08T15:22:26+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2021-10-08T13:09:17+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=2169498941254eef0589d7c078f9955959d4baf5'/>
<id>2169498941254eef0589d7c078f9955959d4baf5</id>
<content type='text'>
This removes the knowledge of clockid_t from anywhere but clock.c, thus
eliminating a source of includes burden. The unused clock_id field was
removed from thread_info, and the definition setting of clockid_t was
removed from compat.h. The most visible change is that the function
now_cpu_time_thread() now takes the thread number instead of a tinfo
pointer.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This removes the knowledge of clockid_t from anywhere but clock.c, thus
eliminating a source of includes burden. The unused clock_id field was
removed from thread_info, and the definition setting of clockid_t was
removed from compat.h. The most visible change is that the function
now_cpu_time_thread() now takes the thread number instead of a tinfo
pointer.
</pre>
</div>
</content>
</entry>
<entry>
<title>REORG: clock/wdt: move wdt timer initialization to clock.c</title>
<updated>2021-10-08T15:22:26+00:00</updated>
<author>
<name>Willy Tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2021-10-08T12:48:30+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/haproxy.git/commit/?id=6cb0c391e7654e44795e43f9a7bb92c1aee74f95'/>
<id>6cb0c391e7654e44795e43f9a7bb92c1aee74f95</id>
<content type='text'>
The code that deals with timer creation for the WDT was moved to clock.c
and is called with the few relevant arguments. This removes the need for
awareness of clock_id from wdt.c and as such saves us from having to
share it outside. The timer_t is also known only from both ends but not
from the public API so that we don't have to create a fake timer_t
anymore on systems which do not support it (e.g. macos).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The code that deals with timer creation for the WDT was moved to clock.c
and is called with the few relevant arguments. This removes the need for
awareness of clock_id from wdt.c and as such saves us from having to
share it outside. The timer_t is also known only from both ends but not
from the public API so that we don't have to create a fake timer_t
anymore on systems which do not support it (e.g. macos).
</pre>
</div>
</content>
</entry>
</feed>
