From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <496F3F32.4090307@domain.hid> Date: Thu, 15 Jan 2009 13:50:42 +0000 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <496DEB16.5060803@domain.hid> <496DEE61.80706@domain.hid> <496DEFEA.5000709@domain.hid> <496DF150.8050606@domain.hid> <496F36EE.1070305@domain.hid> <496F3A6F.4060402@domain.hid> In-Reply-To: <496F3A6F.4060402@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] Clock drift. List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: Xenomai core Gilles Chanteperdrix wrote: > Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >>> Gilles Chanteperdrix wrote: >>>> Philippe Gerum wrote: >>>>> Gilles Chanteperdrix wrote: >>>>>> Hi, >>>>>> >>>>>> I run clocktest on a system here, not running NTP, using >>>>>> CONFIG_GENERIC_CLOCKEVENT, with a systematic drift of 3us/s. How can >>>>>> this happen? Does it come from the error due to the multiply and shift >>>>>> used for tsc to/from ns conversions ? >>>>>> >>>>> - ipipe_request_tickdev() returning a timer freq we don't like? >>>> Well, I would expect ipipe_request_tickdev() to return the same >>>> frequency as the one used by Linux. >>>> >>> Yes it does. But this value is used by Xenomai code. >> It turns out that the frequency used to convert tsc to ns is the cpu >> frequency (which is kind of a misnomer, since your emulated tsc on arm >> does not run at cpu frequency), which is computed though it should have >> the same value as the timer frequency but is suject to rounding errors. > > The timer frequency is as approximate as the cpu frequency, > ipipe_request_tickdev does this: > > freq = (1000000000ULL * evtdev->mult) >> evtdev->shift; > *tmfreq = (unsigned long)freq; > Ok. But linux uses the same approximate frequency. So, the error is somewhere else. -- Gilles.