Date: Mon, 13 Jul 2020 15:32:05 +0200 From: Alexander Leidinger <netchild@freebsd.org> To: Conrad Meyer <cem@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r363125 - head/sys/compat/linux Message-ID: <20200713153205.Horde.3fZseDV88TEEnXbYL8ZwX50@webmail.leidinger.net> In-Reply-To: <CAG6CVpXniVitnrk2qqnkGocHG%2BiPKHfPJ-KuRdaPKbNfTnrE=A@mail.gmail.com> References: <202007120951.06C9pA4F024281@repo.freebsd.org> <CAG6CVpXniVitnrk2qqnkGocHG%2BiPKHfPJ-KuRdaPKbNfTnrE=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed. --=_UMX5_4lrr3cyWS9q7suIWav Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Conrad Meyer <cem@freebsd.org> (from Sun, 12 Jul 2020 16:27:49 -070= 0): > Hi Alexander, > > On Sun, Jul 12, 2020 at 2:51 AM Alexander Leidinger > <netchild@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 >=3D 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=20=20 terms=20of precision is the "not subject to NTP or incremental=20=20 adjustments".=20I understand this as: MONOTINIC is rather precise about=20= =20 the=20rate of change (e.g. it is close to the rate of change as far as=20= =20 you=20can get with NTP and the hardware you have), whereas MONOTIC_RAW=20= =20 may=20increase 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 (=3D 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=20=20 little=20device with which you was able to test your sensitivity between=20= =20 two=20audio or visual events. It simply activated the left and right=20=20 device=20for a short moment of time (LED or a click in the headphone).=20= =20 It=20displayed how far in time the two events were apart (the scale was=20= =20 from=2010ms to 100ms in 10ms steps). I should have still this device=20=20 somehere... In=20my twenties, I tested it. I was able to distinguish 2 different=20=20 events=20which were 40-60ms apart (don't remember if I was able to=20=20 detect=20shorter pauses in the audio test or in the visual test, but=20=20 both=20weren't at the same level). They told with age your ability gets=20= =20 worse. This=20device was able to train your abilities in this regard. The=20=20 training=20mode did the same, but instead of only one type of test, you=20= =20 was=20testing both (audio + visual). This not onlxy brought the slower=20= =20 of=20both down to the level of the faster one (when testing afterwards=20= =20 only=20one of the types), but with some repetition you was able to=20=20 distinguish=20two different events which were too close in time to each=20= =20 other=20before. I was able to get down to 20ms (and sometimes 10ms). But=20= =20 I=20had to be concentrated on the test. So I have first hand experience of being able to notice two events=20=20 which=20are 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.=20= =20 See=20further down before commenting on this sentence. Bring me 3 people which swear that they notice a difference when=20=20 running=20steam / linux-chrome (comparing MONOTONIC_FAST vs MONOTONIC),=20= =20 and=20which tell that it annoys them, and I fully agree to switch to=20=20 MONOTONIC.=20Please see below before commenting on this sentence. > functions are purportedly accurate to 1 timer tick, which is 1ms on > HZ=3D1000 (amd64) =E2=80=94 much better than 10-20ms.) However, I'm conc= erned Our MONOTONIC_FAST is documented to have an accuracy of one timer=20=20 tick.=20So we _are_ with this setting at 1ms (with HZ=3D1000). This=20=20 accuracy=20is a worst case accuracy. If your call to get the clock is=20=20 0.1ms=20after the update of the value MONOTONIC_FAST reads out, you are=20= =20 as=20accurate as 0.1ms... So the accuracy we achieve with the mapping to=20= =20 MONOTONIC_FAST=20is between 0ms and 1ms (with HZ=3D1000). To come back to= =20=20 what=20I said before and change it a little bit: if you bring 3 people=20= =20 which=20swear they notice a difference of upto 1ms in their use of steam=20= =20 /=20linux-chrome which annoys them, and if they switch to MONOTONIC and=20= =20 they=20do not notice a difference anymore, I fully agree to switch to=20=20 MONOTONIC.=20Until 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=20=20 read=20online as not detailed enough to be able to judge that. I tried=20= =20 to=20find more info before the commit, but I haven't found more. By=20=20 looking=20at our man page, I understand the implementation detail=20=20 between=20MONOTONIC_FAST and MONOTONIC, and I assume the same rationale=20= =20 why=20it was done and why this is useful applies to the linux=20=20 MONOTONIC_COARSE=20and MONOTONIC. I can not say the same about the=20=20 MONOTONIC_RAW.=20From reading the linux man page I do not understand the=20= =20 rationale=20of _RAW and as such I do not understand where I want to use=20= =20 it=20and why steam/chrome is using it. As such I do not know if the use=20= =20 case=20has to do with access-speed, or time-precision or something else.=20= =20 The=20linux man page is simply too much underdocumented to be able to=20=20 tell=20if this is insufficient precision or not. My gut-feeling is that either of those timecounters work for _RAW. And=20= =20 I=20have my doubts that there were real blind-A/B-experiments/test=20=20 behind=20chosing the _RAW timecounter on linux. From a pure=20=20 thought-experiment=20point of view I think that both other options=20=20 MONOTONIC=20and MONOTONIC_COARSE would work as good as _RAW on linux=20=20 (for=20steam/chrome) and that there is no benefit of RAW in the=20=20 experience=20in the UI or with audio or with video. With all the above being said, I do not hold a lock on the current=20=20 code.=20If you want to change that part of the implementation of the=20=20 linuxulator,=20feel free to go ahead (but in this case I challenge you=20= =20 in=20advance to provide an example where it makes a difference ... can=20= =20 be=20a thought-experiment or a real-world example). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_UMX5_4lrr3cyWS9q7suIWav Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJfDGJVAAoJEBINsJsD+NiGZosP+wRSK5djf8PaJrxtf4EDMabd KHuFU+3kMi1ifpbynLgkNh4y8XDUBuBxgw8QmJWIxBKiTx/lLFYmHOILnRB8fRTi Dylzd+mnyE8DoU9iBT1rF4Je6zAL7ebrhuj0H6/KnJhSewHmL1vwIdIO8ChEQzQS LTm+axqi8WZWxB+UiDZjABy11zrPbfYCnPZijvWTZCFTgHj5uZ3gl8NO0Wmo3hMc z7sJJHTau1oxfPip4bwZbkCnOuo0kb7KWBsfqnvoFqcnxchQxJPDxrsNudRhXzjJ YMFsLYrPSCNOuKOLkiuRQjuhiwpITXc+7Fs6Y0syZIxxFaXvmLSnLVvt5MdifrzO vR/x9YH4yxR08SwKHbMa/j92gcft/cOtFIfJ4sRqVDtigndXGn4woCe5pB3Evdcd ULhVKZ9O1Ct1wrxFFKGq7HlImVhidipzp35X25Z7Y8tQfD1tEEaMhQewoEGh2g+o BjInn86PvdRnCm/oflwDiM674fko4HS4zr7fn11buQttCJ0seyCyM8SQVRt/4FDs rQENdJafeDwPHLhapw5oIpnPfEUaKnhbx7Uug+KFptFr6hVGYHSKBGEcGO0TkKSX pMw6o3JD+RhsxbVzFENqZNXxFGXfNH6qoH7Ttuqtr5HNixCcylrCS0aVUjoNeJgM CTZZxkVb0UiO8D8W1r92 =lxop -----END PGP SIGNATURE----- --=_UMX5_4lrr3cyWS9q7suIWav--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200713153205.Horde.3fZseDV88TEEnXbYL8ZwX50>