Quoting Conrad Meyer (from Sun, 12 Jul 2020 16:27:49 -0700):
Hi Alexander,
On Sun, Jul 12, 2020 at 2:51 AM Alexander Leidinger
wrote:
Author: netchild
Date: Sun Jul 12 09:51:09 2020
New Revision: 363125
URL: https://svnweb.freebsd.org/changeset/base/363125
Log:
Implement CLOCK_MONOTONIC_RAW (linux >= 2.6.28).
It is documented as a raw hardware-based clock not subject to NTP or
incremental adjustments. With this "not as precise as CLOCK_MONOTONIC"
description in mind, map it to our CLOCK_MONOTNIC_FAST (the same
mapping as for the linux CLOCK_MONOTONIC_COARSE).
Can you point at the documentation suggesting CLOCK_MONOTONIC_RAW is
any less precise than CLOCK_MONOTONIC? I'm looking at the Linux
manual page and it does not seem to contain any language to that
effect.
It depends what each of us means by "less precise".
I only had a look at the man page online, and what I refer to her in
terms of precision is the "not subject to NTP or incremental
adjustments". I understand this as: MONOTINIC is rather precise about
the rate of change (e.g. it is close to the rate of change as far as
you can get with NTP and the hardware you have), whereas MONOTIC_RAW
may increase faster or slower than MONOTONIC, but it stays monotonic.
This is needed for the webcomponent of steam (chromium) and some
other steam component or game.
The linux-steam-utils port contains a LD_PRELOAD based fix for this.
There this is mapped to CLOCK_MONOTONIC.
As an untrained ear/eye (= the majority of people) is normaly not
noticing a difference of jitter in the 10-20 ms range, specially
if you don't pay attention like for example in a browser session
while watching a video stream, the mapping to CLOCK_MONOTONIC_FAST
seems more appropriate than to CLOCK_MONOTONIC.
I don't know how these programs use the clock, but 10-20 ms of jitter
in the UI is noticeable to even casual users. (In FreeBSD these
A german DIY electronic magazine had once (about 20 years ago) a
little device with which you was able to test your sensitivity between
two audio or visual events. It simply activated the left and right
device for a short moment of time (LED or a click in the headphone).
It displayed how far in time the two events were apart (the scale was
from 10ms to 100ms in 10ms steps). I should have still this device
somehere...
In my twenties, I tested it. I was able to distinguish 2 different
events which were 40-60ms apart (don't remember if I was able to
detect shorter pauses in the audio test or in the visual test, but
both weren't at the same level). They told with age your ability gets
worse.
This device was able to train your abilities in this regard. The
training mode did the same, but instead of only one type of test, you
was testing both (audio + visual). This not onlxy brought the slower
of both down to the level of the faster one (when testing afterwards
only one of the types), but with some repetition you was able to
distinguish two different events which were too close in time to each
other before. I was able to get down to 20ms (and sometimes 10ms). But
I had to be concentrated on the test.
So I have first hand experience of being able to notice two events
which are 20ms apart... 20 years ago, after some days of training.
And this is the sole reason why I mentioned 10-20ms in the commit log.
See further down before commenting on this sentence.
Bring me 3 people which swear that they notice a difference when
running steam / linux-chrome (comparing MONOTONIC_FAST vs MONOTONIC),
and which tell that it annoys them, and I fully agree to switch to
MONOTONIC. Please see below before commenting on this sentence.
functions are purportedly accurate to 1 timer tick, which is 1ms on
HZ=1000 (amd64) — much better than 10-20ms.) However, I'm concerned
Our MONOTONIC_FAST is documented to have an accuracy of one timer
tick. So we _are_ with this setting at 1ms (with HZ=1000). This
accuracy is a worst case accuracy. If your call to get the clock is
0.1ms after the update of the value MONOTONIC_FAST reads out, you are
as accurate as 0.1ms... So the accuracy we achieve with the mapping to
MONOTONIC_FAST is between 0ms and 1ms (with HZ=1000). To come back to
what I said before and change it a little bit: if you bring 3 people
which swear they notice a difference of upto 1ms in their use of steam
/ linux-chrome which annoys them, and if they switch to MONOTONIC and
they do not notice a difference anymore, I fully agree to switch to
MONOTONIC. Until them I'm sceptical that this can be noticed.
this is still insufficient precision compared with the documented
behavior of the Linux functions. I think regular CLOCK_MONOTONIC is
the closest thing we've got to Linux's CLOCK_MONOTONIC_RAW. The Linux
analog of _FAST is _COARSE.
I do not know which one is closer. I consider the linux man page I've
read online as not detailed enough to be
