[Xenomai-core] [BUG] timer issues with SVN head

[Xenomai-core] [BUG] timer issues with SVN head

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

Hi,

just to save my current finding and maybe trigger some feedback:

We just tried both 2.3.x-SVN and trunk with our "reference robot". While
2.3.x behaves fine, weird things happened with trunk /wrt some serial
device. We saw reception timeouts and no serial IRQs.

So I fired up a second box with plain latency test (all the latest: SVN,
2.6.19.2, ipipe-i386-1.6-06):

> root@domain.hid :/root# latency      
> == 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| 1299105.405| 1505168.638|  -14316.105|    3671| 1299105.405|  -14316.105
> RTD| 1220704.831| 1779065.782|-1220608.470|    7345| 1220704.831|-1220608.470
> RTD|   14316.105|-1760409.537|-1554398.542|   11018| 1220704.831|-1220608.470
> RTD|   14316.105| 2122222.174|-1966597.124|   14691| 1220704.831|-1220608.470
> RTD|   14316.105| 1709930.735| 1916083.739|   18372| 1220704.831|-1220608.470

Houston, I think we have a problem.

Periodic mode is on, but all skins are using the master time base. I
suspect some time conversion issues. I'll try to dig deeper -- later.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] timer issues with SVN head

[Philippe Gerum]

On Thu, 2007-02-01 at 18:39 +0100, Jan Kiszka wrote:
> Hi,
> 
> just to save my current finding and maybe trigger some feedback:
> 
> We just tried both 2.3.x-SVN and trunk with our "reference robot". While
> 2.3.x behaves fine, weird things happened with trunk /wrt some serial
> device. We saw reception timeouts and no serial IRQs.
> 
> So I fired up a second box with plain latency test (all the latest: SVN,
> 2.6.19.2, ipipe-i386-1.6-06):
> 
> > root@domain.hid :/root# latency      
> > == 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| 1299105.405| 1505168.638|  -14316.105|    3671| 1299105.405|  -14316.105

I can't reproduce this here, so this is likely an untested configuration
issue again.

.config welcome. TIA,

-- 
Philippe.

Re: [Xenomai-core] [BUG] timer issues with SVN head

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

Philippe Gerum wrote:

> On Thu, 2007-02-01 at 18:39 +0100, Jan Kiszka wrote:
>   
>> Hi,
>>
>> just to save my current finding and maybe trigger some feedback:
>>
>> We just tried both 2.3.x-SVN and trunk with our "reference robot". While
>> 2.3.x behaves fine, weird things happened with trunk /wrt some serial
>> device. We saw reception timeouts and no serial IRQs.
>>
>> So I fired up a second box with plain latency test (all the latest: SVN,
>> 2.6.19.2, ipipe-i386-1.6-06):
>>
>>     
>>> root@domain.hid :/root# latency      
>>> == 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| 1299105.405| 1505168.638|  -14316.105|    3671| 1299105.405|  -14316.105
>>>       
>
> I can't reproduce this here, so this is likely an untested configuration
> issue again.
>
> .config welcome. TIA,
>
>   
What about a patch? =8)

--- include/nucleus/timebase.h  (revision 2094)
+++ include/nucleus/timebase.h  (working copy)
@@ -183,7 +183,7 @@ static inline xnticks_t xntbase_get_jiff
 
 static inline xnticks_t xntbase_get_rawclock(xntbase_t *base)
 {
-	return xntbase_get_jiffies(base);
+	return xntbase_periodic_p(base) ? base->jiffies : xnarch_get_cpu_tsc();
 }
 
 int xntbase_alloc(const char *name,


This fixes at least one symptom I found, the broken latency test, but we still need
to re-check the serial device scenario on the robot. That will take longer
unfortunately.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] timer issues with SVN head

[Philippe Gerum]

On Fri, 2007-02-02 at 13:56 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
> > On Thu, 2007-02-01 at 18:39 +0100, Jan Kiszka wrote:
> >   
> >> Hi,
> >>
> >> just to save my current finding and maybe trigger some feedback:
> >>
> >> We just tried both 2.3.x-SVN and trunk with our "reference robot". While
> >> 2.3.x behaves fine, weird things happened with trunk /wrt some serial
> >> device. We saw reception timeouts and no serial IRQs.
> >>
> >> So I fired up a second box with plain latency test (all the latest: SVN,
> >> 2.6.19.2, ipipe-i386-1.6-06):
> >>
> >>     
> >>> root@domain.hid :/root# latency      
> >>> == 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| 1299105.405| 1505168.638|  -14316.105|    3671| 1299105.405|  -14316.105
> >>>       
> >
> > I can't reproduce this here, so this is likely an untested configuration
> > issue again.
> >
> > .config welcome. TIA,
> >
> >   
> What about a patch? =8)
> 

Even better, thanks. I should really work with
CONFIG_XENO_OPT_TIMING_PERIODIC enabled sometimes...

> --- include/nucleus/timebase.h  (revision 2094)
> +++ include/nucleus/timebase.h  (working copy)
> @@ -183,7 +183,7 @@ static inline xnticks_t xntbase_get_jiff
>  
>  static inline xnticks_t xntbase_get_rawclock(xntbase_t *base)
>  {
> -	return xntbase_get_jiffies(base);
> +	return xntbase_periodic_p(base) ? base->jiffies : xnarch_get_cpu_tsc();
>  }
>  
>  int xntbase_alloc(const char *name,
> 
> 
> This fixes at least one symptom I found, the broken latency test, but we still need
> to re-check the serial device scenario on the robot. That will take longer
> unfortunately.
> 
> Jan
> 
> 
-- 
Philippe.