[Xenomai-core] RTDM and Timer functions

[Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Hi Jan,

I'm still concerned about the future of RTDM and timer functions. I think 
there should be some function for starting the timer manually, since the 
automatic feature don't work great for RTDM drivers.

It is not nice to have to run the latency (or any other) program for starting 
the timer before I can load my driver. And it is not suffice to run it once I 
booted. After I open/close my rtdm device and reload my driver the problem 
will occur again and I'll have to re-run the latency program.

Do you have any plans to correct this undesirable behaviour?

I don't even have an idea why the timer stops once it is started... Actually 
I'm not sure why does rtdm_clock_read should depend on the xenomai timer. At 
least, I think there should be a note in the rtdm_clock_read documentation 
stating that it only works after the timer has been started.

Best Regards,

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Hi Jan,
> 
> I'm still concerned about the future of RTDM and timer functions. I think 
> there should be some function for starting the timer manually, since the 
> automatic feature don't work great for RTDM drivers.
> 
> It is not nice to have to run the latency (or any other) program for starting 
> the timer before I can load my driver. And it is not suffice to run it once I 
> booted. After I open/close my rtdm device and reload my driver the problem 
> will occur again and I'll have to re-run the latency program.
> 

Sorry I don't see the problem here.

# modprobe xeno_nucleus; cat /proc/xenomai/timer
status=off:setup=1392:tickval=0:jiffies=0

# modprobe xeno_rtdm; cat /proc/xenomai/timer
status=oneshot:setup=1392:tickval=1:jiffies=8113917792696

So the timer is running right since when rtdm is loaded?!

And that simple heartbeat rtdm example on my rt-addon homepage now
cleanly runs even without any further helper to start some timer.

> Do you have any plans to correct this undesirable behaviour?
> 
> I don't even have an idea why the timer stops once it is started... Actually 
> I'm not sure why does rtdm_clock_read should depend on the xenomai timer. At 
> least, I think there should be a note in the rtdm_clock_read documentation 
> stating that it only works after the timer has been started.
> 
> Best Regards,
> 
> Rodrigo.
> 

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Quinta 09 Mar=E7o 2006 17:33, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Hi Jan,
>>
>> I'm still concerned about the future of RTDM and timer functions. I think
>> there should be some function for starting the timer manually, since the
>> automatic feature don't work great for RTDM drivers.
>>
>> It is not nice to have to run the latency (or any other) program for
>> starting the timer before I can load my driver. And it is not suffice to
>> run it once I booted. After I open/close my rtdm device and reload my
>> driver the problem will occur again and I'll have to re-run the latency
>> program.
>
>Sorry I don't see the problem here.
>
># modprobe xeno_nucleus; cat /proc/xenomai/timer
>status=3Doff:setup=3D1392:tickval=3D0:jiffies=3D0
>
># modprobe xeno_rtdm; cat /proc/xenomai/timer
>status=3Doneshot:setup=3D1392:tickval=3D1:jiffies=3D8113917792696
>
>So the timer is running right since when rtdm is loaded?!

Yes, here too.

>And that simple heartbeat rtdm example on my rt-addon homepage now
>cleanly runs even without any further helper to start some timer.

Yes, here too. You are right, once the timer is in oneshot mode. My driver=
=20
loads correctly without the helper. Then I start a user application that=20
changes the timer to periodic mode and uses my driver. When I reload my=20
driver, now in periodic mode, the problem raises.

It seems, there is no problem when the timer is set to oneshot. But when=20
turning it to periodic, at least one of rtdm_task_busy_sleep() or=20
rtdm_clock_read() doesn't seem to work. See below:

cat /proc/xenomai/timer
  status=3Dperiodic:setup=3D188:tickval=3D100000:jiffies=3D19972453

start_time =3D rtdm_clock_read();
rtdm_task_busy_sleep(84000);
temp_time =3D rtdm_clock_read();
rtdm_printk(KERN_INFO "Should be near 84000: %u\n", (unsigned int)
                   (temp_time-start_time));

Sometimes the result is "Should be near 84000: 100000", that is kind of=20
correct, since the tickval is 100000, although I think that those functions=
=20
in the RTDM driver context should be independent of the tick value set by t=
he=20
user program... Maybe using oneshot in the driver calls and periodic in the=
=20
application... I really don't know what would be the best approach here...

But the worst case is that sometimes I get "Should be near 84000: 0" which=
=20
clearly is a incorrect result.

After I run the latency program, the timer turns to be oneshot again and=20
everything goes right.

What can I do to solve this problem?

Thanks in advance,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Hi Jan,
>>>
>>> I'm still concerned about the future of RTDM and timer functions. I think
>>> there should be some function for starting the timer manually, since the
>>> automatic feature don't work great for RTDM drivers.
>>>
>>> It is not nice to have to run the latency (or any other) program for
>>> starting the timer before I can load my driver. And it is not suffice to
>>> run it once I booted. After I open/close my rtdm device and reload my
>>> driver the problem will occur again and I'll have to re-run the latency
>>> program.
>> Sorry I don't see the problem here.
>>
>> # modprobe xeno_nucleus; cat /proc/xenomai/timer
>> status=off:setup=1392:tickval=0:jiffies=0
>>
>> # modprobe xeno_rtdm; cat /proc/xenomai/timer
>> status=oneshot:setup=1392:tickval=1:jiffies=8113917792696
>>
>> So the timer is running right since when rtdm is loaded?!
> 
> Yes, here too.
> 
>> And that simple heartbeat rtdm example on my rt-addon homepage now
>> cleanly runs even without any further helper to start some timer.
> 
> Yes, here too. You are right, once the timer is in oneshot mode. My driver 
> loads correctly without the helper. Then I start a user application that 
> changes the timer to periodic mode and uses my driver. When I reload my 
> driver, now in periodic mode, the problem raises.

What happens if you make the periodic timer the default one in the
kernel configuration?

> 
> It seems, there is no problem when the timer is set to oneshot. But when 
> turning it to periodic, at least one of rtdm_task_busy_sleep() or 
> rtdm_clock_read() doesn't seem to work. See below:
> 
> cat /proc/xenomai/timer
>   status=periodic:setup=188:tickval=100000:jiffies=19972453
> 
> start_time = rtdm_clock_read();
> rtdm_task_busy_sleep(84000);
> temp_time = rtdm_clock_read();
> rtdm_printk(KERN_INFO "Should be near 84000: %u\n", (unsigned int)
>                    (temp_time-start_time));
> 
> Sometimes the result is "Should be near 84000: 100000", that is kind of 
> correct, since the tickval is 100000, although I think that those functions 
> in the RTDM driver context should be independent of the tick value set by the 
> user program... Maybe using oneshot in the driver calls and periodic in the 
> application... I really don't know what would be the best approach here...

rtdm_clock_read always uses the nucleus clock. Using something different
(e.g. always TSC) would break applications specifying absolute times
derived from the return values of other skins' functions.

> 
> But the worst case is that sometimes I get "Should be near 84000: 0" which 
> clearly is a incorrect result.

That might be a rounding issue somewhere, as the sleep than clearly did
not wait at least one tick. Will have to check this when time permits.

> 
> After I run the latency program, the timer turns to be oneshot again and 
> everything goes right.
> 
> What can I do to solve this problem?

Use oneshot mode in the meantime - or even longer ;). Why do you prefer
periodic mode for your application? Another workaround: reduce the tick
interval.

> 
> Thanks in advance,
> 
> Rodrigo.
> 

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Sexta 10 Mar=E7o 2006 15:32, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Em Quinta 09 Mar=E7o 2006 17:33, Jan Kiszka escreveu:
>>> Rodrigo Rosenfeld Rosas wrote:
>>>> Hi Jan,
>>>>
>>>> I'm still concerned about the future of RTDM and timer functions. I
>>>> think there should be some function for starting the timer manually,
>>>> since the automatic feature don't work great for RTDM drivers.
>>>>
>>>> It is not nice to have to run the latency (or any other) program for
>>>> starting the timer before I can load my driver. And it is not suffice =
to
>>>> run it once I booted. After I open/close my rtdm device and reload my
>>>> driver the problem will occur again and I'll have to re-run the latency
>>>> program.
>>>
>>> Sorry I don't see the problem here.
>>>
>>> # modprobe xeno_nucleus; cat /proc/xenomai/timer
>>> status=3Doff:setup=3D1392:tickval=3D0:jiffies=3D0
>>>
>>> # modprobe xeno_rtdm; cat /proc/xenomai/timer
>>> status=3Doneshot:setup=3D1392:tickval=3D1:jiffies=3D8113917792696
>>>
>>> So the timer is running right since when rtdm is loaded?!
>>
>> Yes, here too.
>>
>>> And that simple heartbeat rtdm example on my rt-addon homepage now
>>> cleanly runs even without any further helper to start some timer.
>>
>> Yes, here too. You are right, once the timer is in oneshot mode. My driv=
er
>> loads correctly without the helper. Then I start a user application that
>> changes the timer to periodic mode and uses my driver. When I reload my
>> driver, now in periodic mode, the problem raises.
>
>What happens if you make the periodic timer the default one in the
>kernel configuration?

The same behaviour.

>> It seems, there is no problem when the timer is set to oneshot. But when
>> turning it to periodic, at least one of rtdm_task_busy_sleep() or
>> rtdm_clock_read() doesn't seem to work. See below:
>>
>> cat /proc/xenomai/timer
>>   status=3Dperiodic:setup=3D188:tickval=3D100000:jiffies=3D19972453
>>
>> start_time =3D rtdm_clock_read();
>> rtdm_task_busy_sleep(84000);
>> temp_time =3D rtdm_clock_read();
>> rtdm_printk(KERN_INFO "Should be near 84000: %u\n", (unsigned int)
>>                    (temp_time-start_time));
>>
>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>> correct, since the tickval is 100000, although I think that those
>> functions in the RTDM driver context should be independent of the tick
>> value set by the user program... Maybe using oneshot in the driver calls
>> and periodic in the application... I really don't know what would be the
>> best approach here...
>
>rtdm_clock_read always uses the nucleus clock.

Do you mean that rtdm_clock_read will always read a multiple of tickval val=
ue?=20
If so, I think it would be good to make it clear on its documentation. "Get=
=20
system time" isn't enough for getting this information, IMHO.

>Using something different=20
>(e.g. always TSC) would break applications specifying absolute times
>derived from the return values of other skins' functions.

I did not understand. I'm talking about using TSC only for these two=20
functions. I can not see why shouldn't it be possible... I mean, I think th=
e=20
driver should not depend on the userspace program timer for these two=20
functions.

>> But the worst case is that sometimes I get "Should be near 84000: 0" whi=
ch
>> clearly is a incorrect result.
>
>That might be a rounding issue somewhere, as the sleep than clearly did
>not wait at least one tick. Will have to check this when time permits.
>
>> After I run the latency program, the timer turns to be oneshot again and
>> everything goes right.
>>
>> What can I do to solve this problem?
>
>Use oneshot mode in the meantime - or even longer ;).

That is what I'll gonna do, but I know it is not a definite solution. Since=
=20
I'm providing a framework, the user should decide which approach is better=
=20
for him/her, oneshot or periodic mode.

>Why do you prefer=20
>periodic mode for your application? Another workaround: reduce the tick
>interval.

I have some loops in my userspace programs that a common 100us tick would=20
satisfy them all. I think the overhead would be lower than using the=20
aperiodic oneshot mode... I'm not pretty sure about that. But that is not t=
he=20
question. My application is just an use case of my framework (actually I=20
didn't even started building it). The final user should decide what is the=
=20
best approach for him/her, not me. So, I would prefer that the driver be=20
independent from the timer source chosen by the user program.

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Sexta 10 Março 2006 15:32, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu:
>>>> Rodrigo Rosenfeld Rosas wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I'm still concerned about the future of RTDM and timer functions. I
>>>>> think there should be some function for starting the timer manually,
>>>>> since the automatic feature don't work great for RTDM drivers.
>>>>>
>>>>> It is not nice to have to run the latency (or any other) program for
>>>>> starting the timer before I can load my driver. And it is not suffice to
>>>>> run it once I booted. After I open/close my rtdm device and reload my
>>>>> driver the problem will occur again and I'll have to re-run the latency
>>>>> program.
>>>> Sorry I don't see the problem here.
>>>>
>>>> # modprobe xeno_nucleus; cat /proc/xenomai/timer
>>>> status=off:setup=1392:tickval=0:jiffies=0
>>>>
>>>> # modprobe xeno_rtdm; cat /proc/xenomai/timer
>>>> status=oneshot:setup=1392:tickval=1:jiffies=8113917792696
>>>>
>>>> So the timer is running right since when rtdm is loaded?!
>>> Yes, here too.
>>>
>>>> And that simple heartbeat rtdm example on my rt-addon homepage now
>>>> cleanly runs even without any further helper to start some timer.
>>> Yes, here too. You are right, once the timer is in oneshot mode. My driver
>>> loads correctly without the helper. Then I start a user application that
>>> changes the timer to periodic mode and uses my driver. When I reload my
>>> driver, now in periodic mode, the problem raises.
>> What happens if you make the periodic timer the default one in the
>> kernel configuration?
> 
> The same behaviour.
> 
>>> It seems, there is no problem when the timer is set to oneshot. But when
>>> turning it to periodic, at least one of rtdm_task_busy_sleep() or
>>> rtdm_clock_read() doesn't seem to work. See below:
>>>
>>> cat /proc/xenomai/timer
>>>   status=periodic:setup=188:tickval=100000:jiffies=19972453
>>>
>>> start_time = rtdm_clock_read();
>>> rtdm_task_busy_sleep(84000);
>>> temp_time = rtdm_clock_read();
>>> rtdm_printk(KERN_INFO "Should be near 84000: %u\n", (unsigned int)
>>>                    (temp_time-start_time));
>>>
>>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>>> correct, since the tickval is 100000, although I think that those
>>> functions in the RTDM driver context should be independent of the tick
>>> value set by the user program... Maybe using oneshot in the driver calls
>>> and periodic in the application... I really don't know what would be the
>>> best approach here...
>> rtdm_clock_read always uses the nucleus clock.
> 
> Do you mean that rtdm_clock_read will always read a multiple of tickval value? 
> If so, I think it would be good to make it clear on its documentation. "Get 
> system time" isn't enough for getting this information, IMHO.

Please have a look at the two sentences of documentation I added to SVN
(didn't make it into the release).

I gave your scenario a try, and I was able to verify that
rtdm_task_busy_sleep works correctly under both timer modes. Indeed, the
behaviour of rtdm_clock_read may have been confusing due to lacking
information, but it was also correct.

> 
>> Using something different 
>> (e.g. always TSC) would break applications specifying absolute times
>> derived from the return values of other skins' functions.
> 
> I did not understand. I'm talking about using TSC only for these two 
> functions. I can not see why shouldn't it be possible... I mean, I think the 
> driver should not depend on the userspace program timer for these two 
> functions.
> 
>>> But the worst case is that sometimes I get "Should be near 84000: 0" which
>>> clearly is a incorrect result.
>> That might be a rounding issue somewhere, as the sleep than clearly did
>> not wait at least one tick. Will have to check this when time permits.
>>
>>> After I run the latency program, the timer turns to be oneshot again and
>>> everything goes right.
>>>
>>> What can I do to solve this problem?
>> Use oneshot mode in the meantime - or even longer ;).
> 
> That is what I'll gonna do, but I know it is not a definite solution. Since 
> I'm providing a framework, the user should decide which approach is better 
> for him/her, oneshot or periodic mode.
> 
>> Why do you prefer 
>> periodic mode for your application? Another workaround: reduce the tick
>> interval.
> 
> I have some loops in my userspace programs that a common 100us tick would 
> satisfy them all. I think the overhead would be lower than using the 
> aperiodic oneshot mode... I'm not pretty sure about that. But that is not the 
> question. My application is just an use case of my framework (actually I 
> didn't even started building it). The final user should decide what is the 
> best approach for him/her, not me. So, I would prefer that the driver be 
> independent from the timer source chosen by the user program.
> 

I see your point. But when the user decides to pick a low-precision
timer source to reduce overhead, (s)he has to live with the side-effect.
There is no such thing like "user vs. kernel" timer source - it is
always the same. Thus, also the precision of time stamping in drivers
suffers.

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Segunda 13 Mar=E7o 2006 08:48, voc=EA escreveu:
>...
>
>> Do you mean that rtdm_clock_read will always read a multiple of tickval
>> value? If so, I think it would be good to make it clear on its
>> documentation. "Get system time" isn't enough for getting this
>> information, IMHO.
>
>Please have a look at the two sentences of documentation I added to SVN
>(didn't make it into the release).

I did.

>I gave your scenario a try, and I was able to verify that
>rtdm_task_busy_sleep works correctly under both timer modes.

I cannot understand yet why it doesn't occur here, but I'll investigate if I
have the time to.

>Indeed, the
>behaviour of rtdm_clock_read may have been confusing due to lacking
>information, but it was also correct.

I liked the note, but I would include another one:
"When in periodic mode, the time resolution is limited to the tick set to t=
he
system timer" or something like. Maybe:
"[If using periodic mode, note that ]The time resolution is limited by the
system timer tick". Well my English is not that good, so I think you could
give a better description, but I really need this note is very useful.

>>> Using something different
>>> (e.g. always TSC) would break applications specifying absolute times
>>> derived from the return values of other skins' functions.
>>
>> I did not understand. I'm talking about using TSC only for these two
>> functions. I can not see why shouldn't it be possible... I mean, I think
>> the driver should not depend on the userspace program timer for these two
>> functions.
>>
>>>> But the worst case is that sometimes I get "Should be near 84000: 0"
>>>> which clearly is a incorrect result.
>>>
>>> That might be a rounding issue somewhere, as the sleep than clearly did
>>> not wait at least one tick. Will have to check this when time permits.
>>>
>>>> After I run the latency program, the timer turns to be oneshot again a=
nd
>>>> everything goes right.
>>>>
>>>> What can I do to solve this problem?
>>>
>>> Use oneshot mode in the meantime - or even longer ;).
>>
>> That is what I'll gonna do, but I know it is not a definite solution.
>> Since I'm providing a framework, the user should decide which approach is
>> better for him/her, oneshot or periodic mode.
>>
>>> Why do you prefer
>>> periodic mode for your application? Another workaround: reduce the tick
>>> interval.
>>
>> I have some loops in my userspace programs that a common 100us tick would
>> satisfy them all. I think the overhead would be lower than using the
>> aperiodic oneshot mode... I'm not pretty sure about that. But that is not
>> the question. My application is just an use case of my framework (actual=
ly
>> I didn't even started building it). The final user should decide what is
>> the best approach for him/her, not me. So, I would prefer that the driver
>> be independent from the timer source chosen by the user program.
>
>I see your point. But when the user decides to pick a low-precision
>timer source to reduce overhead, (s)he has to live with the side-effect.
>There is no such thing like "user vs. kernel" timer source - it is
>always the same. Thus, also the precision of time stamping in drivers
>suffers.

Ok, I'll document this on my framework.

Thanks for the support,

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

____________________________________________________________
Em Segunda 13 Mar=E7o 2006 11:54, Rodrigo Rosenfeld Rosas escreveu:

>I liked the note, but I would include another one:
>"When in periodic mode, the time resolution is limited to the tick set to
> the system timer" or something like. Maybe:
>"[If using periodic mode, note that ]The time resolution is limited by the
>system timer tick". Well my English is not that good, so I think you could
>give a better description, but I really need this note is very useful.

Actually, I would add them to rtdm_task_busy_sleep() documentation too.

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Sorry Jan, I was looking at a different documentation. Now I read the right=
=20
one. It is good. But I didn't understand why didn't you keep the latter not=
e:=20
"The nucleus timer has to be started to obtain valid results." I would=20
include it before the other note.

Thank you,

Rodrigo.

____________________________________________________________
Em Segunda 13 Mar=E7o 2006 14:15, Rodrigo Rosenfeld Rosas escreveu:

>____________________________________________________________
>
>Em Segunda 13 Mar=E7o 2006 11:54, Rodrigo Rosenfeld Rosas escreveu:
>>I liked the note, but I would include another one:
>>"When in periodic mode, the time resolution is limited to the tick set to
>> the system timer" or something like. Maybe:
>>"[If using periodic mode, note that ]The time resolution is limited by the
>>system timer tick". Well my English is not that good, so I think you could
>>give a better description, but I really need this note is very useful.
>
>Actually, I would add them to rtdm_task_busy_sleep() documentation too.
>
>Rodrigo.
>
>
>_______________________________________________________
>Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora!
>http://br.acesso.yahoo.com
>
>
>_______________________________________________
>Xenomai-core mailing list
>Xenomai-core@domain.hid
>https://mail.gna.org/listinfo/xenomai-core

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Sorry Jan, I was looking at a different documentation. Now I read the right 
> one. It is good. But I didn't understand why didn't you keep the latter note: 
> "The nucleus timer has to be started to obtain valid results." I would 
> include it before the other note.
> 

Well, it's no longer relevant for Xenomai: you can't load a driver
without the timer being started - loading xeno_rtdm will do this.

On the other hand, you are right when considering RTAI where you still
face this obstacle. I will re-introduce the note below, but the strategy
will remain that it's up to the user (application) to resolve this.

"The system timer has to be started to obtain valid results. If this
happens automatically or is controlled by the application depends on the
RTDM host environment, see related documentation of the real-time Linux
extension."

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Segunda 13 Mar=E7o 2006 15:24, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Sorry Jan, I was looking at a different documentation. Now I read the
>> right one. It is good. But I didn't understand why didn't you keep the
>> latter note: "The nucleus timer has to be started to obtain valid
>> results." I would include it before the other note.
>
>Well, it's no longer relevant for Xenomai: you can't load a driver
>without the timer being started - loading xeno_rtdm will do this.
>
>On the other hand, you are right when considering RTAI where you still
>face this obstacle. I will re-introduce the note below, but the strategy
>will remain that it's up to the user (application) to resolve this.
>
>"The system timer has to be started to obtain valid results. If this
>happens automatically or is controlled by the application depends on the
>RTDM host environment, see related documentation of the real-time Linux
>extension."

I would add a little, but significant comment with:
"The system timer has to be started to obtain valid results. If this
happens automatically (as it does on Xenomai) or is controlled by the=20
application depends on the RTDM host environment, see related documentation=
=20
of the real-time Linux extension."

Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Actually, I noted a minor typo error in the documentation:

" of the this service" should be " of this service"

Best Regards,

Rodrigo.
____________________________________________________________
Em Segunda 13 Mar=E7o 2006 14:58, Rodrigo Rosenfeld Rosas escreveu:

>Sorry Jan, I was looking at a different documentation. Now I read the right
>one. It is good. But I didn't understand why didn't you keep the latter
> note: "The nucleus timer has to be started to obtain valid results." I
> would include it before the other note.
>
>Thank you,
>
>Rodrigo.
>
>____________________________________________________________
>
>Em Segunda 13 Mar=E7o 2006 14:15, Rodrigo Rosenfeld Rosas escreveu:
>>____________________________________________________________
>>
>>Em Segunda 13 Mar=E7o 2006 11:54, Rodrigo Rosenfeld Rosas escreveu:
>>>I liked the note, but I would include another one:
>>>"When in periodic mode, the time resolution is limited to the tick set to
>>> the system timer" or something like. Maybe:
>>>"[If using periodic mode, note that ]The time resolution is limited by t=
he
>>>system timer tick". Well my English is not that good, so I think you cou=
ld
>>>give a better description, but I really need this note is very useful.
>>
>>Actually, I would add them to rtdm_task_busy_sleep() documentation too.
>>
>>Rodrigo.
>>
>>
>>_______________________________________________________
>>Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora!
>>http://br.acesso.yahoo.com
>>
>>
>>_______________________________________________
>>Xenomai-core mailing list
>>Xenomai-core@domain.hid
>>https://mail.gna.org/listinfo/xenomai-core
>
>_______________________________________________________
>Yahoo! Acesso Grtis - Internet rpida e grtis. Instale o discador agora!
>http://br.acesso.yahoo.com
>
>
>_______________________________________________
>Xenomai-core mailing list
>Xenomai-core@domain.hid
>https://mail.gna.org/listinfo/xenomai-core

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] RTDM and Timer functions

[Jim Cromie]

Rodrigo Rosenfeld Rosas wrote:
> Actually, I noted a minor typo error in the documentation:
>
> " of the this service" should be " of this service"
>   

this is the kind of thing that youre encouraged to create a patch for.
Same for other doc nits - youre offering 'something-like' suggestions,
when you could almost as easily prep an actual patch with your best wording.

Also please start trimming much more agressively.
None of us need to see 3 or 4 xenomai footers, and  more yahoo ones besides.

thanks

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 13 Março 2006 08:48, você escreveu:
>> ...
>>
>>> Do you mean that rtdm_clock_read will always read a multiple of tickval
>>> value? If so, I think it would be good to make it clear on its
>>> documentation. "Get system time" isn't enough for getting this
>>> information, IMHO.
>> Please have a look at the two sentences of documentation I added to SVN
>> (didn't make it into the release).
> 
> I did.
> 
>> I gave your scenario a try, and I was able to verify that
>> rtdm_task_busy_sleep works correctly under both timer modes.
> 
> I cannot understand yet why it doesn't occur here, but I'll investigate if I
> have the time to.

I counted the loops rtdm_task_busy_sleep took, and they were quite
similar (IRQ noise aside).

> 
>> Indeed, the
>> behaviour of rtdm_clock_read may have been confusing due to lacking
>> information, but it was also correct.
> 
> I liked the note, but I would include another one:
> "When in periodic mode, the time resolution is limited to the tick set to the
> system timer" or something like. Maybe:
> "[If using periodic mode, note that ]The time resolution is limited by the
> system timer tick". Well my English is not that good, so I think you could
> give a better description, but I really need this note is very useful.

"Resolution" is the accurate term, indeed. To include what I think is
the core of your suggestions:

"The resolution of the this service depends on the system timer. In
particular, if the system timer is running in periodic mode, the return
value will be limited to multiples of the timer tick period."

Actually, the resolution based on TSC is also limited - when your CPU
has less then 1 GHz. ;)

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

>...
>"Resolution" is the accurate term, indeed. To include what I think is
>the core of your suggestions:
>...

Please, ignore this. As I've said in another message, I was reading a prior 
documentation version. It is good the way it is.

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > > Sometimes the result is "Should be near 84000: 100000", that is kind of 
 > > correct, since the tickval is 100000, although I think that those functions 
 > > in the RTDM driver context should be independent of the tick value set by the 
 > > user program... Maybe using oneshot in the driver calls and periodic in the 
 > > application... I really don't know what would be the best approach here...
 > 
 > rtdm_clock_read always uses the nucleus clock. Using something different
 > (e.g. always TSC) would break applications specifying absolute times
 > derived from the return values of other skins' functions.

Maybe adding a service to RTDM would allow users to measure short time
intervals with RTDM using the TSC ?

The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
skins have a way to do this.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Segunda 13 Mar=E7o 2006 14:25, Gilles Chanteperdrix escreveu:

>Jan Kiszka wrote:
> > > Sometimes the result is "Should be near 84000: 100000", that is kind =
of
> > > correct, since the tickval is 100000, although I think that those
> > > functions in the RTDM driver context should be independent of the tick
> > > value set by the user program... Maybe using oneshot in the driver
> > > calls and periodic in the application... I really don't know what wou=
ld
> > > be the best approach here...
> >
> > rtdm_clock_read always uses the nucleus clock. Using something different
> > (e.g. always TSC) would break applications specifying absolute times
> > derived from the return values of other skins' functions.
>
>Maybe adding a service to RTDM would allow users to measure short time
>intervals with RTDM using the TSC ?
>
>The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>skins have a way to do this.

This would fit great for my needs (and most developers I think)!

Thanks for the suggestion,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu:
> 
>> Jan Kiszka wrote:
>>>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>>>> correct, since the tickval is 100000, although I think that those
>>>> functions in the RTDM driver context should be independent of the tick
>>>> value set by the user program... Maybe using oneshot in the driver
>>>> calls and periodic in the application... I really don't know what would
>>>> be the best approach here...
>>> rtdm_clock_read always uses the nucleus clock. Using something different
>>> (e.g. always TSC) would break applications specifying absolute times
>>> derived from the return values of other skins' functions.
>> Maybe adding a service to RTDM would allow users to measure short time
>> intervals with RTDM using the TSC ?
>>
>> The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>> skins have a way to do this.
> 
> This would fit great for my needs (and most developers I think)!
> 

Will think about it. Actually, I'm not a big fan of this. It creates the
risk that someone feeds the output of this service into (incompatible)
timed RTDM services. Even worse, this would work for aperiodic mode but
fail for periodic.

We would definitely need a good name for it,
rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
adding an argument (otherwise, I would have to fix too many drivers on
my own... :-/).

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Segunda 13 Mar=E7o 2006 15:33, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Em Segunda 13 Mar=E7o 2006 14:25, Gilles Chanteperdrix escreveu:
>>> Jan Kiszka wrote:
>>>>> Sometimes the result is "Should be near 84000: 100000", that is kind =
of
>>>>> correct, since the tickval is 100000, although I think that those
>>>>> functions in the RTDM driver context should be independent of the tick
>>>>> value set by the user program... Maybe using oneshot in the driver
>>>>> calls and periodic in the application... I really don't know what wou=
ld
>>>>> be the best approach here...
>>>>
>>>> rtdm_clock_read always uses the nucleus clock. Using something differe=
nt
>>>> (e.g. always TSC) would break applications specifying absolute times
>>>> derived from the return values of other skins' functions.
>>>
>>> Maybe adding a service to RTDM would allow users to measure short time
>>> intervals with RTDM using the TSC ?
>>>
>>> The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>>> skins have a way to do this.
>>
>> This would fit great for my needs (and most developers I think)!
>
>Will think about it. Actually, I'm not a big fan of this. It creates the
>risk that someone feeds the output of this service into (incompatible)
>timed RTDM services.

Sorry, I couldn't see a practical usage of this. Could you give an example?

>Even worse, this would work for aperiodic mode but fail for periodic.

Actually it is only necessary on periodic modes as it already works for=20
aperiodic mode.

>We would definitely need a good name for it,
>rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>adding an argument (otherwise, I would have to fix too many drivers on
>my own... :-/).

That is the idea, I think. I agree that rtdm_clock_read() should be kept as=
 it=20
is (the API/definition). No body is asking you to change it. Adding=20
rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain=
=20
coherency with other skins.

Thank you for considering it.

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 13 Março 2006 15:33, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Segunda 13 Março 2006 14:25, Gilles Chanteperdrix escreveu:
>>>> Jan Kiszka wrote:
>>>>>> Sometimes the result is "Should be near 84000: 100000", that is kind of
>>>>>> correct, since the tickval is 100000, although I think that those
>>>>>> functions in the RTDM driver context should be independent of the tick
>>>>>> value set by the user program... Maybe using oneshot in the driver
>>>>>> calls and periodic in the application... I really don't know what would
>>>>>> be the best approach here...
>>>>> rtdm_clock_read always uses the nucleus clock. Using something different
>>>>> (e.g. always TSC) would break applications specifying absolute times
>>>>> derived from the return values of other skins' functions.
>>>> Maybe adding a service to RTDM would allow users to measure short time
>>>> intervals with RTDM using the TSC ?
>>>>
>>>> The native (rt_timer_tsc()) and posix (clock_gettime(CLOCK_MONOTONIC))
>>>> skins have a way to do this.
>>> This would fit great for my needs (and most developers I think)!
>> Will think about it. Actually, I'm not a big fan of this. It creates the
>> risk that someone feeds the output of this service into (incompatible)
>> timed RTDM services.
> 
> Sorry, I couldn't see a practical usage of this. Could you give an example?
> 
>> Even worse, this would work for aperiodic mode but fail for periodic.
> 
> Actually it is only necessary on periodic modes as it already works for 
> aperiodic mode.
> 
>> We would definitely need a good name for it,
>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>> adding an argument (otherwise, I would have to fix too many drivers on
>> my own... :-/).
> 
> That is the idea, I think. I agree that rtdm_clock_read() should be kept as it 
> is (the API/definition). No body is asking you to change it. Adding 
> rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain 
> coherency with other skins.

Thinking about this more thoroughly, a few questions popped up for me:

o When we call it rtdm_clock_read_tsc(), we should actually return the
  raw TSC values, shouln't we? But then we also need conversion
  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
  convert to nanoseconds on return? POSIX and Native are different in
  this regard.

o What would be the core rationale behind it, having a high-resolution
  time stamp? What are the primary use cases? I'm asking for this so
  that I can clearly differentiate between this new service and the
  existing one in the docs. Also, giving an abstract description would
  leave more options to the actual implementation on other archs or
  platforms.

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Segunda 13 Mar=E7o 2006 20:05, Jan Kiszka escreveu:
> ...
>>> We would definitely need a good name for it,
>>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>>> adding an argument (otherwise, I would have to fix too many drivers on
>>> my own... :-/).
>>
>> That is the idea, I think. I agree that rtdm_clock_read() should be kept
>> as it is (the API/definition). No body is asking you to change it. Adding
>> rtdm_clock_read_tsc() would be sufficient in my opinion whilst it mainta=
in
>> coherency with other skins.
>
>Thinking about this more thoroughly, a few questions popped up for me:
>
>o When we call it rtdm_clock_read_tsc(), we should actually return the
>  raw TSC values, shouln't we? But then we also need conversion
>  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>  convert to nanoseconds on return? POSIX and Native are different in
>  this regard.

I would prefer returning always ns, but both solutions would fit my needs, =
so=20
I'm not really worried about this topic.

>o What would be the core rationale behind it, having a high-resolution
>  time stamp? What are the primary use cases? I'm asking for this so
>  that I can clearly differentiate between this new service and the
>  existing one in the docs. Also, giving an abstract description would
>  leave more options to the actual implementation on other archs or
>  platforms.

As I've said, I think that it is good to give some independency to the driv=
er,=20
at least to the time related functions, for not depending on the user chose=
n=20
timer behaviour for some delay routines. Eg, I would like to wait a specifi=
ed=20
amount of us before testing some register. That is a quite normal task when=
=20
developing drivers. Another one is for timeouts on short delays. In those=20
cases, we want a good resolution, but this should be independent of the=20
user's timer choice IMO.

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
>> ...
>>>> We would definitely need a good name for it,
>>>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>>>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read() by
>>>> adding an argument (otherwise, I would have to fix too many drivers on
>>>> my own... :-/).
>>> That is the idea, I think. I agree that rtdm_clock_read() should be kept
>>> as it is (the API/definition). No body is asking you to change it. Adding
>>> rtdm_clock_read_tsc() would be sufficient in my opinion whilst it maintain
>>> coherency with other skins.
>> Thinking about this more thoroughly, a few questions popped up for me:
>>
>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>  raw TSC values, shouln't we? But then we also need conversion
>>  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>  convert to nanoseconds on return? POSIX and Native are different in
>>  this regard.
> 
> I would prefer returning always ns, but both solutions would fit my needs, so 
> I'm not really worried about this topic.
> 
>> o What would be the core rationale behind it, having a high-resolution
>>  time stamp? What are the primary use cases? I'm asking for this so
>>  that I can clearly differentiate between this new service and the
>>  existing one in the docs. Also, giving an abstract description would
>>  leave more options to the actual implementation on other archs or
>>  platforms.
> 
> As I've said, I think that it is good to give some independency to the driver, 
> at least to the time related functions, for not depending on the user chosen 
> timer behaviour for some delay routines. Eg, I would like to wait a specified 
> amount of us before testing some register. That is a quite normal task when 

This is what rtdm_task_busy_sleep() already provides - independent of
the system timer.

> developing drivers. Another one is for timeouts on short delays. In those 
> cases, we want a good resolution, but this should be independent of the 
> user's timer choice IMO.

And this is something rtdm_clock_read_tsc() will obviously not be for.

Again, when the user / system administrator decided to lower the timer
resolution in favour of performance, it is not possible (and doesn't
make sense) to circumvent this decision at driver level (except for busy
waiting). So, I wonder what you plan to do with the return value of the
new function?

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Mar=E7o 2006 03:44, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Em Segunda 13 Mar=E7o 2006 20:05, Jan Kiszka escreveu:
>>> ...
>>>
>>>>> We would definitely need a good name for it,
>>>>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>>>>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read()
>>>>> by adding an argument (otherwise, I would have to fix too many drivers
>>>>> on my own... :-/).
>>>>
>>>> That is the idea, I think. I agree that rtdm_clock_read() should be ke=
pt
>>>> as it is (the API/definition). No body is asking you to change it.
>>>> Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst =
it
>>>> maintain coherency with other skins.
>>>
>>> Thinking about this more thoroughly, a few questions popped up for me:
>>>
>>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>>  raw TSC values, shouln't we? But then we also need conversion
>>>  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>>  convert to nanoseconds on return? POSIX and Native are different in
>>>  this regard.
>>
>> I would prefer returning always ns, but both solutions would fit my need=
s,
>> so I'm not really worried about this topic.
>>
>>> o What would be the core rationale behind it, having a high-resolution
>>>  time stamp? What are the primary use cases? I'm asking for this so
>>>  that I can clearly differentiate between this new service and the
>>>  existing one in the docs. Also, giving an abstract description would
>>>  leave more options to the actual implementation on other archs or
>>>  platforms.
>>
>> As I've said, I think that it is good to give some independency to the
>> driver, at least to the time related functions, for not depending on the
>> user chosen timer behaviour for some delay routines. Eg, I would like to
>> wait a specified amount of us before testing some register. That is a
>> quite normal task when
>
>This is what rtdm_task_busy_sleep() already provides - independent of
>the system timer.

I didn't know it was independent from the timer. Good to know. I think it=20
would worth enforce this statement on its documentation.

>> developing drivers. Another one is for timeouts on short delays. In those
>> cases, we want a good resolution, but this should be independent of the
>> user's timer choice IMO.
>
>And this is something rtdm_clock_read_tsc() will obviously not be for.

Please, take a look in my case. The specification recommends wait at least =
Xus=20
before testing a bit. But the time to wait is not constant, it can vary a f=
ew=20
microseconds. So, I busy wait Xus and then do some code like:

rtdm_task_busy_sleep(X*1000);
start_time =3D rtdm_clock_read[_tsc]();
do {
condition=3Dtestbit();
} while (! condition && (time_passed(start_time) < TIMEOUT));

But if the user specifies a periodic timer, with tickval=3D1ms, then my dri=
ver=20
will be too slow. I could busy wait TIMEOUT before testing, and it would be=
=20
faster then the above code in this case. But I would like to go away as soo=
n=20
as possible, ie, just after the bit has been set...

>
>Again, when the user / system administrator decided to lower the timer
>resolution in favour of performance, it is not possible (and doesn't
>make sense) to circumvent this decision at driver level (except for busy
>waiting).

But my situation is still a busy wait but written in another form.

>So, I wonder what you plan to do with the return value of the=20
>new function?

I think I've already explained myself.

Best regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Março 2006 03:44, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Segunda 13 Março 2006 20:05, Jan Kiszka escreveu:
>>>> ...
>>>>
>>>>>> We would definitely need a good name for it,
>>>>>> rtdm_clock_read_ex(<clock-id>), rtdm_clock_read_tsc(),
>>>>>> rtdm_clock_read_monotonic()? I'm not going to break rtdm_clock_read()
>>>>>> by adding an argument (otherwise, I would have to fix too many drivers
>>>>>> on my own... :-/).
>>>>> That is the idea, I think. I agree that rtdm_clock_read() should be kept
>>>>> as it is (the API/definition). No body is asking you to change it.
>>>>> Adding rtdm_clock_read_tsc() would be sufficient in my opinion whilst it
>>>>> maintain coherency with other skins.
>>>> Thinking about this more thoroughly, a few questions popped up for me:
>>>>
>>>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>>>  raw TSC values, shouln't we? But then we also need conversion
>>>>  functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>>>  convert to nanoseconds on return? POSIX and Native are different in
>>>>  this regard.
>>> I would prefer returning always ns, but both solutions would fit my needs,
>>> so I'm not really worried about this topic.
>>>
>>>> o What would be the core rationale behind it, having a high-resolution
>>>>  time stamp? What are the primary use cases? I'm asking for this so
>>>>  that I can clearly differentiate between this new service and the
>>>>  existing one in the docs. Also, giving an abstract description would
>>>>  leave more options to the actual implementation on other archs or
>>>>  platforms.
>>> As I've said, I think that it is good to give some independency to the
>>> driver, at least to the time related functions, for not depending on the
>>> user chosen timer behaviour for some delay routines. Eg, I would like to
>>> wait a specified amount of us before testing some register. That is a
>>> quite normal task when
>> This is what rtdm_task_busy_sleep() already provides - independent of
>> the system timer.
> 
> I didn't know it was independent from the timer. Good to know. I think it 
> would worth enforce this statement on its documentation.
> 
>>> developing drivers. Another one is for timeouts on short delays. In those
>>> cases, we want a good resolution, but this should be independent of the
>>> user's timer choice IMO.
>> And this is something rtdm_clock_read_tsc() will obviously not be for.
> 
> Please, take a look in my case. The specification recommends wait at least Xus 
> before testing a bit. But the time to wait is not constant, it can vary a few 
> microseconds. So, I busy wait Xus and then do some code like:
> 
> rtdm_task_busy_sleep(X*1000);
> start_time = rtdm_clock_read[_tsc]();
> do {
> condition=testbit();
> } while (! condition && (time_passed(start_time) < TIMEOUT));
> 
> But if the user specifies a periodic timer, with tickval=1ms, then my driver 
> will be too slow. I could busy wait TIMEOUT before testing, and it would be 
> faster then the above code in this case. But I would like to go away as soon 
> as possible, ie, just after the bit has been set...
> 

This is how the eepr100 driver of RTnet handles it, though RTnet would
not work very well in periodic mode. Actually, this has been ported over
from Linux where you do not have a portable API for reading the TSC, I
think.

static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
{
    int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;

    while (inb(cmd_ioaddr) != 0) {
        if (wait-- == 0)
            return 1;
        rtdm_task_busy_sleep(1000);
    }
    return 0;
}
(Hmm, BTW, de-inlining might be worth considering...)

So this works at a polling period of 1 us, but you may also reduce it,
though this would certainly degrade the accuracy further. For sure, the
accuracy is slightly worse than with your pattern. Would this matter to you?

>> Again, when the user / system administrator decided to lower the timer
>> resolution in favour of performance, it is not possible (and doesn't
>> make sense) to circumvent this decision at driver level (except for busy
>> waiting).
> 
> But my situation is still a busy wait but written in another form.
> 
>> So, I wonder what you plan to do with the return value of the 
>> new function?
> 
> I think I've already explained myself.
> 
> Best regards,
> 
> Rodrigo.
> 
> 

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Mar=E7o 2006 13:46, Jan Kiszka escreveu:

>>>> ... Another one is for timeouts on short delays. In=20
>>>> those cases, we want a good resolution, but this should be independent
>>>> of the user's timer choice IMO.
>>>
>>> And this is something rtdm_clock_read_tsc() will obviously not be for.
>>
>> Please, take a look in my case. The specification recommends wait at lea=
st
>> Xus before testing a bit. But the time to wait is not constant, it can
>> vary a few microseconds. So, I busy wait Xus and then do some code like:
>>
>> rtdm_task_busy_sleep(X*1000);
>> start_time =3D rtdm_clock_read[_tsc]();
>> do {
>> condition=3Dtestbit();
>> } while (! condition && (time_passed(start_time) < TIMEOUT));
>>
>> But if the user specifies a periodic timer, with tickval=3D1ms, then my
>> driver will be too slow. I could busy wait TIMEOUT before testing, and it
>> would be faster then the above code in this case. But I would like to go
>> away as soon as possible, ie, just after the bit has been set...
>
>This is how the eepr100 driver of RTnet handles it, though RTnet would
>not work very well in periodic mode. Actually, this has been ported over
>from Linux where you do not have a portable API for reading the TSC, I
>think.
>
>static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>{
>    int wait =3D CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>
>    while (inb(cmd_ioaddr) !=3D 0) {
>        if (wait-- =3D=3D 0)
>            return 1;
>        rtdm_task_busy_sleep(1000);
>    }
>    return 0;
>}
>(Hmm, BTW, de-inlining might be worth considering...)
>
>So this works at a polling period of 1 us, but you may also reduce it,
>though this would certainly degrade the accuracy further. For sure, the
>accuracy is slightly worse than with your pattern. Would this matter to yo=
u?

No, in my case it doesn't matter. I'll adopt this way of doing it.

Thank you,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Mar=E7o 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:

>Em Ter=E7a 14 Mar=E7o 2006 13:46, Jan Kiszka escreveu:
>>>>> ... Another one is for timeouts on short delays. In
>>>>> those cases, we want a good resolution, but this should be independent
>>>>> of the user's timer choice IMO.
>>>>
>>>> And this is something rtdm_clock_read_tsc() will obviously not be for.
>>>
>>> Please, take a look in my case. The specification recommends wait at
>>> least Xus before testing a bit. But the time to wait is not constant, it
>>> can vary a few microseconds. So, I busy wait Xus and then do some code
>>> like:
>>>
>>> rtdm_task_busy_sleep(X*1000);
>>> start_time =3D rtdm_clock_read[_tsc]();
>>> do {
>>> condition=3Dtestbit();
>>> } while (! condition && (time_passed(start_time) < TIMEOUT));
>>>
>>> But if the user specifies a periodic timer, with tickval=3D1ms, then my
>>> driver will be too slow. I could busy wait TIMEOUT before testing, and =
it
>>> would be faster then the above code in this case. But I would like to go
>>> away as soon as possible, ie, just after the bit has been set...
>>
>>This is how the eepr100 driver of RTnet handles it, though RTnet would
>>not work very well in periodic mode. Actually, this has been ported over
>>from Linux where you do not have a portable API for reading the TSC, I
>>think.
>>
>>static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>>{
>>    int wait =3D CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>>
>>    while (inb(cmd_ioaddr) !=3D 0) {
>>        if (wait-- =3D=3D 0)
>>            return 1;
>>        rtdm_task_busy_sleep(1000);
>>    }
>>    return 0;
>>}
>>(Hmm, BTW, de-inlining might be worth considering...)
>>
>>So this works at a polling period of 1 us, but you may also reduce it,
>>though this would certainly degrade the accuracy further. For sure, the
>>accuracy is slightly worse than with your pattern. Would this matter to
>> you?
>
>No, in my case it doesn't matter. I'll adopt this way of doing it.

Thinking better, I would need such a function for registering the timestamp=
 of=20
the captured frame on the irq handler...

Rodrigo.


		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
> 
>> Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
>>>>>> ... Another one is for timeouts on short delays. In
>>>>>> those cases, we want a good resolution, but this should be independent
>>>>>> of the user's timer choice IMO.
>>>>> And this is something rtdm_clock_read_tsc() will obviously not be for.
>>>> Please, take a look in my case. The specification recommends wait at
>>>> least Xus before testing a bit. But the time to wait is not constant, it
>>>> can vary a few microseconds. So, I busy wait Xus and then do some code
>>>> like:
>>>>
>>>> rtdm_task_busy_sleep(X*1000);
>>>> start_time = rtdm_clock_read[_tsc]();
>>>> do {
>>>> condition=testbit();
>>>> } while (! condition && (time_passed(start_time) < TIMEOUT));
>>>>
>>>> But if the user specifies a periodic timer, with tickval=1ms, then my
>>>> driver will be too slow. I could busy wait TIMEOUT before testing, and it
>>>> would be faster then the above code in this case. But I would like to go
>>>> away as soon as possible, ie, just after the bit has been set...
>>> This is how the eepr100 driver of RTnet handles it, though RTnet would
>>> not work very well in periodic mode. Actually, this has been ported over
>> >from Linux where you do not have a portable API for reading the TSC, I
>>> think.
>>>
>>> static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>>> {
>>>    int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>>>
>>>    while (inb(cmd_ioaddr) != 0) {
>>>        if (wait-- == 0)
>>>            return 1;
>>>        rtdm_task_busy_sleep(1000);
>>>    }
>>>    return 0;
>>> }
>>> (Hmm, BTW, de-inlining might be worth considering...)
>>>
>>> So this works at a polling period of 1 us, but you may also reduce it,
>>> though this would certainly degrade the accuracy further. For sure, the
>>> accuracy is slightly worse than with your pattern. Would this matter to
>>> you?
>> No, in my case it doesn't matter. I'll adopt this way of doing it.
> 
> Thinking better, I would need such a function for registering the timestamp of 
> the captured frame on the irq handler...
> 

What will this timestamp be used for, relative time calculations? I just
would like to remind that the output of rtdm_clock_read_tsc() will not
be in sync with the system clock in periodic mode (one of my major
concern: that driver writers forget this fact).

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

Em Ter=E7a 14 Mar=E7o 2006 16:00, Jan Kiszka escreveu:

>Rodrigo Rosenfeld Rosas wrote:
>> Em Ter=E7a 14 Mar=E7o 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
>>> Em Ter=E7a 14 Mar=E7o 2006 13:46, Jan Kiszka escreveu:
>>>>>>> ... Another one is for timeouts on short delays. In
>>>>>>> those cases, we want a good resolution, but this should be
>>>>>>> independent of the user's timer choice IMO.
>>>>>>
>>>>>> And this is something rtdm_clock_read_tsc() will obviously not be fo=
r.
>>>>>
>>>>> Please, take a look in my case. The specification recommends wait at
>>>>> least Xus before testing a bit. But the time to wait is not constant,
>>>>> it can vary a few microseconds. So, I busy wait Xus and then do some
>>>>> code like:
>>>>>
>>>>> rtdm_task_busy_sleep(X*1000);
>>>>> start_time =3D rtdm_clock_read[_tsc]();
>>>>> do {
>>>>> condition=3Dtestbit();
>>>>> } while (! condition && (time_passed(start_time) < TIMEOUT));
>>>>>
>>>>> But if the user specifies a periodic timer, with tickval=3D1ms, then =
my
>>>>> driver will be too slow. I could busy wait TIMEOUT before testing, and
>>>>> it would be faster then the above code in this case. But I would like
>>>>> to go away as soon as possible, ie, just after the bit has been set...
>>>>
>>>> This is how the eepr100 driver of RTnet handles it, though RTnet would
>>>> not work very well in periodic mode. Actually, this has been ported ov=
er
>>>>
>>> >from Linux where you do not have a portable API for reading the TSC, I
>>>>
>>>> think.
>>>>
>>>> static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cm=
d)
>>>> {
>>>>    int wait =3D CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>>>>
>>>>    while (inb(cmd_ioaddr) !=3D 0) {
>>>>        if (wait-- =3D=3D 0)
>>>>            return 1;
>>>>        rtdm_task_busy_sleep(1000);
>>>>    }
>>>>    return 0;
>>>> }
>>>> (Hmm, BTW, de-inlining might be worth considering...)
>>>>
>>>> So this works at a polling period of 1 us, but you may also reduce it,
>>>> though this would certainly degrade the accuracy further. For sure, the
>>>> accuracy is slightly worse than with your pattern. Would this matter to
>>>> you?
>>>
>>> No, in my case it doesn't matter. I'll adopt this way of doing it.
>>
>> Thinking better, I would need such a function for registering the
>> timestamp of the captured frame on the irq handler...
>
>What will this timestamp be used for, relative time calculations? I just
>would like to remind that the output of rtdm_clock_read_tsc() will not
>be in sync with the system clock in periodic mode (one of my major
>concern: that driver writers forget this fact).

But that is exactly what I need. Suppose that a robot control system uses t=
wo=20
images to estimate the robot speed. The application may need a control loop=
=20
of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But,=20
suppose that in each loop it takes two images in a short time interval (les=
s=20
then 100ms or even less then 1ms) and the real time interval is very=20
important. So the driver must pass the timestamp of each captured frame to=
=20
application loop. But those times shouldn't be multiple of the timer tick,=
=20
but the real time with all precision it can get.

I'm not talking especifically about this application, but giving you a gene=
ral=20
idea of what is not possible to do currently with RTDM if the application s=
et=20
the timer to periodic.

Regards,

Rodrigo.

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> Em Terça 14 Março 2006 16:00, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Em Terça 14 Março 2006 13:59, Rodrigo Rosenfeld Rosas escreveu:
>>>> Em Terça 14 Março 2006 13:46, Jan Kiszka escreveu:
>>>>>>>> ... Another one is for timeouts on short delays. In
>>>>>>>> those cases, we want a good resolution, but this should be
>>>>>>>> independent of the user's timer choice IMO.
>>>>>>> And this is something rtdm_clock_read_tsc() will obviously not be for.
>>>>>> Please, take a look in my case. The specification recommends wait at
>>>>>> least Xus before testing a bit. But the time to wait is not constant,
>>>>>> it can vary a few microseconds. So, I busy wait Xus and then do some
>>>>>> code like:
>>>>>>
>>>>>> rtdm_task_busy_sleep(X*1000);
>>>>>> start_time = rtdm_clock_read[_tsc]();
>>>>>> do {
>>>>>> condition=testbit();
>>>>>> } while (! condition && (time_passed(start_time) < TIMEOUT));
>>>>>>
>>>>>> But if the user specifies a periodic timer, with tickval=1ms, then my
>>>>>> driver will be too slow. I could busy wait TIMEOUT before testing, and
>>>>>> it would be faster then the above code in this case. But I would like
>>>>>> to go away as soon as possible, ie, just after the bit has been set...
>>>>> This is how the eepr100 driver of RTnet handles it, though RTnet would
>>>>> not work very well in periodic mode. Actually, this has been ported over
>>>>>
>>>> >from Linux where you do not have a portable API for reading the TSC, I
>>>>> think.
>>>>>
>>>>> static inline int rt_wait_for_cmd_done(long cmd_ioaddr, const char *cmd)
>>>>> {
>>>>>    int wait = CONFIG_RTNET_DRV_EEPRO100_CMDTIMEOUT;
>>>>>
>>>>>    while (inb(cmd_ioaddr) != 0) {
>>>>>        if (wait-- == 0)
>>>>>            return 1;
>>>>>        rtdm_task_busy_sleep(1000);
>>>>>    }
>>>>>    return 0;
>>>>> }
>>>>> (Hmm, BTW, de-inlining might be worth considering...)
>>>>>
>>>>> So this works at a polling period of 1 us, but you may also reduce it,
>>>>> though this would certainly degrade the accuracy further. For sure, the
>>>>> accuracy is slightly worse than with your pattern. Would this matter to
>>>>> you?
>>>> No, in my case it doesn't matter. I'll adopt this way of doing it.
>>> Thinking better, I would need such a function for registering the
>>> timestamp of the captured frame on the irq handler...
>> What will this timestamp be used for, relative time calculations? I just
>> would like to remind that the output of rtdm_clock_read_tsc() will not
>> be in sync with the system clock in periodic mode (one of my major
>> concern: that driver writers forget this fact).
> 
> But that is exactly what I need. Suppose that a robot control system uses two 
> images to estimate the robot speed. The application may need a control loop 
> of, say, 100ms, putting the periodic timer set to 1, 10 or 100ms. But, 
> suppose that in each loop it takes two images in a short time interval (less 
> then 100ms or even less then 1ms) and the real time interval is very 
> important. So the driver must pass the timestamp of each captured frame to 
> application loop. But those times shouldn't be multiple of the timer tick, 
> but the real time with all precision it can get.

Ok, your framework is effectively aiming for relative times here, that's
clear now. But your driver will deliver individual frames with absolute
timestamp, right? Then it's up to the user to NOT mix up these
timestamps with dates obtained from the system clock. You will have to
state this clearly!

Moreover, when considering the TSC as high-resolution timestamp source,
this is not applicable on SMP / multicore systems. Those tend to have
unsynchronised and drifting TSCs. So if the first picture was taken on
one CPU and the second on some other...

> 
> I'm not talking especifically about this application, but giving you a general 
> idea of what is not possible to do currently with RTDM if the application set 
> the timer to periodic.

And as I have this general view in mind, I want to avoid that the TSC
issue gets exported via RTDM drivers to the user. That's already
problematic for the other skins, but having to write special notes all
over the documentation of dozens of driver using mixed clocks would be
very unhandy.

I see the need for having a high-resolution timestamp aside a
low-overhead and low-resolution timer now, and I think we need to look
for a way to avoid its negative sides. Not sure yet if it will be
feasible, but I will come up with a new thread on this topic soon...

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

I really tried to not answer this message and finish the "endless thread" y=
ou=20
mentioned, but I couldn't resist. ;) Maybe this will be the last post from =
my=20
own on this thread and will begin writing in the new thread. See below,=20
please.
____________________________________________________________
Em Ter=E7a 14 Mar=E7o 2006 17:29, Jan Kiszka escreveu:

>...
>
>Ok, your framework is effectively aiming for relative times here, that's
>clear now. But your driver will deliver individual frames with absolute
>timestamp, right?

Right.

>Then it's up to the user to NOT mix up these=20
>timestamps with dates obtained from the system clock. You will have to
>state this clearly!

Sure, of course. No problem with that.

>Moreover, when considering the TSC as high-resolution timestamp source,
>this is not applicable on SMP / multicore systems. Those tend to have
>unsynchronised and drifting TSCs. So if the first picture was taken on
>one CPU and the second on some other...

Unfortunately I can not arguee on that for now since I know almost nothing=
=20
about SMP systems. I'll take a look on the topic and hopely soon I'll retur=
n=20
you what I think about it.

>> I'm not talking especifically about this application, but giving you a
>> general idea of what is not possible to do currently with RTDM if the
>> application set the timer to periodic.
>
>And as I have this general view in mind, I want to avoid that the TSC
>issue gets exported via RTDM drivers to the user. That's already
>problematic for the other skins, but having to write special notes all
>over the documentation of dozens of driver using mixed clocks would be
>very unhandy.

I don't understand why adding a new function like this would change a lot t=
he=20
documentation. I really can not see your worries... If you could give me a=
=20
practical example, maybe it would be easier for me...

>I see the need for having a high-resolution timestamp aside a
>low-overhead and low-resolution timer now,=20

good, got an ally. ;)

>and I think we need to look=20
>for a way to avoid its negative sides.

=46irst I need to understand better what exactly are the negative sides...

>Not sure yet if it will be=20
>feasible, but I will come up with a new thread on this topic soon...

Yes, I've seen. I'll discuss next messages there.

Thank you,

Rodrigo.

	

	
		
_______________________________________________________ 
Yahoo! doce lar. Faça do Yahoo! sua homepage. 
http://br.yahoo.com/homepageset.html 

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Rodrigo Rosenfeld Rosas wrote:
> I really tried to not answer this message and finish the "endless thread" you 
> mentioned, but I couldn't resist. ;) Maybe this will be the last post from my 
> own on this thread and will begin writing in the new thread. See below, 
> please.

I see no problem in continuing it. I guess most subscribers already
created special deletion filter for its keywords anyway. ;)

> ____________________________________________________________
> Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu:
> 
>> ...
>>
>> Ok, your framework is effectively aiming for relative times here, that's
>> clear now. But your driver will deliver individual frames with absolute
>> timestamp, right?
> 
> Right.
> 
>> Then it's up to the user to NOT mix up these 
>> timestamps with dates obtained from the system clock. You will have to
>> state this clearly!
> 
> Sure, of course. No problem with that.
> 
>> Moreover, when considering the TSC as high-resolution timestamp source,
>> this is not applicable on SMP / multicore systems. Those tend to have
>> unsynchronised and drifting TSCs. So if the first picture was taken on
>> one CPU and the second on some other...
> 
> Unfortunately I can not arguee on that for now since I know almost nothing 
> about SMP systems. I'll take a look on the topic and hopely soon I'll return 
> you what I think about it.

Then let me continue my sentence:

... the timestamps can not be used to calculate the delay between both
of them. The reason is that you are lacking the offset between both TSC
sources at the respective timestamp acquisition dates.

> 
>>> I'm not talking especifically about this application, but giving you a
>>> general idea of what is not possible to do currently with RTDM if the
>>> application set the timer to periodic.
>> And as I have this general view in mind, I want to avoid that the TSC
>> issue gets exported via RTDM drivers to the user. That's already
>> problematic for the other skins, but having to write special notes all
>> over the documentation of dozens of driver using mixed clocks would be
>> very unhandy.
> 
> I don't understand why adding a new function like this would change a lot the 
> documentation. I really can not see your worries... If you could give me a 
> practical example, maybe it would be easier for me...

A driver that reports TSC timestamps instead of system clock timestamps
to the user has to state this fact and its potential effects in periodic
mode - as long as both clocks are out of sync. My idea is now to
synchronise them and report corrected TSC-based timestamps via
rtdm_clock_read() when in periodic mode. No need for new functions, use
the old one, and all your problems would be solved automatically.

> 
>> I see the need for having a high-resolution timestamp aside a
>> low-overhead and low-resolution timer now, 
> 
> good, got an ally. ;)
> 
>> and I think we need to look 
>> for a way to avoid its negative sides.
> 
> First I need to understand better what exactly are the negative sides...
> 
>> Not sure yet if it will be 
>> feasible, but I will come up with a new thread on this topic soon...
> 
> Yes, I've seen. I'll discuss next messages there.
> 
> Thank you,
> 
> Rodrigo.
> 
> 	

Jan


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

Re: [Xenomai-core] RTDM and Timer functions

[Rodrigo Rosenfeld Rosas]

--- Jan Kiszka <jan.kiszka@domain.hid> escreveu:

> ...
> >> Moreover, when considering the TSC as high-resolution timestamp source,
> >> this is not applicable on SMP / multicore systems. Those tend to have
> >> unsynchronised and drifting TSCs. So if the first picture was taken on
> >> one CPU and the second on some other...
> > 
> > Unfortunately I can not arguee on that for now since I know almost nothing 
> > about SMP systems. I'll take a look on the topic and hopely soon I'll return 
> > you what I think about it.
> 
> Then let me continue my sentence:
> 
> ... the timestamps can not be used to calculate the delay between both
> of them. The reason is that you are lacking the offset between both TSC
> sources at the respective timestamp acquisition dates.

I understood that. What I've said is that I do not have enough knowledge about SMP systems for
suggesting you a way of dealing with this kind of problem.

> > ...
> > I don't understand why adding a new function like this would change a lot the 
> > documentation. I really can not see your worries... If you could give me a 
> > practical example, maybe it would be easier for me...
> 
> A driver that reports TSC timestamps instead of system clock timestamps
> to the user has to state this fact and its potential effects in periodic
> mode - as long as both clocks are out of sync.

That I understand. But I couldn't figure out which changes should be made to documentation for
adding this function. Of course, as usual, the programmer will need to know what (s)he is doing. A
single note explaining the situation in the rtdm_clock_read_tsc() function would suffice in my
opinion. I do not think that adding this function would imply in any confusion for developers.

> My idea is now to
> synchronise them and report corrected TSC-based timestamps via
> rtdm_clock_read() when in periodic mode. No need for new functions, use
> the old one, and all your problems would be solved automatically.

What do you mean by "corrected TSC-based timestamps"? How would be this mechanism? Which
resolution would it give?

I think you are meaning that:

On RTDM load, there is an automatic calculation of the offsets between the TSC of each CPU and the
Xenomai timer. Then, rtdm_clock_read() would change it behaviour to returning a higher precision
time read, based on TSC and correcting them with the stored offsets. Is that right?

Rodrigo.



		
_______________________________________________________ 
Novo Yahoo! Messenger com voz: Instale agora e faça ligações de graça. 
http://br.messenger.yahoo.com/

Re: [Xenomai-core] RTDM and Timer functions

[Philippe Gerum]

Rodrigo Rosenfeld Rosas wrote:
> I really tried to not answer this message and finish the "endless thread" you 
> mentioned, but I couldn't resist. ;) Maybe this will be the last post from my 
> own on this thread and will begin writing in the new thread. See below, 
> please.

Don't bother with self-censorship, AFAIC, the issues you are triggering are 
important ones, since RTDM is a critical piece of the Xenomai framework, and 
allowing users to leverage it efficiently will help us all. However, please don't 
top post and trim the old messages a bit more from your replies: unfortunately, my 
brain has a limited FIFO. TIA,

> ____________________________________________________________
> Em Terça 14 Março 2006 17:29, Jan Kiszka escreveu:
> 
> 
>>...
>>
>>Ok, your framework is effectively aiming for relative times here, that's
>>clear now. But your driver will deliver individual frames with absolute
>>timestamp, right?
> 
> 
> Right.
> 
> 
>>Then it's up to the user to NOT mix up these 
>>timestamps with dates obtained from the system clock. You will have to
>>state this clearly!
> 
> 
> Sure, of course. No problem with that.
> 
> 
>>Moreover, when considering the TSC as high-resolution timestamp source,
>>this is not applicable on SMP / multicore systems. Those tend to have
>>unsynchronised and drifting TSCs. So if the first picture was taken on
>>one CPU and the second on some other...
> 
> 
> Unfortunately I can not arguee on that for now since I know almost nothing 
> about SMP systems. I'll take a look on the topic and hopely soon I'll return 
> you what I think about it.
> 
> 
>>>I'm not talking especifically about this application, but giving you a
>>>general idea of what is not possible to do currently with RTDM if the
>>>application set the timer to periodic.
>>
>>And as I have this general view in mind, I want to avoid that the TSC
>>issue gets exported via RTDM drivers to the user. That's already
>>problematic for the other skins, but having to write special notes all
>>over the documentation of dozens of driver using mixed clocks would be
>>very unhandy.
> 
> 
> I don't understand why adding a new function like this would change a lot the 
> documentation. I really can not see your worries... If you could give me a 
> practical example, maybe it would be easier for me...
> 
> 
>>I see the need for having a high-resolution timestamp aside a
>>low-overhead and low-resolution timer now, 
> 
> 
> good, got an ally. ;)
> 
> 
>>and I think we need to look 
>>for a way to avoid its negative sides.
> 
> 
> First I need to understand better what exactly are the negative sides...
> 
> 
>>Not sure yet if it will be 
>>feasible, but I will come up with a new thread on this topic soon...
> 
> 
> Yes, I've seen. I'll discuss next messages there.
> 
> Thank you,
> 
> Rodrigo.
> 
> 	
> 
> 	
> 		
> _______________________________________________________ 
> Yahoo! doce lar. Faça do Yahoo! sua homepage. 
> http://br.yahoo.com/homepageset.html 
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.

Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka]

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

Anders Blomdell wrote:
> Jan Kiszka wrote:
>> ...
>> Thinking about this more thoroughly, a few questions popped up for me:
>>
>> o When we call it rtdm_clock_read_tsc(), we should actually return the
>>   raw TSC values, shouln't we? But then we also need conversion
>>   functions (rtdm_clock_tsc2ns, rtdm_clock_ns2tsc). Or should we always
>>   convert to nanoseconds on return? POSIX and Native are different in
>>   this regard.
>>
>> o What would be the core rationale behind it, having a high-resolution
>>   time stamp? What are the primary use cases? I'm asking for this so
>>   that I can clearly differentiate between this new service and the
>>   existing one in the docs. Also, giving an abstract description would
>>   leave more options to the actual implementation on other archs or
>>   platforms.
> If you implement it, don't forget to point out that the tsc may have
> increments varying over time (due to clock scaling), and might even stop
> for long periods (ACPI sleep), just so we are not faced with a primitive
> that makes it impossible to implement low-power operation (not at the
> very top on my priority list, but still important).

Yeah, one reason why I'm hesitating ATM to introduce a too specific
service to RTDM. But I'm still open to being persuaded about its usefulness.

Jan



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