From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4666B879.7000907@domain.hid> Date: Wed, 06 Jun 2007 15:36:57 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <46649F7E.3060104@domain.hid> <46651F7D.9090702@domain.hid> <4666AD52.1050101@domain.hid> <4666B6AE.2070209@domain.hid> In-Reply-To: <4666B6AE.2070209@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AFF46BA6F502100607BE61A" Sender: jan.kiszka@domain.hid Subject: Re: [Xenomai-core] [PATCH-STACK] Updates, timerstats, rtdm-timers List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai-core This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AFF46BA6F502100607BE61A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Jan Kiszka wrote: >> >>> Jan Kiszka wrote: >>> ... >>> >>>> fast-tsc-to-ns-v2.patch >>>> >>>> [Rebased, improved rounding of least significant digit] >>> Rounding in the fast path for the sake of the last digit was silly. >>> Instead, I'm now addressing the ugly interval printing via >>> xnarch_precise_tsc_to_ns when converting the timer interval back into= >>> nanos. -v3 incorporating this has just been uploaded. >>> >> >> After noticing yesterday that even unpatched Xenomai sometimes convert= s >> inaccurately when showing small timer intervals under /proc, I just go= t >> an idea how to address this beautification issue even better: -v4 now >> rounds up in the slow, precise tsc-to-ns path, see >> >> http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/fast-tsc-to-ns-= v4.patch >=20 > I am the one who decided of the rounding behaviour of llimd, RTAI > version had the same rounding policy as the one you propose, and I made= > it for the following reasons: > - rouding towards 0 is the policy used by the C language, so doing this= > for llimd made it consistent with what one expects from C code; > - values computed by llimd are used to program timers, and we prefer th= e > timer to be programmed for a too short value than for a too long value.= That's OK, I agree. In my patch for i386, this rounding is only relevant for display purposes. It's just to help me finding the expected period T of my task in /proc instead of T-1 sometimes. Beautification. All we need for other archs is xnarch_tsc_to_ns according to the old scheme. Will rework this. Jan --------------enig9AFF46BA6F502100607BE61A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGZrh5niDOoMHTA+kRAkYRAJ4kKNNTFZBfyZ2H9g30nsGNc5utVQCcCKUv jvGwdOPLPCnN3xjj5/UVoTk= =Li1+ -----END PGP SIGNATURE----- --------------enig9AFF46BA6F502100607BE61A--