From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <462DE28F.5010400@domain.hid> Date: Tue, 24 Apr 2007 12:57:19 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <45F68258.5040603@domain.hid> <460AB8FF.5060904@domain.hid> <460B21C0.7090200@domain.hid> <460B7FDF.8030100@domain.hid> <460BECFD.2030003@domain.hid> <460C0C7D.7000001@domain.hid> <17964.64208.463335.611234@domain.hid> <462DC874.20303@domain.hid> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Latencies due to RT-Socket-CAN register accesses List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: roland Tollenaar Cc: Xenomai-help@domain.hid, Jan Kiszka roland Tollenaar wrote: > Hi > >> Two conclusions: >> >> - You are running your kernel as i586 without TSC support - suboptimal, >> costs you a few micros. > I am aware of this. For the current machine I will stick to this. > > >> - The reported latency perfectly matches the trace, nothing >> pathological there. The trace looks like this: Timer fired, >> measurement task woken up, two interrupts squeeze themselves between >> wakeup and time stamp acquisition. All sane. > Is it not a bit strange that a machine as fast as this one is supposed > to be give worse latencies than much slower machines. Are the 2 > interrupts causing the latency? Yes, what puzzels me is actually the high min latency of more than 24us: == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period, priority 99) RTH|--lat min|---lat avg|-----lat max|-overrun|----lat best|---lat worst RTD| 24.304| 35.199| 65.371| 0| 24.304| 65.371 Can the TSC cause such high delays? And what is the output of "/proc/xenomai/latency"? Wolfgang.