On Thu, Oct 14, 2021 at 04:13:18PM -0500, Scott Cheloha wrote:
>
> [...]
>
> When we compute high resolution time, both in the kernel and in libc,
> we get a 32-bit (or smaller) value from the active timecounter and
> scale it up into a 128-bit bintime.
>
> The scaling math currently looks like
> On Oct 14, 2021, at 18:09, Scott Cheloha wrote:
>
> On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
>>> Date: Thu, 14 Oct 2021 16:13:17 -0500
>>> From: Scott Cheloha
>>>
>>> [...]
>>>
>>> Thoughts?
>>
>> I never understood this code. But I don't understand that if our
>>
On Thu, Oct 14, 2021 at 11:37:44PM +0200, Mark Kettenis wrote:
> > Date: Thu, 14 Oct 2021 16:13:17 -0500
> > From: Scott Cheloha
> >
> > [...]
> >
> > Thoughts?
>
> I never understood this code. But I don't understand that if our
> timecounters are only 32 bits, we need more than 64 bits to
> Date: Thu, 14 Oct 2021 16:13:17 -0500
> From: Scott Cheloha
>
> Hi,
>
> When we compute high resolution time, both in the kernel and in libc,
> we get a 32-bit (or smaller) value from the active timecounter and
> scale it up into a 128-bit bintime.
>
> The scaling math currently looks like
Hi,
When we compute high resolution time, both in the kernel and in libc,
we get a 32-bit (or smaller) value from the active timecounter and
scale it up into a 128-bit bintime.
The scaling math currently looks like this in the kernel:
*bt = th->th_offset;
bintimeaddfrac(bt,
