Quoting Conrad Meyer <c...@freebsd.org> (from Sun, 12 Jul 2020 16:27:49 -0700):
Hi Alexander, On Sun, Jul 12, 2020 at 2:51 AM Alexander Leidinger <netch...@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 alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
pgpeUdmbVjSD8.pgp
Description: Digitale PGP-Signatur
