Re: [Xenomai-core] RTDM and Timer functions

2006-03-15 Thread 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@gna.org
https://mail.gna.org/listinfo/xenomai-core




--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Jan Kiszka
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




signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
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...


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.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
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.

Thank you,

Rodrigo.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
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...

Rodrigo.



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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
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.

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.

Regards,

Rodrigo.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
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.

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@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread Rodrigo Rosenfeld Rosas
--- Jan Kiszka [EMAIL PROTECTED] 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/

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-14 Thread 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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Rodrigo Rosenfeld Rosas
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.

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.

 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.

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



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Gilles Chanteperdrix
Jan Kiszka wrote:
   Sometimes the result is Should be near 84000: 10, that is kind of 
   correct, since the tickval is 10, 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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Rodrigo Rosenfeld Rosas
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ço 2006 14:15, Rodrigo Rosenfeld Rosas escreveu:



Em Segunda 13 Março 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@gna.org
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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread 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ço 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ço 2006 14:15, Rodrigo Rosenfeld Rosas escreveu:


Em Segunda 13 Março 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@gna.org
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@gna.org
https://mail.gna.org/listinfo/xenomai-core





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



___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Rodrigo Rosenfeld Rosas
Em Segunda 13 Março 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 
application depends on the RTDM host environment, see related documentation 
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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Rodrigo Rosenfeld Rosas
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: 10, that is kind of
 correct, since the tickval is 10, 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.

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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-13 Thread Rodrigo Rosenfeld Rosas
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 
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.

Rodrigo.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-10 Thread Rodrigo Rosenfeld Rosas
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.

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=10: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: 10, that is kind of 
correct, since the tickval is 10, 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...

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

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?

Thanks in advance,

Rodrigo.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-10 Thread Jan Kiszka
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=10: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: 10, that is kind of 
 correct, since the tickval is 10, 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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-10 Thread Rodrigo Rosenfeld Rosas
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=10: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: 10, that is kind of
 correct, since the tickval is 10, 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.

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.

Rodrigo.


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


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


Re: [Xenomai-core] RTDM and Timer functions

2006-03-09 Thread Jan Kiszka
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



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core