> 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. OK. > > Cyclictest on the same machine gives me a max deviation of about 7uS, > so I guess my timers (hrt) are functioning alright. Out of how much? What is the range of the timer. > 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. Yes, but the cyclic test doesnot match with this result. Both are in the negative. How have you tested the patch. > > 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 > > > -- > http://www.prady.in > -- -- Sujit K M blog(http://kmsujit.blogspot.com/) -- 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