svn commit: r363125 - head/sys/compat/linux

Mon Jul 13 13:32:08 UTC 2020

Quoting Conrad Meyer <cem at freebsd.org> (from Sun, 12 Jul 2020 16:27:49 -0700):

> Hi Alexander,
>
> On Sun, Jul 12, 2020 at 2:51 AM Alexander Leidinger
> <netchild at freebsd.org> 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 able to judge that. I tried  
to find more info before the commit, but I haven't found more. By  
looking at our man page, I understand the implementation detail  
between MONOTONIC_FAST and MONOTONIC, and I assume the same rationale  
why it was done and why this is useful applies to the linux  
MONOTONIC_COARSE and MONOTONIC. I can not say the same about the  
MONOTONIC_RAW. From reading the linux man page I do not understand the  
rationale of _RAW and as such I do not understand where I want to use  
it and why steam/chrome is using it. As such I do not know if the use  
case has to do with access-speed, or time-precision or something else.  
The linux man page is simply too much underdocumented to be able to  
tell if this is insufficient precision or not.

My gut-feeling is that either of those timecounters work for _RAW. And  
I have my doubts that there were real blind-A/B-experiments/test  
behind chosing the _RAW timecounter on linux. From a pure  
thought-experiment point of view I think that both other options  
MONOTONIC and MONOTONIC_COARSE would work as good as _RAW on linux  
(for steam/chrome) and that there is no benefit of RAW in the  
experience in the UI or with audio or with video.

With all the above being said, I do not hold a lock on the current  
code. If you want to change that part of the implementation of the  
linuxulator, feel free to go ahead (but in this case I challenge you  
in advance to provide an example where it makes a difference ... can  
be a thought-experiment or a real-world example).

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20200713/ac684cff/attachment.sig>