Date: Mon, 11 Oct 2021 11:31:29 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Large timecounter delta handling Message-ID: <994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee@embedded-brains.de> In-Reply-To: <YWP8sNfY0i4VNunS@kib.kiev.ua> References: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> <YWP8sNfY0i4VNunS@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/10/2021 10:58, Konstantin Belousov wrote: > On Mon, Oct 11, 2021 at 09:53:31AM +0200, Sebastian Huber wrote: >> Hello, >> >> I synchronize currently the port of the FreeBSD timecounters to RTEMS.= I >> have to write test cases for all code we use in RTEMS. In 2020 some co= de was >> added to fix integer overflow issues with large time deltas while gett= ing >> the time from a timehand. >> >> https://github.com/freebsd/freebsd-src/commit/6cf2362e2c7e9061611f93a4= 8ec654a5b7451d6b#diff-8b8e2f8e41e6a847f14ab08c7d50454c20a4a135f2c2241d916= 87c0832c1d99e >> >> If a time delta obtained by tc_delta(th) is greater than or equal to >> th->th_large_delta, then some extra calculation is carried out. >> >> The th->th_large_delta is computed like this >> >> scale =3D (uint64_t)1 << 63; >> scale +=3D (th->th_adjustment / 1024) * 2199; >> scale /=3D th->th_counter->tc_frequency; >> th->th_scale =3D scale * 2; >> th->th_large_delta =3D MIN(((uint64_t)1 << 63) / scale, UINT_MAX); >> >> If we ignore the th->th_adjustment (=3D=3D 0), then we have ideally >> >> scale =3D 2**64 / f >> th->th_large_delta =3D MIN( f / 2, UINT_MAX ) >> >> Does this mean that we only need the large delta processing if a timeh= and >> was not updated for about 0.5s? >=20 > I do not understand your question. We need large_delta to handle overf= lows > in bintime_off(). tc_large_delta is computed in advance during windup = to > avoid this calculation in time reading code. Yes, I also ask since we never got bug reports for RTEMS related to such=20 a scenario. No updates for about 0.5s would mean that an RTEMS=20 application is already in a completely undefined system state. Maybe it=20 can happen in FreeBSD systems under transient overload conditions. It could happen in RTEMS, if we have an extremely long boot time, since=20 during boot interrupts are disabled. >=20 > Your question is more like "under which conditions we switch to use > tc_large_delta path in bintime_off()?" Then it is mostly right, that > long intervals between tc_windup() calls would trigger it, and it seems > that indeed it is around 0.5 sec. Yes, this was the question. I think the initialization value should be 50000: diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 81d373b3b1d0..a4792e31abd4 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -87,7 +87,7 @@ static struct timehands ths[16] =3D { [0] =3D { .th_counter =3D &dummy_timecounter, .th_scale =3D (uint64_t)-1 / 1000000, - .th_large_delta =3D 1000000, + .th_large_delta =3D 500000, .th_offset =3D { .sec =3D 1 }, .th_generation =3D 1, }, >=20 > If you have a controlled environment, just skip some tc_windup() calls > to see. Yes, I can also use a software timecounter for these tests. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee>