[Xenomai-help] tsc enable or disable

[Xenomai-help] tsc enable or disable

[roland Tollenaar]

Hi,

I have a  xenomai kernel running!

I have tested using the testsuit latency ./run program. initially I
got this message

Xenomai: incompatible feature set.
(required="sep tsc", present= "sep", missing="tsc")

Which I "sorted" by configuring the user part of xenomai with --disable-x86-tsc

However I understood from previous mails that TSC was good. Did I miss
a setting when configuring the kernel?

What does this TSC mean. The documentation is very spars about this.

Ehh and while I think about it, what is displayed by the latency test. I get

lat min  lat ave latmax overrun lat best
20.11   29.33   52.79  0            19.276

typical.

The period seems to be 100micro seconds so what do the figures above
mean? 20 microseconds is typically the shortest period I could run at?
Or >52.79? Some light on this would be great.

Kind regards,

And thanks for all the help.

Roland.

Re: [Xenomai-help] tsc enable or disable

[Philippe Gerum]

On Tue, 2007-02-20 at 23:37 +0000, roland Tollenaar wrote:
> Hi,
> 
> I have a  xenomai kernel running!
> 
> I have tested using the testsuit latency ./run program. initially I
> got this message
> 
> Xenomai: incompatible feature set.
> (required="sep tsc", present= "sep", missing="tsc")
> 

Which means "user-space wants sep+tsc, but kernel only provides sep, so
tsc is missing". Since tsc is a required option, the whole thing bails
out whinning.

> Which I "sorted" by configuring the user part of xenomai with --disable-x86-tsc
> 

The other way is to select an x86 CPU that provides a time stamp counter
in the kernel configuration. You have likely picked 486 which does not
usually have such support.

> However I understood from previous mails that TSC was good. Did I miss
> a setting when configuring the kernel?
> 

Yep.

> What does this TSC mean. The documentation is very spars about this.
> 

Search for Time stamp counter / x86. Activating it gives a better timing
precision -and a much lower overhead- than using the poor man's
emulation of a TSC based on the 8254 programmable interval timer you
also have in your PC (which is the fallback choice Xenomai picks when no
TSC is available on x86). (This said, TSCs also have their problems, but
that's off-topic).

> Ehh and while I think about it, what is displayed by the latency test. I get
> 
> lat min  lat ave latmax overrun lat best
> 20.11   29.33   52.79  0            19.276
> 
> typical.
> 

Decent, especially in emulated TSC mode over a low-end system. Not that
brilliant and almost suspect on a multi-Ghz box, it depends on you hw.

> The period seems to be 100micro seconds so what do the figures above
> mean? 20 microseconds is typically the shortest period I could run at?
> Or >52.79? Some light on this would be great.
> 

20 us is the closest latency _spot_ (i.e. for one sample) to the ideal
tick time observed in your current configuration, for running a
user-space task sampling at 10Khz (if you did not specify any option to
the latency test, that is). 52.79 would tell us that the sustainable
rate without any overrun should in theory be close to 20Khz according to
those figures, but you also need to account for some RT sleep time to
let the regular Linux kernel breathe and other perturbations, so I would
rather bet on a period around 80-90 us (to check this, try running the
latency test as either: ./run -- -p 80, or sudo ./latency -p 80, and
adjust /proc/xenomai/latency to get the minimal latency closer to the
ideal tick time while the test runs, i.e. zero).

In any case, those figures would only make sense as significant
worst-case values for a properly loaded box (i.e. w/ cache
perturbations, bus traffic, all sorts of runtime tortures).

Search the mail archive for the keyword "/proc/xenomai/latency", and
make sure to have read the TROUBLESHOOTING guide, you will get more
information about these issues.

> Kind regards,
> 
> And thanks for all the help.
> 
> Roland.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] tsc enable or disable

[Roland Tollenaar]

Hi

> Processor type and features -> Processor family
Thanks found it. I did try to set it to the 586/5x86 etc series but I am 
having serious conflicts now with the squashfs and unionfs file system 
drivers. I cannot get it booted like this.

I will try the pentium classic family to see whether that works.

Anyone know why I might be seeing this. Those file systems are inherent 
to the liveUSB liveCD distributions.


How serious is it if I cannot get TSC support into the kernel?
Will I have problems with sound cards and such like?

RR



> 
>> Regards,
>>
>> Roland
>>
>>
>>
>>
>>
>>
>>
>>> Search for Time stamp counter / x86. Activating it gives a better timing
>>> precision -and a much lower overhead- than using the poor man's
>>> emulation of a TSC based on the 8254 programmable interval timer you
>>> also have in your PC (which is the fallback choice Xenomai picks when no
>>> TSC is available on x86). (This said, TSCs also have their problems, but
>>> that's off-topic).
>>>
>>>> Ehh and while I think about it, what is displayed by the latency test. I get
>>>>
>>>> lat min  lat ave latmax overrun lat best
>>>> 20.11   29.33   52.79  0            19.276
>>>>
>>>> typical.
>>>>
>>> Decent, especially in emulated TSC mode over a low-end system. Not that
>>> brilliant and almost suspect on a multi-Ghz box, it depends on you hw.
>>>
>>>> The period seems to be 100micro seconds so what do the figures above
>>>> mean? 20 microseconds is typically the shortest period I could run at?
>>>> Or >52.79? Some light on this would be great.
>>>>
>>> 20 us is the closest latency _spot_ (i.e. for one sample) to the ideal
>>> tick time observed in your current configuration, for running a
>>> user-space task sampling at 10Khz (if you did not specify any option to
>>> the latency test, that is). 52.79 would tell us that the sustainable
>>> rate without any overrun should in theory be close to 20Khz according to
>>> those figures, but you also need to account for some RT sleep time to
>>> let the regular Linux kernel breathe and other perturbations, so I would
>>> rather bet on a period around 80-90 us (to check this, try running the
>>> latency test as either: ./run -- -p 80, or sudo ./latency -p 80, and
>>> adjust /proc/xenomai/latency to get the minimal latency closer to the
>>> ideal tick time while the test runs, i.e. zero).
>>>
>>> In any case, those figures would only make sense as significant
>>> worst-case values for a properly loaded box (i.e. w/ cache
>>> perturbations, bus traffic, all sorts of runtime tortures).
>>>
>>> Search the mail archive for the keyword "/proc/xenomai/latency", and
>>> make sure to have read the TROUBLESHOOTING guide, you will get more
>>> information about these issues.
>>>
>>>> Kind regards,
>>>>
>>>> And thanks for all the help.
>>>>
>>>> Roland.
>>>>
>>>> _______________________________________________
>>>> Xenomai-help mailing list
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help