We have a situation where I think we need multiple TimeServices (ie clocks) within one deployer. I wanted to run my thoughts by the ML, and see if anyone had a) done this before, or b) had significant issues with potential future patches from this effort. The ability to essentially run multiple clocks within one RTT process/deployer might be useful to others ...
Basically, we need some components to run off a virtual clock, with a rate that we can manually scale up and down (eg run at 1x for some time, then 8x for some time, down to 2x for a while). The remaining components are all using the normal wall clock. We need to be able to use an OCL::TimerComponent with this virtual clock also. We can not separate these components out into a different deployer and/or use a SimulationThread (or similar), for a bunch of different reasons.
It looks to me like we would need to
- add a function to RTT::TimeService to convert a Time from this TimeService, into a "wallClockTime " (a real operating system time). For the existing RTT::TimeService, this would return the given time (ie no conversion involved).
- create a (non-RTT) VirtualTimeService derived from RTT::TimeService, that internally kept time of the virtual clock, provided the virtual clock time at all its public functions, and implement the new wallClockTime() function to convert a virtualClockTime to a wallClockTime
- we might also have to deal with the singelton aspect of TimeService. Not sure.
- change RTT::Timer to optionally accept a TimeService as a parameter. Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to convert the wake_up_time to a wallClockTime, and then wait on that wallClockTime instead. An RTT::Timer with a virutal clock TimeService would simply operate in the virtual clock world, except for this one added line, so no other changes.
- change OCL::TimerComponent to accept a TimeoutCatcher as a parameter. Derived classes wanting a virtual clock would pass in a TimeoutCatcher associated with an RTT::Timer associated with a VirtualTimeService.
In our situation, we might also add an application component that makes the virtual clock available through its RTT interface (eg getTime, time_port). I am not yet sure where the virtual clock TimeService would actually be instantiated: here, in the derived OCL::TimerComponent, or elsewhere ...
Any thoughts?
Stephen
Multiple TimeServices in one deployer
This is an interesting discussion ... I always wondered what the time
service was for ;-)
Now, I have some kind of side question: how, based on this
infrastructure, do you implement your algorithms/drivers/... "out of
RTT" (and since some people were talking about ROS: "out of ros") ? This
is a primary concern for us ...
Sylvain
[PS: and I'm not talking about "clock interactions" through
synchronization primitives / hardware access]
Multiple TimeServices in one deployer
On Thursday 06 May 2010 02:04:09 S Roderick wrote:
> We have a situation where I think we need multiple TimeServices (ie clocks)
> within one deployer. I wanted to run my thoughts by the ML, and see if
> anyone had a) done this before, or b) had significant issues with
> potential future patches from this effort. The ability to essentially run
> multiple clocks within one RTT process/deployer might be useful to others
> ...
>
> Basically, we need some components to run off a virtual clock, with a rate
> that we can manually scale up and down (eg run at 1x for some time, then
> 8x for some time, down to 2x for a while). The remaining components are
> all using the normal wall clock. We need to be able to use an
> OCL::TimerComponent with this virtual clock also. We can not separate
> these components out into a different deployer and/or use a
> SimulationThread (or similar), for a bunch of different reasons.
I've read the follow-ups with Herman, so I'm replying again with that in mind.
I think I start to understand your use case. Is the intention to run the
'controller' at normal time, but the simulate the environment (with Orocos
components) and let you play with how fast the environment changes ?
An exciting idea I must say :) Nothing present in RTT/OCL supports this today,
so you have all freedom. This is the case for both 1.x and 2.x (time service
did not change) so I hope porting to 2.x will be straight forward.
>
> It looks to me like we would need to
>
> - add a function to RTT::TimeService to convert a Time from this
> TimeService, into a "wallClockTime " (a real operating system time). For
> the existing RTT::TimeService, this would return the given time (ie no
> conversion involved).
Just to remind you of bug #735, the fosi functions for gnulinux return the
posix time (because other gnulinux OS functions require it), being not robust
against clock adjustments. The idea of a fix here was to provide both the
monotontic and the posix time such that OS functions could choose which one to
use. Be aware of nastyness here...
>
> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService, that
> internally kept time of the virtual clock, provided the virtual clock time
> at all its public functions, and implement the new wallClockTime()
> function to convert a virtualClockTime to a wallClockTime - we might also
> have to deal with the singelton aspect of TimeService. Not sure.
Ack. The idea is that all the fosi functions remain working with the OS
clocks/timers, and that the 'virtual time' layer we build lives in C++ classes
above that.
>
> - change RTT::Timer to optionally accept a TimeService as a parameter. Add
> one line in RTT::Timer::loop(), before the msem.waitUntil(), to convert
> the wake_up_time to a wallClockTime, and then wait on that wallClockTime
> instead. An RTT::Timer with a virutal clock TimeService would simply
> operate in the virtual clock world, except for this one added line, so no
> other changes.
Ack.
>
> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
> associated with an RTT::Timer associated with a VirtualTimeService.
A reimplementation + new interface of TimerComponent wouldn't be bad either
:-) It never felt 'right'.
>
> In our situation, we might also add an application component that makes the
> virtual clock available through its RTT interface (eg getTime, time_port).
> I am not yet sure where the virtual clock TimeService would actually be
> instantiated: here, in the derived OCL::TimerComponent, or elsewhere ...
Good questions. Normally, we can't share any objects between components,
unless they are singleton-like, ie globals in the process. Logger and
TimeService are two such examples. Herman would call them 'containers that
encapsulate system resources'. You are allowed to assume that these containers
live in your own process, and that each process will have their own copy of
it. If these containers synchronize between processes, is completely
implementation specific. But I understand you want to stay in-process...
Peter
Multiple TimeServices in one deployer
On May 7, 2010, at 16:19 , Peter Soetens wrote:
> On Thursday 06 May 2010 02:04:09 S Roderick wrote:
>> We have a situation where I think we need multiple TimeServices (ie clocks)
>> within one deployer. I wanted to run my thoughts by the ML, and see if
>> anyone had a) done this before, or b) had significant issues with
>> potential future patches from this effort. The ability to essentially run
>> multiple clocks within one RTT process/deployer might be useful to others
>> ...
>>
>> Basically, we need some components to run off a virtual clock, with a rate
>> that we can manually scale up and down (eg run at 1x for some time, then
>> 8x for some time, down to 2x for a while). The remaining components are
>> all using the normal wall clock. We need to be able to use an
>> OCL::TimerComponent with this virtual clock also. We can not separate
>> these components out into a different deployer and/or use a
>> SimulationThread (or similar), for a bunch of different reasons.
>
> I've read the follow-ups with Herman, so I'm replying again with that in mind.
> I think I start to understand your use case. Is the intention to run the
> 'controller' at normal time, but the simulate the environment (with Orocos
> components) and let you play with how fast the environment changes ?
Yes. One deployer contains a set of components. Some of these components deal with a virtual world that run against a virtual clock (that we can manually speed up or slow down), while the rest of the componends deal with the physical world and need a wall clock.
> An exciting idea I must say :) Nothing present in RTT/OCL supports this today,
> so you have all freedom. This is the case for both 1.x and 2.x (time service
> did not change) so I hope porting to 2.x will be straight forward.
Actually, the separation is already there (for a large part) to support this. Bar the OCL bit, I _think_ this won't be too bad. Treading carefully though ...
>> It looks to me like we would need to
>>
>> - add a function to RTT::TimeService to convert a Time from this
>> TimeService, into a "wallClockTime " (a real operating system time). For
>> the existing RTT::TimeService, this would return the given time (ie no
>> conversion involved).
>
> Just to remind you of bug #735, the fosi functions for gnulinux return the
> posix time (because other gnulinux OS functions require it), being not robust
> against clock adjustments. The idea of a fix here was to provide both the
> monotontic and the posix time such that OS functions could choose which one to
> use. Be aware of nastyness here...
This should affect us no more than now, when we're only running on the wall clock. Right?
>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService, that
>> internally kept time of the virtual clock, provided the virtual clock time
>> at all its public functions, and implement the new wallClockTime()
>> function to convert a virtualClockTime to a wallClockTime - we might also
>> have to deal with the singelton aspect of TimeService. Not sure.
>
> Ack. The idea is that all the fosi functions remain working with the OS
> clocks/timers, and that the 'virtual time' layer we build lives in C++ classes
> above that.
Yes.
>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>> associated with an RTT::Timer associated with a VirtualTimeService.
>
> A reimplementation + new interface of TimerComponent wouldn't be bad either
> :-) It never felt 'right'.
It's close though ... will do for now, with just a couple of tweaks maybe ...
>> In our situation, we might also add an application component that makes the
>> virtual clock available through its RTT interface (eg getTime, time_port).
>> I am not yet sure where the virtual clock TimeService would actually be
>> instantiated: here, in the derived OCL::TimerComponent, or elsewhere ...
>
> Good questions. Normally, we can't share any objects between components,
> unless they are singleton-like, ie globals in the process. Logger and
> TimeService are two such examples. Herman would call them 'containers that
> encapsulate system resources'. You are allowed to assume that these containers
> live in your own process, and that each process will have their own copy of
> it. If these containers synchronize between processes, is completely
> implementation specific. But I understand you want to stay in-process...
I think that we want (longer term) to end up being able to register TimeServices, like we register toolkits. And able to put them into dynamic libraries. This will spur a more general approach to loadable resources I would think ... Herman's term is quite right I think.
S
Multiple TimeServices in one deployer
On Thursday 06 May 2010 02:04:09 S Roderick wrote:
> We have a situation where I think we need multiple TimeServices (ie clocks)
> within one deployer. I wanted to run my thoughts by the ML, and see if
> anyone had a) done this before, or b) had significant issues with
> potential future patches from this effort. The ability to essentially run
> multiple clocks within one RTT process/deployer might be useful to others
> ...
ROS has this built-in (damn ROS!) so there's lots of inspiration to get from
there. They use it (I guess) for running nodes in Gazebo. Since we're planning
ROS-RTT integration, I would prefer to see if we can lign up with them...
>
> Basically, we need some components to run off a virtual clock, with a rate
> that we can manually scale up and down (eg run at 1x for some time, then
> 8x for some time, down to 2x for a while). The remaining components are
> all using the normal wall clock. We need to be able to use an
> OCL::TimerComponent with this virtual clock also. We can not separate
> these components out into a different deployer and/or use a
> SimulationThread (or similar), for a bunch of different reasons.
Ouch ! TimerComponent is depending totally on the 'Wall' clock of the OS. Oh
wait, that's what you're writing below :-)
>
> It looks to me like we would need to
>
> - add a function to RTT::TimeService to convert a Time from this
> TimeService, into a "wallClockTime " (a real operating system time). For
> the existing RTT::TimeService, this would return the given time (ie no
> conversion involved).
ros::time has similar functions.
>
> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService, that
> internally kept time of the virtual clock, provided the virtual clock time
> at all its public functions, and implement the new wallClockTime()
> function to convert a virtualClockTime to a wallClockTime - we might also
> have to deal with the singelton aspect of TimeService. Not sure.
You can keep TimeService a singleton and keep track VirtualTimeService
instances in that class itself.
>
> - change RTT::Timer to optionally accept a TimeService as a parameter. Add
> one line in RTT::Timer::loop(), before the msem.waitUntil(), to convert
> the wake_up_time to a wallClockTime, and then wait on that wallClockTime
> instead. An RTT::Timer with a virutal clock TimeService would simply
> operate in the virtual clock world, except for this one added line, so no
> other changes.
Ok.
>
> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
> associated with an RTT::Timer associated with a VirtualTimeService.
I have to look into this, don't know this by the top of my head.
>
> In our situation, we might also add an application component that makes the
> virtual clock available through its RTT interface (eg getTime, time_port).
> I am not yet sure where the virtual clock TimeService would actually be
> instantiated: here, in the derived OCL::TimerComponent, or elsewhere ...
If it's a sequence of virtual time instances, you'd probably 'just' have to
number them and allow lookup through the static
VirtualTimeService::Instance(int inst_nbr) interface.
Just be sure to investigate how ROS does it, it would be great if our
TimeService could be made to play nice along the ROS one.
Peter
Multiple TimeServices in one deployer
On May 6, 2010, at 09:39 , Peter Soetens wrote:
> On Thursday 06 May 2010 02:04:09 S Roderick wrote:
>> We have a situation where I think we need multiple TimeServices (ie clocks)
>> within one deployer. I wanted to run my thoughts by the ML, and see if
>> anyone had a) done this before, or b) had significant issues with
>> potential future patches from this effort. The ability to essentially run
>> multiple clocks within one RTT process/deployer might be useful to others
>> ...
>
> ROS has this built-in (damn ROS!) so there's lots of inspiration to get from
> there. They use it (I guess) for running nodes in Gazebo. Since we're planning
> ROS-RTT integration, I would prefer to see if we can lign up with them...
>
>>
>> Basically, we need some components to run off a virtual clock, with a rate
>> that we can manually scale up and down (eg run at 1x for some time, then
>> 8x for some time, down to 2x for a while). The remaining components are
>> all using the normal wall clock. We need to be able to use an
>> OCL::TimerComponent with this virtual clock also. We can not separate
>> these components out into a different deployer and/or use a
>> SimulationThread (or similar), for a bunch of different reasons.
>
> Ouch ! TimerComponent is depending totally on the 'Wall' clock of the OS. Oh
> wait, that's what you're writing below :-)
>
>>
>> It looks to me like we would need to
>>
>> - add a function to RTT::TimeService to convert a Time from this
>> TimeService, into a "wallClockTime " (a real operating system time). For
>> the existing RTT::TimeService, this would return the given time (ie no
>> conversion involved).
>
> ros::time has similar functions.
>
>>
>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService, that
>> internally kept time of the virtual clock, provided the virtual clock time
>> at all its public functions, and implement the new wallClockTime()
>> function to convert a virtualClockTime to a wallClockTime - we might also
>> have to deal with the singelton aspect of TimeService. Not sure.
>
> You can keep TimeService a singleton and keep track VirtualTimeService
> instances in that class itself.
>
>>
>> - change RTT::Timer to optionally accept a TimeService as a parameter. Add
>> one line in RTT::Timer::loop(), before the msem.waitUntil(), to convert
>> the wake_up_time to a wallClockTime, and then wait on that wallClockTime
>> instead. An RTT::Timer with a virutal clock TimeService would simply
>> operate in the virtual clock world, except for this one added line, so no
>> other changes.
>
> Ok.
>
>>
>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>> associated with an RTT::Timer associated with a VirtualTimeService.
>
> I have to look into this, don't know this by the top of my head.
This is the murkiest part for me. Not sure my solution is a good one, but it would work for now.
>> In our situation, we might also add an application component that makes the
>> virtual clock available through its RTT interface (eg getTime, time_port).
>> I am not yet sure where the virtual clock TimeService would actually be
>> instantiated: here, in the derived OCL::TimerComponent, or elsewhere ...
>
> If it's a sequence of virtual time instances, you'd probably 'just' have to
> number them and allow lookup through the static
> VirtualTimeService::Instance(int inst_nbr) interface.
>
> Just be sure to investigate how ROS does it, it would be great if our
> TimeService could be made to play nice along the ROS one.
ROS' setup isn't much different from RTT's. Differences are
- time types are defined outside their timing classes
- they separate a Timer from a Timer Manager (they are tied together in RTT::Timer)
- they also have separate Timer/TimerManger classes vs WallTimer/WallTimerManager classes.
- you can change the period of a Timer/TimerManager on the fly (RTT lacks certain connections for this, though it is noted as a TODO).
- their Time/WallTime/TimeBase classes deal with basic time, arithmetic, and sleeping. Of interest, their non-WallTime sleep, when not using system time (presumably, a virtual clock then), sleeps in 1ms intervals, advancing thru virutal clock time until the end is reached. Interesting approach (not my first choice though) ... this bypasses my suggested addition of a VirtutalTime-to-WallTime conversion function. Also, they appear to explicitly use a simulated time construct in their lowest Time class, to allow unit tests to monkey with time. This appears to be hard-coded in there. Ugh!
They still don't appear to be able to do what I need though - advance a virtual clock at an arbitrary rate. You would need to repeatedly poke a Time's setNow() function while it is interacting with a TimerManager in some way. I don't understand enough to really say, though.
Recommendations for now
- allow changing period of Timer on the fly (this is just making some connections in v1 implementation, I believe)
- add the RTT changes (or similar) that I outlined above, to provide the beginnings of a separation of wall clock time from any desired time
Structurally, in v2, I would suggest we separate things just a little to something like
- Time types and operators
- TimeService aka Clock (ie WallClock or VirtualClock), with a default WallClock TimeService that all other TimerService's must/should be able to convert to
- TimerManager, associated with a Clock, manages N Timers and does the actual thread/sleep/wait work
- Timer, associated with a TimerManager
- OCL::TimerComponent should look as it currently does, with some extra configuration to select/instantiate a TimerManager + TimeService.
Then to support virtual clocks, you implement the VirtualClock TimeService class, and you should be able to use the existing TimerManager, Timer and TimerComponent classes as is. You just need a way to configure this. Easy! ;-)
What am I going to do ... implement my original modifications. I suspect the RTT changes could go into the v1 repo. The OCL changes promise to be more interesting though, and may stay in my private repo for some time. At least until we/I get a clean configuration approach.
So, ROS looks interesting, except for the part where their damn installer begins using MacPorts to install packages for me. Automatically! Without asking!! Broke my #@$%!!! REALLY UNFRIENDLY!!!! Grrrr ... :-(
S
Multiple TimeServices in one deployer
On Thursday 06 May 2010 19:46:05 Stephen Roderick wrote:
> On May 6, 2010, at 09:39 , Peter Soetens wrote:
> >
> > Just be sure to investigate how ROS does it, it would be great if our
> > TimeService could be made to play nice along the ROS one.
>
> ROS' setup isn't much different from RTT's. Differences are
> - time types are defined outside their timing classes
> - they separate a Timer from a Timer Manager (they are tied together in
> RTT::Timer) - they also have separate Timer/TimerManger classes vs
> WallTimer/WallTimerManager classes. - you can change the period of a
> Timer/TimerManager on the fly (RTT lacks certain connections for this,
> though it is noted as a TODO). - their Time/WallTime/TimeBase classes deal
> with basic time, arithmetic, and sleeping. Of interest, their non-WallTime
> sleep, when not using system time (presumably, a virtual clock then),
> sleeps in 1ms intervals, advancing thru virutal clock time until the end
> is reached. Interesting approach (not my first choice though)
Probably, they rely on the assumption that a) an external source delivers the
clock (a ros topic) and b) that there's only one ros node (read:thread) in
each process.
The main interaction point would be to be able to be a 'slave' for their ros
clock topic during a ROS simulation. On the other hand, we could be a clock
source to ROS components by writing this topic. I'm guessing though.
> ... this
> bypasses my suggested addition of a VirtutalTime-to-WallTime conversion
> function. Also, they appear to explicitly use a simulated time construct
> in their lowest Time class, to allow unit tests to monkey with time. This
> appears to be hard-coded in there. Ugh!
Having my code on the internet for a decade now, I have built up some
humility... sometimes you just do what you got to do.
>
> They still don't appear to be able to do what I need though - advance a
> virtual clock at an arbitrary rate. You would need to repeatedly poke a
> Time's setNow() function while it is interacting with a TimerManager in
> some way. I don't understand enough to really say, though.
I think it depends on who steers the clock topic. See
http://www.ros.org/wiki/Clock
>
> Recommendations for now
> - allow changing period of Timer on the fly (this is just making some
> connections in v1 implementation, I believe) - add the RTT changes (or
What do you mean with 'making connections' ?
> similar) that I outlined above, to provide the beginnings of a separation
> of wall clock time from any desired time
Ack.
>
> Structurally, in v2, I would suggest we separate things just a little to
> something like - Time types and operators
> - TimeService aka Clock (ie WallClock or VirtualClock), with a default
> WallClock TimeService that all other TimerService's must/should be able to
> convert to - TimerManager, associated with a Clock, manages N Timers and
> does the actual thread/sleep/wait work - Timer, associated with a
> TimerManager
Now I need a picture :-) Well, at least about how TimerManager would
work/help. Is it a wrapper round the OS primitives ? So a periodic activity
would use TimerManager intead of rtos_wait_periodic() ? Or would we install a
new kind of activity that delegates this (changes your deployment XML, but is
maybe the solution for installing timers in components )?
> - OCL::TimerComponent should look as it currently does, with some extra
> configuration to select/instantiate a TimerManager + TimeService.
Ok.
>
> Then to support virtual clocks, you implement the VirtualClock TimeService
> class, and you should be able to use the existing TimerManager, Timer and
> TimerComponent classes as is. You just need a way to configure this. Easy!
> ;-)
Yeah!
>
> What am I going to do ... implement my original modifications. I suspect
> the RTT changes could go into the v1 repo. The OCL changes promise to be
> more interesting though, and may stay in my private repo for some time. At
> least until we/I get a clean configuration approach.
>
> So, ROS looks interesting, except for the part where their damn installer
> begins using MacPorts to install packages for me. Automatically! Without
> asking!! Broke my #@$%!!! REALLY UNFRIENDLY!!!! Grrrr ... :-( S
Strange, I thought tooling was their strongest point :-D
Peter
Multiple TimeServices in one deployer
On May 7, 2010, at 17:42 , Peter Soetens wrote:
> On Thursday 06 May 2010 19:46:05 Stephen Roderick wrote:
>> On May 6, 2010, at 09:39 , Peter Soetens wrote:
>>>
>>> Just be sure to investigate how ROS does it, it would be great if our
>>> TimeService could be made to play nice along the ROS one.
>>
>> ROS' setup isn't much different from RTT's. Differences are
>> - time types are defined outside their timing classes
>> - they separate a Timer from a Timer Manager (they are tied together in
>> RTT::Timer) - they also have separate Timer/TimerManger classes vs
>> WallTimer/WallTimerManager classes. - you can change the period of a
>> Timer/TimerManager on the fly (RTT lacks certain connections for this,
>> though it is noted as a TODO). - their Time/WallTime/TimeBase classes deal
>> with basic time, arithmetic, and sleeping. Of interest, their non-WallTime
>> sleep, when not using system time (presumably, a virtual clock then),
>> sleeps in 1ms intervals, advancing thru virutal clock time until the end
>> is reached. Interesting approach (not my first choice though)
>
> Probably, they rely on the assumption that a) an external source delivers the
> clock (a ros topic) and b) that there's only one ros node (read:thread) in
> each process.
No idea, never used ROS.
> The main interaction point would be to be able to be a 'slave' for their ros
> clock topic during a ROS simulation. On the other hand, we could be a clock
> source to ROS components by writing this topic. I'm guessing though.
I think the first case is as simple as creating an Orocos ROSClock derived from TimeService, and plugging that into their clock topic. Any Orocos code using ROSClock will get ROS time from underneath then.
>> ... this
>> bypasses my suggested addition of a VirtutalTime-to-WallTime conversion
>> function. Also, they appear to explicitly use a simulated time construct
>> in their lowest Time class, to allow unit tests to monkey with time. This
>> appears to be hard-coded in there. Ugh!
>
> Having my code on the internet for a decade now, I have built up some
> humility... sometimes you just do what you got to do.
Yeah, it is funny how things come back to haunt you, isn't it!! :-)
>> They still don't appear to be able to do what I need though - advance a
>> virtual clock at an arbitrary rate. You would need to repeatedly poke a
>> Time's setNow() function while it is interacting with a TimerManager in
>> some way. I don't understand enough to really say, though.
>
> I think it depends on who steers the clock topic. See
> http://www.ros.org/wiki/Clock
I think that they still have the same situation we do. You need to create a new time service class that implements the actual clock functionality, and then they can plug that easily into their infrastructure. Orocos has to do the first also, but currently lacks the second part.
>> Recommendations for now
>> - allow changing period of Timer on the fly (this is just making some
>> connections in v1 implementation, I believe) - add the RTT changes (or
>
> What do you mean with 'making connections' ?
One of your TODO's in the code is to connect up a setPeriod() somewhere (I don't recall which of the timing classes). It looks like that simply needs to be plumbed through a couple of associated classes.
>> Structurally, in v2, I would suggest we separate things just a little to
>> something like - Time types and operators
>> - TimeService aka Clock (ie WallClock or VirtualClock), with a default
>> WallClock TimeService that all other TimerService's must/should be able to
>> convert to - TimerManager, associated with a Clock, manages N Timers and
>> does the actual thread/sleep/wait work - Timer, associated with a
>> TimerManager
>
> Now I need a picture :-) Well, at least about how TimerManager would
> work/help. Is it a wrapper round the OS primitives ? So a periodic activity
> would use TimerManager intead of rtos_wait_periodic() ? Or would we install a
> new kind of activity that delegates this (changes your deployment XML, but is
> maybe the solution for installing timers in components )?
Let me get a little further into this, and I'll send you some UML. I am not thinking of changes that go into activities. I can see how that might be a long-term future goal but, for now, I'm just concentrating on timer/clock related tasks. Not the actual scheduling side of activities and components.
S
Multiple TimeServices in one deployer
Preliminary RTT changes
http://github.com/snrkiwi/orocos-rtt/branches/release-virtual-clocks
These are the changes outlined previously, plus an additional (potentially slightly controversial) patch making ticks available in a derived time service. NB this branch is off my 'release' branch which has some required v1 fixes.
I have a working virtual-clock and OCL-based virtual-timer component, and have tested in a real system. To make the virtual-timer component really useful requires the ability to configure the time-service (aka clock) at deployment-time (I intend to do it from a property naming the time service). I think the best approach to this is to be able to register and dynamically load TimeServices, similar to toolkits. This is really about finding services dynamically (by name in this case ie factory pattern). What are people's thoughts on this? Do people have other general approaches in mind to configuring clocks?
For RTT v2, I would suggest changing the Time, TimeService, etc, interfaces a little to make things cleaner. This can wait IMHO.
Stephen
Multiple TimeServices in one deployer
On Monday 24 May 2010 18:56:17 S Roderick wrote:
> Preliminary RTT changes
>
> http://github.com/snrkiwi/orocos-rtt/branches/release-virtual-clocks
>
> These are the changes outlined previously, plus an additional (potentially
> slightly controversial) patch making ticks available in a derived time
> service. NB this branch is off my 'release' branch which has some required
> v1 fixes.
I'll have to look at this in 3 weeks, since I'm on holidays from tomorrow on.
>
> I have a working virtual-clock and OCL-based virtual-timer component, and
> have tested in a real system. To make the virtual-timer component really
> useful requires the ability to configure the time-service (aka clock) at
> deployment-time (I intend to do it from a property naming the time
> service). I think the best approach to this is to be able to register and
> dynamically load TimeServices, similar to toolkits. This is really about
> finding services dynamically (by name in this case ie factory pattern).
> What are people's thoughts on this? Do people have other general
> approaches in mind to configuring clocks?
The RTT 2.0 'services' idea discussed before on this list wants to solve your
case too. Each process has a singleton 'service tracker' that keeps track of
all created and destroyed services in a process. A service is basically a
provided interface. You can subscribe to services, ie be notified when they
come up or go away, and take proper action. This is all very OSGi like. Since
services are distributable in RTT 2, an RTT component can subscribe to all
local services and provide the 'service tracking' on a distributed level, Ie,
this process provides all these interfaces, and any component not in this
process can use them too. In your case, when a component is loaded that loads
a new TimeService in the process, it can announce this to the service tracker,
which will inform all interested parties of its appearance. Creation of
connections between ports will also use this technique to announce
connections, such that (remote) GUI's can list and visualise them.
This is all very basic object/callback bookkeeping, but very powerful. It's a
2.2 feature though.
> For RTT v2, I would suggest changing the Time, TimeService, etc, interfaces
> a little to make things cleaner. This can wait IMHO.
Now's the time to break that API, not after the release...
Peter
Multiple TimeServices in one deployer
On May 25, 2010, at 11:29 , Peter Soetens wrote:
> On Monday 24 May 2010 18:56:17 S Roderick wrote:
>> Preliminary RTT changes
>>
>> http://github.com/snrkiwi/orocos-rtt/branches/release-virtual-clocks
>>
>> These are the changes outlined previously, plus an additional (potentially
>> slightly controversial) patch making ticks available in a derived time
>> service. NB this branch is off my 'release' branch which has some required
>> v1 fixes.
>
> I'll have to look at this in 3 weeks, since I'm on holidays from tomorrow on.
No worries. Go take a break!
>> I have a working virtual-clock and OCL-based virtual-timer component, and
>> have tested in a real system. To make the virtual-timer component really
>> useful requires the ability to configure the time-service (aka clock) at
>> deployment-time (I intend to do it from a property naming the time
>> service). I think the best approach to this is to be able to register and
>> dynamically load TimeServices, similar to toolkits. This is really about
>> finding services dynamically (by name in this case ie factory pattern).
>> What are people's thoughts on this? Do people have other general
>> approaches in mind to configuring clocks?
>
> The RTT 2.0 'services' idea discussed before on this list wants to solve your
> case too. Each process has a singleton 'service tracker' that keeps track of
> all created and destroyed services in a process. A service is basically a
> provided interface. You can subscribe to services, ie be notified when they
> come up or go away, and take proper action. This is all very OSGi like. Since
> services are distributable in RTT 2, an RTT component can subscribe to all
> local services and provide the 'service tracking' on a distributed level, Ie,
> this process provides all these interfaces, and any component not in this
> process can use them too. In your case, when a component is loaded that loads
> a new TimeService in the process, it can announce this to the service tracker,
> which will inform all interested parties of its appearance. Creation of
> connections between ports will also use this technique to announce
> connections, such that (remote) GUI's can list and visualise them.
>
> This is all very basic object/callback bookkeeping, but very powerful. It's a
> 2.2 feature though.
Sounds good, but unfortunately, it does me no good right now. :-(
RTT v1 uses multiple methods of dealing with dynamically loaded items
- components with the ORO_LIST_COMPONENT_TYPE() style macros
- toolkits/plugins with the ORO_TOOLKIT_PLUGIN() macro
- type info repository, populated by toolkit plugins
I would advocate using something similar to one of the above, to be able to dynamically load time services without building a whole new mechanism. It seems that the component style is closest - the tookit/plugin is way too heavy for this. We just need a factory of time services that can be looked up by name. Based on that, I think the changes would just be
- copy ComponentLoader.hpp to TimeServiceLoader.hpp, with appropriate changes
- in DeploymentComponent::loadLibrary() add a section to lookup Time Service factories
- add a similar FactoryMap& DeploymentComponent::getFactories() for TimeService factories
User components can then lookup a TimeService during a configureHook(), say, with something like
if ( TimeServiceFactories::Instance().count( tsName ) == 1 ) {
factory = TimeService Factories::Instance()[ tsName ];
ts = factory();
It needs to be slightly different as the time service only offers Instance() to construct an object, not an actual constructor, but the basic approach is there.
>> For RTT v2, I would suggest changing the Time, TimeService, etc, interfaces
>> a little to make things cleaner. This can wait IMHO.
>
> Now's the time to break that API, not after the release...
Ok, I'll work on a propsal ..
S
Multiple TimeServices in one deployer
On May 25, 2010, at 12:48 , Stephen Roderick wrote:
> On May 25, 2010, at 11:29 , Peter Soetens wrote:
>
>> On Monday 24 May 2010 18:56:17 S Roderick wrote:
>>> Preliminary RTT changes
>>>
>>> http://github.com/snrkiwi/orocos-rtt/branches/release-virtual-clocks
>>>
>>> These are the changes outlined previously, plus an additional (potentially
>>> slightly controversial) patch making ticks available in a derived time
>>> service. NB this branch is off my 'release' branch which has some required
>>> v1 fixes.
>>
>> I'll have to look at this in 3 weeks, since I'm on holidays from tomorrow on.
>
> No worries. Go take a break!
>
>>> I have a working virtual-clock and OCL-based virtual-timer component, and
>>> have tested in a real system. To make the virtual-timer component really
>>> useful requires the ability to configure the time-service (aka clock) at
>>> deployment-time (I intend to do it from a property naming the time
>>> service). I think the best approach to this is to be able to register and
>>> dynamically load TimeServices, similar to toolkits. This is really about
>>> finding services dynamically (by name in this case ie factory pattern).
>>> What are people's thoughts on this? Do people have other general
>>> approaches in mind to configuring clocks?
>>
>> The RTT 2.0 'services' idea discussed before on this list wants to solve your
>> case too. Each process has a singleton 'service tracker' that keeps track of
>> all created and destroyed services in a process. A service is basically a
>> provided interface. You can subscribe to services, ie be notified when they
>> come up or go away, and take proper action. This is all very OSGi like. Since
>> services are distributable in RTT 2, an RTT component can subscribe to all
>> local services and provide the 'service tracking' on a distributed level, Ie,
>> this process provides all these interfaces, and any component not in this
>> process can use them too. In your case, when a component is loaded that loads
>> a new TimeService in the process, it can announce this to the service tracker,
>> which will inform all interested parties of its appearance. Creation of
>> connections between ports will also use this technique to announce
>> connections, such that (remote) GUI's can list and visualise them.
>>
>> This is all very basic object/callback bookkeeping, but very powerful. It's a
>> 2.2 feature though.
>
> Sounds good, but unfortunately, it does me no good right now. :-(
>
> RTT v1 uses multiple methods of dealing with dynamically loaded items
>
> - components with the ORO_LIST_COMPONENT_TYPE() style macros
> - toolkits/plugins with the ORO_TOOLKIT_PLUGIN() macro
> - type info repository, populated by toolkit plugins
>
> I would advocate using something similar to one of the above, to be able to dynamically load time services without building a whole new mechanism. It seems that the component style is closest - the tookit/plugin is way too heavy for this. We just need a factory of time services that can be looked up by name. Based on that, I think the changes would just be
>
> - copy ComponentLoader.hpp to TimeServiceLoader.hpp, with appropriate changes
> - in DeploymentComponent::loadLibrary() add a section to lookup Time Service factories
> - add a similar FactoryMap& DeploymentComponent::getFactories() for TimeService factories
>
> User components can then lookup a TimeService during a configureHook(), say, with something like
>
> if ( TimeServiceFactories::Instance().count( tsName ) == 1 ) {
> factory = TimeService Factories::Instance()[ tsName ];
> ts = factory();
>
> It needs to be slightly different as the time service only offers Instance() to construct an object, not an actual constructor, but the basic approach is there.
Implements suggested changes, allowing for loading of time services from dynamic libraries. Interactive and deployment test cases included.
http://github.com/snrkiwi/orocos-ocl/tree/release-virtual-clocks
S
Multiple TimeServices in one deployer
On Thu, 6 May 2010, S Roderick wrote:
> We have a situation where I think we need multiple TimeServices (ie
> clocks) within one deployer. I wanted to run my thoughts by the ML, and
> see if anyone had a) done this before, or b) had significant issues with
> potential future patches from this effort. The ability to essentially run
> multiple clocks within one RTT process/deployer might be useful to others
> ...
I think I agree that this is a useful use case! :-) Since it is the basis
of using RTT as an infrastructure in simulated systems.
> Basically, we need some components to run off a virtual clock, with a
> rate that we can manually scale up and down (eg run at 1x for some time,
> then 8x for some time, down to 2x for a while). The remaining components
> are all using the normal wall clock. We need to be able to use an
> OCL::TimerComponent with this virtual clock also. We can not separate
> these components out into a different deployer and/or use a
> SimulationThread (or similar), for a bunch of different reasons.
>
> It looks to me like we would need to
>
> - add a function to RTT::TimeService to convert a Time from this
> TimeService, into a "wallClockTime " (a real operating system time). For
> the existing RTT::TimeService, this would return the given time (ie no
> conversion involved).
I have since long a bad feeling about this "wallClockTime": reusability is
hindered by singling out one time trigger to be the "real" one! If
functionality in a component requires a clock, then it needs to get one;
whether that clock is the real time is/should be _just_ a configuration issue.
> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
> that internally kept time of the virtual clock, provided the virtual
> clock time at all its public functions, and implement the new
> wallClockTime() function to convert a virtualClockTime to a wallClockTime
> - we might also have to deal with the singelton aspect of TimeService. Not sure.
My feeling says we should, but I have no real arguments either, yet...
> - change RTT::Timer to optionally accept a TimeService as a parameter.
> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
> convert the wake_up_time to a wallClockTime, and then wait on that
> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
> would simply operate in the virtual clock world, except for this one
> added line, so no other changes.
The exact goal of this paragraph is not clear to me.
> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
> associated with an RTT::Timer associated with a VirtualTimeService.
Such classes should not have to know (or be able to decide) whether they
get a virtual clock or a real one: that's too much coupling, and hence is
left to the coordination/configuration of the whole system.
> In our situation, we might also add an application component that makes
> the virtual clock available through its RTT interface (eg getTime,
> time_port). I am not yet sure where the virtual clock TimeService would
> actually be instantiated: here, in the derived OCL::TimerComponent, or
> elsewhere ...
>
> Any thoughts?
Yes:
- I think there is prior art in this, and it's called "HLA"
<http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
Onera has an open source implementation of the Run Time Infrastructure for
HLA, CERTI: <http://www.cert.fr/CERTI />.
- I think virtual timing infrastructure is a very important feature to
extend the scope of RTT to other relevant domains. So, I would like to
stimulate you to continue this discussion.
Herman
Multiple TimeServices in one deployer
On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
> On Thu, 6 May 2010, S Roderick wrote:
>
>> We have a situation where I think we need multiple TimeServices (ie
>> clocks) within one deployer. I wanted to run my thoughts by the ML, and
>> see if anyone had a) done this before, or b) had significant issues with
>> potential future patches from this effort. The ability to essentially run
>> multiple clocks within one RTT process/deployer might be useful to others
>> ...
>
> I think I agree that this is a useful use case! :-) Since it is the basis
> of using RTT as an infrastructure in simulated systems.
>
>> Basically, we need some components to run off a virtual clock, with a
>> rate that we can manually scale up and down (eg run at 1x for some time,
>> then 8x for some time, down to 2x for a while). The remaining components
>> are all using the normal wall clock. We need to be able to use an
>> OCL::TimerComponent with this virtual clock also. We can not separate
>> these components out into a different deployer and/or use a
>> SimulationThread (or similar), for a bunch of different reasons.
>>
>> It looks to me like we would need to
>>
>> - add a function to RTT::TimeService to convert a Time from this
>> TimeService, into a "wallClockTime " (a real operating system time). For
>> the existing RTT::TimeService, this would return the given time (ie no
>> conversion involved).
>
> I have since long a bad feeling about this "wallClockTime": reusability is
> hindered by singling out one time trigger to be the "real" one! If
> functionality in a component requires a clock, then it needs to get one;
> whether that clock is the real time is/should be _just_ a configuration issue.
Agreed, but it was a good starting point for the project. And I think given the very small number of changes I've listed, the overall design pretty well supports what we want.
>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>> that internally kept time of the virtual clock, provided the virtual
>> clock time at all its public functions, and implement the new
>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>
>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>
> My feeling says we should, but I have no real arguments either, yet...
>
>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>> convert the wake_up_time to a wallClockTime, and then wait on that
>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>> would simply operate in the virtual clock world, except for this one
>> added line, so no other changes.
>
> The exact goal of this paragraph is not clear to me.
If you want to wait for a point in virtual time using the operating system primitives, you need a way to convert a virtual time to a "real time" (something the O/S can use), and then you need to wait for this "real time". The above two changes provide that.
>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>> associated with an RTT::Timer associated with a VirtualTimeService.
>
> Such classes should not have to know (or be able to decide) whether they
> get a virtual clock or a real one: that's too much coupling, and hence is
> left to the coordination/configuration of the whole system.
Yep, but I prefer to start small. Make it work. Make it right. Then make it fast/sexy/Herman-happy. :-)
>> In our situation, we might also add an application component that makes
>> the virtual clock available through its RTT interface (eg getTime,
>> time_port). I am not yet sure where the virtual clock TimeService would
>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>> elsewhere ...
>>
>> Any thoughts?
>
> Yes:
> - I think there is prior art in this, and it's called "HLA"
> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
> Onera has an open source implementation of the Run Time Infrastructure for
> HLA, CERTI: <http://www.cert.fr/CERTI />.
> - I think virtual timing infrastructure is a very important feature to
> extend the scope of RTT to other relevant domains. So, I would like to
> stimulate you to continue this discussion.
I'll check out the HLA stuff ...
The above changes are, I think, the minimum required to get a virtual timing infrastructure (I like that phrase) in place. Once that is complete, after some real world use, the next step would be to look at the configuration/coordination aspects, and how things scale.
And of course, the above changes are all v1, so at some point someone will have to port this to v2.
Cheers
Stephen
Multiple TimeServices in one deployer
On Thu, 6 May 2010, S Roderick wrote:
> On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
>
>> On Thu, 6 May 2010, S Roderick wrote:
>>
>>> We have a situation where I think we need multiple TimeServices (ie
>>> clocks) within one deployer. I wanted to run my thoughts by the ML, and
>>> see if anyone had a) done this before, or b) had significant issues with
>>> potential future patches from this effort. The ability to essentially run
>>> multiple clocks within one RTT process/deployer might be useful to others
>>> ...
>>
>> I think I agree that this is a useful use case! :-) Since it is the basis
>> of using RTT as an infrastructure in simulated systems.
>>
>>> Basically, we need some components to run off a virtual clock, with a
>>> rate that we can manually scale up and down (eg run at 1x for some time,
>>> then 8x for some time, down to 2x for a while). The remaining components
>>> are all using the normal wall clock. We need to be able to use an
>>> OCL::TimerComponent with this virtual clock also. We can not separate
>>> these components out into a different deployer and/or use a
>>> SimulationThread (or similar), for a bunch of different reasons.
>>>
>>> It looks to me like we would need to
>>>
>>> - add a function to RTT::TimeService to convert a Time from this
>>> TimeService, into a "wallClockTime " (a real operating system time). For
>>> the existing RTT::TimeService, this would return the given time (ie no
>>> conversion involved).
>>
>> I have since long a bad feeling about this "wallClockTime": reusability is
>> hindered by singling out one time trigger to be the "real" one! If
>> functionality in a component requires a clock, then it needs to get one;
>> whether that clock is the real time is/should be _just_ a configuration issue.
>
> Agreed, but it was a good starting point for the project. And I think given the very small number of changes I've listed, the overall design pretty well supports what we want.
>
Does it also support other use cases...?
>>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>>> that internally kept time of the virtual clock, provided the virtual
>>> clock time at all its public functions, and implement the new
>>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>>
>>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>>
>> My feeling says we should, but I have no real arguments either, yet...
>>
>>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>>> convert the wake_up_time to a wallClockTime, and then wait on that
>>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>>> would simply operate in the virtual clock world, except for this one
>>> added line, so no other changes.
>>
>> The exact goal of this paragraph is not clear to me.
>
> If you want to wait for a point in virtual time using the operating
> system primitives, you need a way to convert a virtual time to a "real
> time" (something the O/S can use), and then you need to wait for this
> "real time". The above two changes provide that.
I am a bit afraid to rely on "OS native" calls for this purpose... When
introducing virtual clocks, one should not "fool" developers by letting
them use the standard OS primitives (since these suggest strongly that one
is using the system's real clock).
>>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>>> associated with an RTT::Timer associated with a VirtualTimeService.
>>
>> Such classes should not have to know (or be able to decide) whether they
>> get a virtual clock or a real one: that's too much coupling, and hence is
>> left to the coordination/configuration of the whole system.
>
> Yep, but I prefer to start small. Make it work. Make it right. Then make
> it fast/sexy/Herman-happy. :-)
Mmmmm.... I have seen to many things starting small, and then growing
ugly :-)
>>> In our situation, we might also add an application component that makes
>>> the virtual clock available through its RTT interface (eg getTime,
>>> time_port). I am not yet sure where the virtual clock TimeService would
>>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>>> elsewhere ...
>>>
>>> Any thoughts?
>>
>> Yes:
>> - I think there is prior art in this, and it's called "HLA"
>> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
>> Onera has an open source implementation of the Run Time Infrastructure for
>> HLA, CERTI: <http://www.cert.fr/CERTI />.
>> - I think virtual timing infrastructure is a very important feature to
>> extend the scope of RTT to other relevant domains. So, I would like to
>> stimulate you to continue this discussion.
>
> I'll check out the HLA stuff ...
>
> The above changes are, I think, the minimum required to get a virtual
> timing infrastructure (I like that phrase) in place. Once that is
> complete, after some real world use, the next step would be to look at
> the configuration/coordination aspects, and how things scale.
This is a pragmatic approach, and I have much sympathy for such approaches.
> And of course, the above changes are all v1, so at some point someone
> will have to port this to v2.
So, please document the "long-term vision" very well, in order for this
"someone" to provide patches that improve your initial (very appreciated!)
efforts in the right direction.
Herman
Multiple TimeServices in one deployer
On May 6, 2010, at 14:02 , Herman Bruyninckx wrote:
> On Thu, 6 May 2010, S Roderick wrote:
>
>> On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
>>
>>> On Thu, 6 May 2010, S Roderick wrote:
>>>
>>>> We have a situation where I think we need multiple TimeServices (ie
>>>> clocks) within one deployer. I wanted to run my thoughts by the ML, and
>>>> see if anyone had a) done this before, or b) had significant issues with
>>>> potential future patches from this effort. The ability to essentially run
>>>> multiple clocks within one RTT process/deployer might be useful to others
>>>> ...
>>>
>>> I think I agree that this is a useful use case! :-) Since it is the basis
>>> of using RTT as an infrastructure in simulated systems.
>>>
>>>> Basically, we need some components to run off a virtual clock, with a
>>>> rate that we can manually scale up and down (eg run at 1x for some time,
>>>> then 8x for some time, down to 2x for a while). The remaining components
>>>> are all using the normal wall clock. We need to be able to use an
>>>> OCL::TimerComponent with this virtual clock also. We can not separate
>>>> these components out into a different deployer and/or use a
>>>> SimulationThread (or similar), for a bunch of different reasons.
>>>>
>>>> It looks to me like we would need to
>>>>
>>>> - add a function to RTT::TimeService to convert a Time from this
>>>> TimeService, into a "wallClockTime " (a real operating system time). For
>>>> the existing RTT::TimeService, this would return the given time (ie no
>>>> conversion involved).
>>>
>>> I have since long a bad feeling about this "wallClockTime": reusability is
>>> hindered by singling out one time trigger to be the "real" one! If
>>> functionality in a component requires a clock, then it needs to get one;
>>> whether that clock is the real time is/should be _just_ a configuration issue.
>>
>> Agreed, but it was a good starting point for the project. And I think given the very small number of changes I've listed, the overall design pretty well supports what we want.
>>
> Does it also support other use cases...?
I think so, yes. It is simply the beginning of separating out Time, Clocks, Timer management, Timers and an Orocos Interface to some of these elements.
>>>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>>>> that internally kept time of the virtual clock, provided the virtual
>>>> clock time at all its public functions, and implement the new
>>>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>>>
>>>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>>>
>>> My feeling says we should, but I have no real arguments either, yet...
>>>
>>>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>>>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>>>> convert the wake_up_time to a wallClockTime, and then wait on that
>>>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>>>> would simply operate in the virtual clock world, except for this one
>>>> added line, so no other changes.
>>>
>>> The exact goal of this paragraph is not clear to me.
>>
>> If you want to wait for a point in virtual time using the operating
>> system primitives, you need a way to convert a virtual time to a "real
>> time" (something the O/S can use), and then you need to wait for this
>> "real time". The above two changes provide that.
>
> I am a bit afraid to rely on "OS native" calls for this purpose... When
> introducing virtual clocks, one should not "fool" developers by letting
> them use the standard OS primitives (since these suggest strongly that one
> is using the system's real clock).
I'm open to other suggestions on how you solve the problem of "wait for this time to occur on this (non-Wall) clock", while reasonably minimizing the number of CPU cycles to do it. It's just that the operating system works in "meters", and your time measurements are in "feet". You simply convert and use the existing capabilities - able to wake up in "meters" time.
There are other changes required to support this, than just the one line of code added above. In particular, while a timer is sleeping waiting on some wall clock time, and the virtual clock time/scalar (in my case) is adjusted. You then need to interrupt the sleep, recompute a new wall clock time to awake at, and go back to sleep. Fun fun fun corner cases there ...
>>>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>>>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>>>> associated with an RTT::Timer associated with a VirtualTimeService.
>>>
>>> Such classes should not have to know (or be able to decide) whether they
>>> get a virtual clock or a real one: that's too much coupling, and hence is
>>> left to the coordination/configuration of the whole system.
>>
>> Yep, but I prefer to start small. Make it work. Make it right. Then make
>> it fast/sexy/Herman-happy. :-)
>
> Mmmmm.... I have seen to many things starting small, and then growing
> ugly :-)
No no no ... want to avoid that. Refactoring can and should be your friend.
>>>> In our situation, we might also add an application component that makes
>>>> the virtual clock available through its RTT interface (eg getTime,
>>>> time_port). I am not yet sure where the virtual clock TimeService would
>>>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>>>> elsewhere ...
>>>>
>>>> Any thoughts?
>>>
>>> Yes:
>>> - I think there is prior art in this, and it's called "HLA"
>>> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
>>> Onera has an open source implementation of the Run Time Infrastructure for
>>> HLA, CERTI: <http://www.cert.fr/CERTI />.
>>> - I think virtual timing infrastructure is a very important feature to
>>> extend the scope of RTT to other relevant domains. So, I would like to
>>> stimulate you to continue this discussion.
>>
>> I'll check out the HLA stuff ...
Ok, this is a super, super, super-set of what I'm planning on doing here ... not speaking for anyone's else intent though ...
>> The above changes are, I think, the minimum required to get a virtual
>> timing infrastructure (I like that phrase) in place. Once that is
>> complete, after some real world use, the next step would be to look at
>> the configuration/coordination aspects, and how things scale.
>
> This is a pragmatic approach, and I have much sympathy for such approaches.
>
>> And of course, the above changes are all v1, so at some point someone
>> will have to port this to v2.
> So, please document the "long-term vision" very well, in order for this
> "someone" to provide patches that improve your initial (very appreciated!)
> efforts in the right direction.
I don't yet have the long term vision, but when I do (and I'm beginning to see bits of it), you'll hear about it ...
S
Multiple TimeServices in one deployer
On Thu, 6 May 2010, S Roderick wrote:
> On May 6, 2010, at 14:02 , Herman Bruyninckx wrote:
>
>> On Thu, 6 May 2010, S Roderick wrote:
>>
>>> On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
>>>
>>>> On Thu, 6 May 2010, S Roderick wrote:
>>>>
>>>>> We have a situation where I think we need multiple TimeServices (ie
>>>>> clocks) within one deployer. I wanted to run my thoughts by the ML, and
>>>>> see if anyone had a) done this before, or b) had significant issues with
>>>>> potential future patches from this effort. The ability to essentially run
>>>>> multiple clocks within one RTT process/deployer might be useful to others
>>>>> ...
>>>>
>>>> I think I agree that this is a useful use case! :-) Since it is the basis
>>>> of using RTT as an infrastructure in simulated systems.
>>>>
>>>>> Basically, we need some components to run off a virtual clock, with a
>>>>> rate that we can manually scale up and down (eg run at 1x for some time,
>>>>> then 8x for some time, down to 2x for a while). The remaining components
>>>>> are all using the normal wall clock. We need to be able to use an
>>>>> OCL::TimerComponent with this virtual clock also. We can not separate
>>>>> these components out into a different deployer and/or use a
>>>>> SimulationThread (or similar), for a bunch of different reasons.
>>>>>
>>>>> It looks to me like we would need to
>>>>>
>>>>> - add a function to RTT::TimeService to convert a Time from this
>>>>> TimeService, into a "wallClockTime " (a real operating system time). For
>>>>> the existing RTT::TimeService, this would return the given time (ie no
>>>>> conversion involved).
>>>>
>>>> I have since long a bad feeling about this "wallClockTime": reusability is
>>>> hindered by singling out one time trigger to be the "real" one! If
>>>> functionality in a component requires a clock, then it needs to get one;
>>>> whether that clock is the real time is/should be _just_ a configuration issue.
>>>
>>> Agreed, but it was a good starting point for the project. And I think given the very small number of changes I've listed, the overall design pretty well supports what we want.
>>>
>> Does it also support other use cases...?
>
> I think so, yes. It is simply the beginning of separating out Time,
> Clocks, Timer management, Timers and an Orocos Interface to some of these
> elements.
I like this one-liner very much...!
>>>>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>>>>> that internally kept time of the virtual clock, provided the virtual
>>>>> clock time at all its public functions, and implement the new
>>>>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>>>>
>>>>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>>>>
>>>> My feeling says we should, but I have no real arguments either, yet...
>>>>
>>>>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>>>>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>>>>> convert the wake_up_time to a wallClockTime, and then wait on that
>>>>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>>>>> would simply operate in the virtual clock world, except for this one
>>>>> added line, so no other changes.
>>>>
>>>> The exact goal of this paragraph is not clear to me.
>>>
>>> If you want to wait for a point in virtual time using the operating
>>> system primitives, you need a way to convert a virtual time to a "real
>>> time" (something the O/S can use), and then you need to wait for this
>>> "real time". The above two changes provide that.
>>
>> I am a bit afraid to rely on "OS native" calls for this purpose... When
>> introducing virtual clocks, one should not "fool" developers by letting
>> them use the standard OS primitives (since these suggest strongly that one
>> is using the system's real clock).
>
> I'm open to other suggestions on how you solve the problem of "wait for
> this time to occur on this (non-Wall) clock",
You don't want the waiting component to explicitly use different names of
clocks, do you? So, the waiting component just uses "the" timer event.
There is only one time for any application component code, the component
just doesn't (have to) know whether that time is real or virtual. The
TimeServer component is then configured to deliver a set of desired virtual
time events, each getting another name, and the system configurator
connects the appropriate virtual time event to "the" time event of the
application component.
> while reasonably minimizing the number of CPU cycles to do it.
That "reasonably" is a very tough requirement :-) What is your definition
of "reasonable"? For example, is the use of a TimeServer component with a
set of configurable events as described above too costly in your opinion?
Or were you thinking of nothing more than a function call to convert
"meters" to "feet" as you mention in the paragraph below?
> It's just that the operating system works in "meters", and your time
> measurements are in "feet". You simply convert and use the existing
> capabilities - able to wake up in "meters" time.
> There are other changes required to support this, than just the one line
> of code added above. In particular, while a timer is sleeping waiting on
> some wall clock time, and the virtual clock time/scalar (in my case) is
> adjusted. You then need to interrupt the sleep, recompute a new wall
> clock time to awake at, and go back to sleep. Fun fun fun corner cases
> there ...
When using a TimeServer, no component has to be awoken, and only the
internal data structures of the virtual timers in the TimeServer have to be
recomputed. Of course, monotonicity is to be preserved when virtual clocks
are adjusted!
>>>>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>>>>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>>>>> associated with an RTT::Timer associated with a VirtualTimeService.
>>>>
>>>> Such classes should not have to know (or be able to decide) whether they
>>>> get a virtual clock or a real one: that's too much coupling, and hence is
>>>> left to the coordination/configuration of the whole system.
>>>
>>> Yep, but I prefer to start small. Make it work. Make it right. Then make
>>> it fast/sexy/Herman-happy. :-)
>>
>> Mmmmm.... I have seen to many things starting small, and then growing
>> ugly :-)
>
> No no no ... want to avoid that. Refactoring can and should be your friend.
>
>>>>> In our situation, we might also add an application component that makes
>>>>> the virtual clock available through its RTT interface (eg getTime,
>>>>> time_port). I am not yet sure where the virtual clock TimeService would
>>>>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>>>>> elsewhere ...
>>>>>
>>>>> Any thoughts?
>>>>
>>>> Yes:
>>>> - I think there is prior art in this, and it's called "HLA"
>>>> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
>>>> Onera has an open source implementation of the Run Time Infrastructure for
>>>> HLA, CERTI: <http://www.cert.fr/CERTI />.
>>>> - I think virtual timing infrastructure is a very important feature to
>>>> extend the scope of RTT to other relevant domains. So, I would like to
>>>> stimulate you to continue this discussion.
>>>
>>> I'll check out the HLA stuff ...
>
> Ok, this is a super, super, super-set of what I'm planning on doing here
> ... not speaking for anyone's else intent though ...
HLA is indeed of this order! But somewhere inside they have "solved" the
virtual time problem; I just don't know yet whether their solution is
simple enough for us...
>>> The above changes are, I think, the minimum required to get a virtual
>>> timing infrastructure (I like that phrase) in place. Once that is
>>> complete, after some real world use, the next step would be to look at
>>> the configuration/coordination aspects, and how things scale.
>>
>> This is a pragmatic approach, and I have much sympathy for such approaches.
>>
>>> And of course, the above changes are all v1, so at some point someone
>>> will have to port this to v2.
>> So, please document the "long-term vision" very well, in order for this
>> "someone" to provide patches that improve your initial (very appreciated!)
>> efforts in the right direction.
>
> I don't yet have the long term vision, but when I do (and I'm beginning
> to see bits of it), you'll hear about it ...
Thanks! "long term" need not be "HLA term" of course! :-)
Herman
Multiple TimeServices in one deployer
On May 6, 2010, at 14:58 , Herman Bruyninckx wrote:
> On Thu, 6 May 2010, S Roderick wrote:
>
>> On May 6, 2010, at 14:02 , Herman Bruyninckx wrote:
>>
>>> On Thu, 6 May 2010, S Roderick wrote:
>>>
>>>> On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
>>>>
>>>>> On Thu, 6 May 2010, S Roderick wrote:
>>>>>
>>>>>> We have a situation where I think we need multiple TimeServices (ie
<sni
>>>>>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>>>>>> that internally kept time of the virtual clock, provided the virtual
>>>>>> clock time at all its public functions, and implement the new
>>>>>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>>>>>
>>>>>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>>>>>
>>>>> My feeling says we should, but I have no real arguments either, yet...
>>>>>
>>>>>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>>>>>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>>>>>> convert the wake_up_time to a wallClockTime, and then wait on that
>>>>>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>>>>>> would simply operate in the virtual clock world, except for this one
>>>>>> added line, so no other changes.
>>>>>
>>>>> The exact goal of this paragraph is not clear to me.
>>>>
>>>> If you want to wait for a point in virtual time using the operating
>>>> system primitives, you need a way to convert a virtual time to a "real
>>>> time" (something the O/S can use), and then you need to wait for this
>>>> "real time". The above two changes provide that.
>>>
>>> I am a bit afraid to rely on "OS native" calls for this purpose... When
>>> introducing virtual clocks, one should not "fool" developers by letting
>>> them use the standard OS primitives (since these suggest strongly that one
>>> is using the system's real clock).
>>
>> I'm open to other suggestions on how you solve the problem of "wait for
>> this time to occur on this (non-Wall) clock",
>
> You don't want the waiting component to explicitly use different names of
> clocks, do you? So, the waiting component just uses "the" timer event.
> There is only one time for any application component code, the component
> just doesn't (have to) know whether that time is real or virtual. The
> TimeServer component is then configured to deliver a set of desired virtual
> time events, each getting another name, and the system configurator
> connects the appropriate virtual time event to "the" time event of the
> application component.
For my application, we are talking arbitrary times, not events. eg sleep(3.678 seconds), waitUntil(15m3.6s). I simply see our application network of components divided into two subsets within a deployer; those in the virtual world, and those in the physical world. Each world has one TimerComponent in it, with associated Virtual or Wall/Physical clock (the association is hidden underneath). Each application component that needs a timer is then configured to use the appropriate TimerComponent instance. This is done during deployment. Internally, the application components just need a timer - they don't need know what clock they are connected to.
>> while reasonably minimizing the number of CPU cycles to do it.
>
> That "reasonably" is a very tough requirement :-) What is your definition
> of "reasonable"? For example, is the use of a TimeServer component with a
> set of configurable events as described above too costly in your opinion?
> Or were you thinking of nothing more than a function call to convert
> "meters" to "feet" as you mention in the paragraph below?
The conversion function. To use the O/S primitives, you need to get back to wall clock time. That is my "universal" clock, as it is the only one that we can sleep/delay on while minimzing resource consumption.
>> It's just that the operating system works in "meters", and your time
>> measurements are in "feet". You simply convert and use the existing
>> capabilities - able to wake up in "meters" time.
>
>
>> There are other changes required to support this, than just the one line
>> of code added above. In particular, while a timer is sleeping waiting on
>> some wall clock time, and the virtual clock time/scalar (in my case) is
>> adjusted. You then need to interrupt the sleep, recompute a new wall
>> clock time to awake at, and go back to sleep. Fun fun fun corner cases
>> there ...
>
> When using a TimeServer, no component has to be awoken, and only the
> internal data structures of the virtual timers in the TimeServer have to be
> recomputed. Of course, monotonicity is to be preserved when virtual clocks
> are adjusted!
>
>>>>>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>>>>>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>>>>>> associated with an RTT::Timer associated with a VirtualTimeService.
>>>>>
>>>>> Such classes should not have to know (or be able to decide) whether they
>>>>> get a virtual clock or a real one: that's too much coupling, and hence is
>>>>> left to the coordination/configuration of the whole system.
>>>>
>>>> Yep, but I prefer to start small. Make it work. Make it right. Then make
>>>> it fast/sexy/Herman-happy. :-)
>>>
>>> Mmmmm.... I have seen to many things starting small, and then growing
>>> ugly :-)
>>
>> No no no ... want to avoid that. Refactoring can and should be your friend.
>>
>>>>>> In our situation, we might also add an application component that makes
>>>>>> the virtual clock available through its RTT interface (eg getTime,
>>>>>> time_port). I am not yet sure where the virtual clock TimeService would
>>>>>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>>>>>> elsewhere ...
>>>>>>
>>>>>> Any thoughts?
>>>>>
>>>>> Yes:
>>>>> - I think there is prior art in this, and it's called "HLA"
>>>>> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
>>>>> Onera has an open source implementation of the Run Time Infrastructure for
>>>>> HLA, CERTI: <http://www.cert.fr/CERTI />.
>>>>> - I think virtual timing infrastructure is a very important feature to
>>>>> extend the scope of RTT to other relevant domains. So, I would like to
>>>>> stimulate you to continue this discussion.
>>>>
>>>> I'll check out the HLA stuff ...
>>
>> Ok, this is a super, super, super-set of what I'm planning on doing here
>> ... not speaking for anyone's else intent though ...
>
> HLA is indeed of this order! But somewhere inside they have "solved" the
> virtual time problem; I just don't know yet whether their solution is
> simple enough for us...
Understood, that requires more digging than I'm prepared to do right now.
S
Multiple TimeServices in one deployer
On Thu, 6 May 2010, S Roderick wrote:
> On May 6, 2010, at 14:58 , Herman Bruyninckx wrote:
>
>> On Thu, 6 May 2010, S Roderick wrote:
>>
>>> On May 6, 2010, at 14:02 , Herman Bruyninckx wrote:
>>>
>>>> On Thu, 6 May 2010, S Roderick wrote:
>>>>
>>>>> On May 6, 2010, at 01:55 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Thu, 6 May 2010, S Roderick wrote:
>>>>>>
>>>>>>> We have a situation where I think we need multiple TimeServices (ie
>
> <sni
>
>>>>>>> - create a (non-RTT) VirtualTimeService derived from RTT::TimeService,
>>>>>>> that internally kept time of the virtual clock, provided the virtual
>>>>>>> clock time at all its public functions, and implement the new
>>>>>>> wallClockTime() function to convert a virtualClockTime to a wallClockTime
>>>>>>
>>>>>>> - we might also have to deal with the singelton aspect of TimeService. Not sure.
>>>>>>
>>>>>> My feeling says we should, but I have no real arguments either, yet...
>>>>>>
>>>>>>> - change RTT::Timer to optionally accept a TimeService as a parameter.
>>>>>>> Add one line in RTT::Timer::loop(), before the msem.waitUntil(), to
>>>>>>> convert the wake_up_time to a wallClockTime, and then wait on that
>>>>>>> wallClockTime instead. An RTT::Timer with a virutal clock TimeService
>>>>>>> would simply operate in the virtual clock world, except for this one
>>>>>>> added line, so no other changes.
>>>>>>
>>>>>> The exact goal of this paragraph is not clear to me.
>>>>>
>>>>> If you want to wait for a point in virtual time using the operating
>>>>> system primitives, you need a way to convert a virtual time to a "real
>>>>> time" (something the O/S can use), and then you need to wait for this
>>>>> "real time". The above two changes provide that.
>>>>
>>>> I am a bit afraid to rely on "OS native" calls for this purpose... When
>>>> introducing virtual clocks, one should not "fool" developers by letting
>>>> them use the standard OS primitives (since these suggest strongly that one
>>>> is using the system's real clock).
>>>
>>> I'm open to other suggestions on how you solve the problem of "wait for
>>> this time to occur on this (non-Wall) clock",
>>
>> You don't want the waiting component to explicitly use different names of
>> clocks, do you? So, the waiting component just uses "the" timer event.
>> There is only one time for any application component code, the component
>> just doesn't (have to) know whether that time is real or virtual. The
>> TimeServer component is then configured to deliver a set of desired virtual
>> time events, each getting another name, and the system configurator
>> connects the appropriate virtual time event to "the" time event of the
>> application component.
>
> For my application, we are talking arbitrary times, not events. eg
> sleep(3.678 seconds), waitUntil(15m3.6s). I simply see our application
> network of components divided into two subsets within a deployer; those
> in the virtual world, and those in the physical world. Each world has one
> TimerComponent in it, with associated Virtual or Wall/Physical clock (the
> association is hidden underneath). Each application component that needs
> a timer is then configured to use the appropriate TimerComponent
> instance. This is done during deployment. Internally, the application
> components just need a timer - they don't need know what clock they are
> connected to.
I think this is precisely what I had in mind too. Maybe with the exception
that there might be more than one Virtual World.
>>> while reasonably minimizing the number of CPU cycles to do it.
>>
>> That "reasonably" is a very tough requirement :-) What is your definition
>> of "reasonable"? For example, is the use of a TimeServer component with a
>> set of configurable events as described above too costly in your opinion?
>> Or were you thinking of nothing more than a function call to convert
>> "meters" to "feet" as you mention in the paragraph below?
>
> The conversion function. To use the O/S primitives, you need to get back
> to wall clock time. That is my "universal" clock, as it is the only one
> that we can sleep/delay on while minimzing resource consumption.
Conceptually that's fine, but the implementation should allow to "virtualize"
this access to the _real_ OS clock. That is, one should not use one
OS-specific call of course, but one that access the equivalent call in the
"FOSI"/"HAL".
>>> It's just that the operating system works in "meters", and your time
>>> measurements are in "feet". You simply convert and use the existing
>>> capabilities - able to wake up in "meters" time.
>>
>>
>>> There are other changes required to support this, than just the one line
>>> of code added above. In particular, while a timer is sleeping waiting on
>>> some wall clock time, and the virtual clock time/scalar (in my case) is
>>> adjusted. You then need to interrupt the sleep, recompute a new wall
>>> clock time to awake at, and go back to sleep. Fun fun fun corner cases
>>> there ...
>>
>> When using a TimeServer, no component has to be awoken, and only the
>> internal data structures of the virtual timers in the TimeServer have to be
>> recomputed. Of course, monotonicity is to be preserved when virtual clocks
>> are adjusted!
>>
>>>>>>> - change OCL::TimerComponent to accept a TimeoutCatcher as a parameter.
>>>>>>> Derived classes wanting a virtual clock would pass in a TimeoutCatcher
>>>>>>> associated with an RTT::Timer associated with a VirtualTimeService.
>>>>>>
>>>>>> Such classes should not have to know (or be able to decide) whether they
>>>>>> get a virtual clock or a real one: that's too much coupling, and hence is
>>>>>> left to the coordination/configuration of the whole system.
>>>>>
>>>>> Yep, but I prefer to start small. Make it work. Make it right. Then make
>>>>> it fast/sexy/Herman-happy. :-)
>>>>
>>>> Mmmmm.... I have seen to many things starting small, and then growing
>>>> ugly :-)
>>>
>>> No no no ... want to avoid that. Refactoring can and should be your friend.
>>>
>>>>>>> In our situation, we might also add an application component that makes
>>>>>>> the virtual clock available through its RTT interface (eg getTime,
>>>>>>> time_port). I am not yet sure where the virtual clock TimeService would
>>>>>>> actually be instantiated: here, in the derived OCL::TimerComponent, or
>>>>>>> elsewhere ...
>>>>>>>
>>>>>>> Any thoughts?
>>>>>>
>>>>>> Yes:
>>>>>> - I think there is prior art in this, and it's called "HLA"
>>>>>> <http://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation%29>
>>>>>> Onera has an open source implementation of the Run Time Infrastructure for
>>>>>> HLA, CERTI: <http://www.cert.fr/CERTI />.
>>>>>> - I think virtual timing infrastructure is a very important feature to
>>>>>> extend the scope of RTT to other relevant domains. So, I would like to
>>>>>> stimulate you to continue this discussion.
>>>>>
>>>>> I'll check out the HLA stuff ...
>>>
>>> Ok, this is a super, super, super-set of what I'm planning on doing here
>>> ... not speaking for anyone's else intent though ...
>>
>> HLA is indeed of this order! But somewhere inside they have "solved" the
>> virtual time problem; I just don't know yet whether their solution is
>> simple enough for us...
>
> Understood, that requires more digging than I'm prepared to do right now.
I understand too!
Herman