From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 19 May 2014 12:24:32 -0400 To: 9fans@9fans.net Message-ID: <063412cb21a6433d959274d7db87d242@ladd.quanstro.net> In-Reply-To: <73d0faddf32ce1bc1d64f05fd113dece@proxima.alt.za> References: <73d0faddf32ce1bc1d64f05fd113dece@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] syscall 53 Topicbox-Message-UUID: e84e574a-ead8-11e9-9d60-3106f5b1d025 On Mon May 19 10:04:28 EDT 2014, lucio@proxima.alt.za wrote: > > i indirectly heard "go needs it", but that is not really a reason > > i can understand technically. why must it be a system call? >=20 > Actually, Go raised an important alert, quite indirectly: when using > high resolution timers, the issue of opening a device, reading it and > converting the input value to a binary value can and in this case is > very expensive. > > Curiously, the actual symptom - I cannot remember how it came about - > was that using the timer leaked file descriptors, or, more likely, > gave the impression of leaking file descriptors. But the reality is > that nanosecond accuracy cannot be achieved from reading a device by > conventional means. i think my original question still stands. what is the purpose of timing= , what is the desired accuracy and precision, and is a relative or absolute time wanted? =20 a relative time (say a time adjusted with timesync, including leap second= s, etc) is not what you want if you want relative timing. something like the timestamp counter makes a lot more sense. i took a quick look at the runtime=C2=B7nanotime, and it looks like it's = being used for gettimeofday, which shouldn't be super performance sensitive. - erik