On Wed, Mar 24, 2010 at 1:27 PM, Pradyumna Sampath <pradysam@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
