Re: mq_timedrecieve timeout accuracy

[John Kacur <jkacur@gmail.com>]

On Wed, Mar 24, 2010 at 1:27 PM, Pradyumna Sampath <pradysam@gmail.com> wrote:
> Hi,
>
> We are dealing with an application that is a fairly heavy user of
> POSIX message queues. While running this application I seemed to have
> stumbled upon the fact that the timeout in the mq_timedrecieve is
> innaccurate to the tune of a more than 5-6 miliseconds and that it is
> fairly consistent even at its highest priority.
>
> Cyclictest on the same machine gives me a max deviation of about 7uS,
> so I guess my timers (hrt) are functioning alright.
>
> Here is a small program I hacked up from the LTP sources to
> demonstrate this behaviour (attached). I ran this on a dual core
> 2.5Ghz cpu and a uniprocessor 1.5Ghz cpu (cpuinfo below). On the
> dual-core I can see that its off by 1-2 miliseconds but on the 1.5 Ghz
> celeron its off by 6-8 miliseconds sometimes.
>
> kernel version: 2.6.33.1-rt10
>
> Usage: ./send_rev_2 <timeout_in_miliseconds>
>
> $ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 13
> model name      : Intel(R) Celeron(R) M processor         1.50GHz
> stepping        : 8
> cpu MHz         : 1500.111
> cache size      : 1024 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 2
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
> clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up bts
>
> Also attaached is my .config.
>
> thanks in advance
> regards
> /prady
>
>

Could you try using CLOCK_MONOTONIC instead of CLOCK_REALTIME in the
clock_gettime() call?

CLOCK_REALTIME isn't actually for real-time, it is the "real" time, which can be
adjusted if you sync with ntp servers for example.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html