Hello,
I am experiencing some weird time readings in my app.
Some details: I have a piece of code (a state estimator) whose exec time
should be quite constant, and is approx. 12 msec (I measure this in offline
simulations). When I use that same code in an OROCOS component, the exec
time starts jumping up to cca 30 msec. Luckily, the exec time is bounded
:), up to those 30 msec.
There are a few things that might go wrong here, but I would like to know
if TimeService from OROCOS is reliable enough or not. I use getTicks() and
secondsSince() for time stamping/time interval measurements. In particular,
can this guy give some weird (false?) readings in case CPU load on a
multi-core CPU is "relatively" high, i.e. > 40%?
Thanx a lot in advance.
Best,
Milan
TimeService in multi-core computer
Hi Milan,
On Tue, Sep 3, 2013 at 11:07 AM, Milan Vukov <mvukov [..] ...> wrote:
> Hello,
>
> I am experiencing some weird time readings in my app.
>
> Some details: I have a piece of code (a state estimator) whose exec time
> should be quite constant, and is approx. 12 msec (I measure this in offline
> simulations). When I use that same code in an OROCOS component, the exec
> time starts jumping up to cca 30 msec. Luckily, the exec time is bounded
> :), up to those 30 msec.
>
> There are a few things that might go wrong here, but I would like to know
> if TimeService from OROCOS is reliable enough or not. I use getTicks() and
> secondsSince() for time stamping/time interval measurements. In particular,
> can this guy give some weird (false?) readings in case CPU load on a
> multi-core CPU is "relatively" high, i.e. > 40%?
>
Not that I know of... we're using it a lot and it has been proven to very
reliable on multi-core, loaded systems as well. It maps directly to the
Operating System, so Orocos does not modify the ticks.
How did you measure the exec time ? Did you compile in Debug mode or in
Release mode ?
Peter
TimeService in multi-core computer
Hi Peter,
Thanx for your answers. I feel a bit safer now :). I am not using CMake,
but "tup". Of course, OROCOS is compiled with CMake in Release mode. User
code is compiled with "-O3 -march=native -mtune=native" compilation flags.
I investigated a bit what TimeService does, thus learned how it works. I
use clock_gettime() a lot in other apps, too.
I forgot to mention: I experienced this weird timing behavior in 1 of cca
15 OROCOS components in my deployment. Is there any specific reason to use
CLOCK_REALTIME vs CLOCK_MONOTONIC_RAW?
Cheers,
Milan
On Thu, Sep 5, 2013 at 9:44 AM, Peter Soetens <peter [..] ...>wrote:
> Hi Milan,
>
> On Tue, Sep 3, 2013 at 11:07 AM, Milan Vukov <mvukov [..] ...> wrote:
>
>> Hello,
>>
>> I am experiencing some weird time readings in my app.
>>
>> Some details: I have a piece of code (a state estimator) whose exec time
>> should be quite constant, and is approx. 12 msec (I measure this in offline
>> simulations). When I use that same code in an OROCOS component, the exec
>> time starts jumping up to cca 30 msec. Luckily, the exec time is bounded
>> :), up to those 30 msec.
>>
>> There are a few things that might go wrong here, but I would like to know
>> if TimeService from OROCOS is reliable enough or not. I use getTicks() and
>> secondsSince() for time stamping/time interval measurements. In particular,
>> can this guy give some weird (false?) readings in case CPU load on a
>> multi-core CPU is "relatively" high, i.e. > 40%?
>>
>
> Not that I know of... we're using it a lot and it has been proven to very
> reliable on multi-core, loaded systems as well. It maps directly to the
> Operating System, so Orocos does not modify the ticks.
>
> How did you measure the exec time ? Did you compile in Debug mode or in
> Release mode ?
>
> Peter
>
>
TimeService in multi-core computer
On Thu, Sep 5, 2013 at 11:31 AM, Milan Vukov <mvukov [..] ...> wrote:
> Hi Peter,
>
> Thanx for your answers. I feel a bit safer now :). I am not using CMake,
> but "tup". Of course, OROCOS is compiled with CMake in Release mode. User
> code is compiled with "-O3 -march=native -mtune=native" compilation flags.
>
> I investigated a bit what TimeService does, thus learned how it works. I
> use clock_gettime() a lot in other apps, too.
>
> I forgot to mention: I experienced this weird timing behavior in 1 of cca
> 15 OROCOS components in my deployment. Is there any specific reason to use
> CLOCK_REALTIME vs CLOCK_MONOTONIC_RAW?
>
Milan,
CLOCK_REALTIME specifies time elapsed since the Epoch, and is subject to
discontinuous forwards/backwards jumps and NTP slew. Prefer this clock when
absolute time and multiple machine synchronization is important.
CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW have an arbitrary time origin. The
former is subject to NTP slew (but not jumps), while the latter is subject
to none. Prefer these clocks when working with durations within a single
machine.
Check the clock_gettime man page for more details. Web version here:
http://man7.org/linux/man-pages/man2/clock_gettime.2.html
Best,
Adolfo.
> Cheers,
> Milan
>
>
> On Thu, Sep 5, 2013 at 9:44 AM, Peter Soetens <peter [..] ...>wrote:
>
>> Hi Milan,
>>
>> On Tue, Sep 3, 2013 at 11:07 AM, Milan Vukov <mvukov [..] ...> wrote:
>>
>>> Hello,
>>>
>>> I am experiencing some weird time readings in my app.
>>>
>>> Some details: I have a piece of code (a state estimator) whose exec time
>>> should be quite constant, and is approx. 12 msec (I measure this in offline
>>> simulations). When I use that same code in an OROCOS component, the exec
>>> time starts jumping up to cca 30 msec. Luckily, the exec time is bounded
>>> :), up to those 30 msec.
>>>
>>> There are a few things that might go wrong here, but I would like to
>>> know if TimeService from OROCOS is reliable enough or not. I use getTicks()
>>> and secondsSince() for time stamping/time interval measurements. In
>>> particular, can this guy give some weird (false?) readings in case CPU load
>>> on a multi-core CPU is "relatively" high, i.e. > 40%?
>>>
>>
>> Not that I know of... we're using it a lot and it has been proven to very
>> reliable on multi-core, loaded systems as well. It maps directly to the
>> Operating System, so Orocos does not modify the ticks.
>>
>> How did you measure the exec time ? Did you compile in Debug mode or in
>> Release mode ?
>>
>> Peter
>>
>>
>
>
> --
> Milan Vukov, PhD Student
> KU Leuven, Department of Electrical Engineering (ESAT)
> STADIUS Center for Dynamical Systems, Signal Processing and Data Analytics
> Kasteelpark Arenberg 10, bus 2446, B-3001 Leuven-Heverlee, Belgium
> e-mail: milan [dot] vukov [..] ...
> phone: +32-479-813256 (BE), +381-64-1541622 (SR)
> disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
>
TimeService in multi-core computer
Hello,
I knew the difference ;). My question was: Is there any specific reason to
use CLOCK_REALTIME vs CLOCK_MONOTONIC_RAW? -- in OROCOS TimeService of
course. I would guess that the later one should be preferred if one works
on a single machine.
Best,
Milan
On Thu, Sep 5, 2013 at 12:27 PM, Adolfo Rodríguez Tsouroukdissian <
adolfo [dot] rodriguez [..] ...> wrote:
>
>
>
> On Thu, Sep 5, 2013 at 11:31 AM, Milan Vukov <mvukov [..] ...> wrote:
>
>> Hi Peter,
>>
>> Thanx for your answers. I feel a bit safer now :). I am not using CMake,
>> but "tup". Of course, OROCOS is compiled with CMake in Release mode. User
>> code is compiled with "-O3 -march=native -mtune=native" compilation flags.
>>
>> I investigated a bit what TimeService does, thus learned how it works. I
>> use clock_gettime() a lot in other apps, too.
>>
>> I forgot to mention: I experienced this weird timing behavior in 1 of cca
>> 15 OROCOS components in my deployment. Is there any specific reason to use
>> CLOCK_REALTIME vs CLOCK_MONOTONIC_RAW?
>>
>
> Milan,
>
> CLOCK_REALTIME specifies time elapsed since the Epoch, and is subject to
> discontinuous forwards/backwards jumps and NTP slew. Prefer this clock when
> absolute time and multiple machine synchronization is important.
>
> CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW have an arbitrary time origin. The
> former is subject to NTP slew (but not jumps), while the latter is subject
> to none. Prefer these clocks when working with durations within a single
> machine.
>
> Check the clock_gettime man page for more details. Web version here:
>
> http://man7.org/linux/man-pages/man2/clock_gettime.2.html
>
> Best,
>
> Adolfo.
>
>
>> Cheers,
>> Milan
>>
>>
>> On Thu, Sep 5, 2013 at 9:44 AM, Peter Soetens <peter [..] ...>wrote:
>>
>>> Hi Milan,
>>>
>>> On Tue, Sep 3, 2013 at 11:07 AM, Milan Vukov <mvukov [..] ...> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am experiencing some weird time readings in my app.
>>>>
>>>> Some details: I have a piece of code (a state estimator) whose exec
>>>> time should be quite constant, and is approx. 12 msec (I measure this in
>>>> offline simulations). When I use that same code in an OROCOS component, the
>>>> exec time starts jumping up to cca 30 msec. Luckily, the exec time is
>>>> bounded :), up to those 30 msec.
>>>>
>>>> There are a few things that might go wrong here, but I would like to
>>>> know if TimeService from OROCOS is reliable enough or not. I use getTicks()
>>>> and secondsSince() for time stamping/time interval measurements. In
>>>> particular, can this guy give some weird (false?) readings in case CPU load
>>>> on a multi-core CPU is "relatively" high, i.e. > 40%?
>>>>
>>>
>>> Not that I know of... we're using it a lot and it has been proven to
>>> very reliable on multi-core, loaded systems as well. It maps directly to
>>> the Operating System, so Orocos does not modify the ticks.
>>>
>>> How did you measure the exec time ? Did you compile in Debug mode or in
>>> Release mode ?
>>>
>>> Peter
>>>
>>>
>>
>>
>> --
>> Milan Vukov, PhD Student
>> KU Leuven, Department of Electrical Engineering (ESAT)
>> STADIUS Center for Dynamical Systems, Signal Processing and Data Analytics
>> Kasteelpark Arenberg 10, bus 2446, B-3001 Leuven-Heverlee, Belgium
>> e-mail: milan [dot] vukov [..] ...
>> phone: +32-479-813256 (BE), +381-64-1541622 (SR)
>> disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>
>> --
>> Orocos-Users mailing list
>> Orocos-Users [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>>
>>
>
>
> --
> Adolfo Rodríguez Tsouroukdissian
> Senior robotics engineer
> adolfo [dot] rodriguez [..] ...
> http://www.pal-robotics.com
>
> PAL ROBOTICS S.L
> c/ Pujades 77-79, 4º4ª
> 08005 Barcelona, Spain.
> Tel. +34.93.414.53.47
> Fax.+34.93.209.11.09
> Skype: adolfo.pal-robotics
> Facebook <http://www.facebook.com/palrobotics1> - Twitter<http://twitter.com/#%21/palrobotics>- PAL
> Robotics YouTube Channel <http://www.youtube.com/user/PALRobotics>
>
> AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
> contener información privilegiada y/o confidencial que está dirigida
> exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
> destinatario indicado, o el empleado encargado de su entrega a dicha
> persona, por favor, notifíquelo inmediatamente y remita el mensaje original
> a la dirección de correo electrónico indicada. Cualquier copia, uso o
> distribución no autorizados de esta comunicación queda estrictamente
> prohibida.
>
> CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
> contain confidential information which is privileged and intended only for
> the individual or entity to whom they are addressed. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution or use of this e-mail and/or accompanying document(s) is
> strictly prohibited. If you have received this e-mail in error, please
> immediately notify the sender at the above e-mail address.
>
TimeService in multi-core computer
On Thu, Sep 12, 2013 at 4:34 PM, Milan Vukov <mvukov [..] ...> wrote:
> Hello,
>
> I knew the difference ;). My question was: Is there any specific reason to
> use CLOCK_REALTIME vs CLOCK_MONOTONIC_RAW? -- in OROCOS TimeService of
> course. I would guess that the later one should be preferred if one works on
> a single machine.
Yes... Orocos applications are not robust against daylight saving
changes or big/small jumps caused by ntp.
I know there have been considerations to use clock_monotonic(_raw) but
they did not make it
into mainline.
I believe the show-stopper was pthread_cond_timedwait, which requires
a clock_realtime value and broke when we switched the clock to
monotonic.
Investigating it again (stack overflow :-) reveals that the clock can
be changed with an attribute as described in:
http://stackoverflow.com/questions/3006259/what-time-function-do-i-need-...
So maybe this was decision was made on false assumptions, and I would
vote for a patch that modifies this...if existing code which actually
interpretes our 'ticks' as clock_realtime values gets a way out by
introducing a new TimeService function which explicitly returns the
real_time (wall time) clock for timestamping data etc.
Peter