Subject: Re: TR: Q23/17
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Tue Nov 13 2001 - 19:57:23 GMT
VINCENT Daniel FTRD/DTL/LAN at daniel.vincent#rd.francetelecom.com wrote on
13/11/2001 17:30:
>>
>> If the action is to be triggered at a "specific point in
>> time", the action
>> has to be entered. An action can only be entered from another
>> action or from
>> a state.
>>
>
> In the context, you must understand "action" as "transition"
OK.
>> If the process is in a state, the SDL semantics (Z.100 11.2)
>> requires that
>> the Continuous signal is re-interpreted every time that NOW
>> changes (that is
>> - according to the semantics - continuously). How is it
>> possible that the
>> correct value of NOW can be missed? Why would the action be
>> entered "too
>> late"? How could it be entered any sooner?
>
> A lot of possibilities : (do not forget that we are in a timed model, and
> that
> some tasks or outputs can take some time).
>
> First, just the process is executing a 3 T.U. delaying task, and you have a
> deadline in 2 T.U
> how do you do that ?
Either the task has to have an internal mechanism (for example as part a
loop of sub-tasks) for checking the clock, or the monitor of the clock has
to be in another process that logically runs concurrently. If you mean the
task requires 3 TU to complete, but it must be complete in 2 TU, it is
evident that the objective just cannot be achieved within one state machine.
This comes back to issue that there must be a resource available to handle
the transition that is required at a specific time.
> You say, the design is not good ! but it is not so evident : the task can be
> a loop
> and you don't know how much time will be needed to execute the loop.
>
> Secondly, do not forget that a PROVIDED has a lower priority than a common
> INPUT.
This was not forgotten. If the process is waiting in a state, there are no
signals that can be consumed, because they are either saved in that state or
the enabling condition for the signal is false.
> So, if the queue of the process is not empty, the PROVIDED has little
> chance.
If some signal arrives that can be consumed BEFORE the T0 is reached, a
transition will be entered. The process is no longer in a state (which was
the situation being considered).
To some extent a timer signal is better, because that can be in a PRIORITY
input. On the other hand, there is (currently) only one level of priority.
>>> why we can not use the general NOW for controlling time
>> everywhere in the
>>> system : for that we rather use clocks defined locally.
>>
>> As far as I know there are many networks that have
>> synchronised clocks,
>
> HUM ? What about IP networks ?
What about them? My computer checks a network clock over IP to make sure its
own clock is "correct". I don't know what the protocol is used for this, but
I can imagine:
Get the time ->
<- The time is xx
Get the time ->
<- The time is yy
Calculate the time based on xx and yy.
Obviously there is a limit (depending on the network) of how accurate the
slave clock can be. More round trips recording the time in each case, before
doing the calculation would enable more smoothing.
Even when there is a synchronous signal there must actually be some jitter.
>> though I would agree that having a global clock of infinitely fine
>> granularity is impossible. In reality each process must have its own
>> relativistic clock.
>>
>>>> Concerning your example :
>>>> TIMER T;
>>>> DCL next_time Time := 0;
>>>> SYNONYM period Time = EXTERNAL; /*the period*/
>>>> ...
>>>> next_time := next_time + period;
>>>> SET ( next_time, T);
>>> period should be of type Duration,
>> (DanIel is - of course - correct)
>>> but the biggest problem is that with an actual SDL timer (this means
>>> with the actual semantics of timer and queues), you only
>> specify a minimum
>>> time interval between two SET, and not an exact one, which
>> is intended with
>>> cyclic timers.
>>
>> No. This is not true.
>>
>> In the above code, if period has the value 3, then by
>> interpreting the two
>> statements above after each timer expiry, T is set to the
>> values: 3, 6, 9,
>> 12 ..., regardless of the time between the actual timeout
>> occurring and the
>> next interpretation of SET.
>
> What happens if you have in-between a task taking from 2 to 7 t.u. ?
You can have what is usually called an over-run.
For example, suppose that the transition handling the timer signal at time
3 takes 7TU. The actual time is then 3+7=10, and the timer is set to 6 and
therefore has already expired. The result is that on entering the state to
handle the timer, the transition for the timer signal is immediately entered
once more. If this time the transition takes 2 TU, the actual time is 12,
but the timer is set to 9. After one more round with with a transition of 2
TU, the time is 14 and the timer is 12. Another 2 TU transition gets the
system into the situation the time is 16 and the timer 15. Another 2 TU
transition reaches the time 18 and the timer 18, and the interpretation
continues in the same way as if there had been no over-run.
Whether this particular behaviour is acceptable will depend on what has to
be done, but provided the average time to interpret the transition for the
timer signal (and other signals) is less than timer period on average, the
timer signal transition is interpreted the correct number of times. The
timing of each interpretation is as accurate as is possible within the
resource limitations of the system.
Clearly over-run can also be detected and corrective action also taken (such
as busy back).
>>> How to achieve this is a problem that we have to deal with. With the
>>> actual semantics, it is completely impossible. We will
>> probably have to
>>> propose some slight changes (to the semantics, even in
>> Z100). Q6/10 will
>>> accept or not.
>>
>> Why is this required? The user has the choice to set a timer
>> relative to
>> either NOW, or to the last value of the timer using the
>> current semantics.
>>
>
> ?? What is this ? last value of the timer ? expiry time ? reset time ?
> probably I missed something in SDL'2000 ?
This is not new to SDL-2000. It has always been the case that a timer is set
to an absolute time, even though it is quite common to think of a timer
being set relative to NOW. Instead of setting a timer to NOW + x, it is
always possible to assign a time variable (next_time in the example) the
value of NOW + x, and use the value of the variable in a SET. In this way
there is a record of the value the timer was set to. When the timer is SET
again the new value can be relative to this stored value: see the above
example. Timers that need accuracy relative the clock (rather than some
previous event) should always be done in this way.
> Nevertheless, slight changes concern not only timer setting and timer base
> (NOW, local clocks ...)
Any drift of timers set in this way arises only from arithmetic
inaccuracies. Assuming integral values are used and Time is implemented as a
sufficiently large integer, there should be no drift.
> but also handling of the time-out (normal signal, urgent(?), interruptive
> (?) ...)
Of course, if the timer signal is not handled the timers are useless.
Handling timer signals with sufficient urgency requires careful design and
sufficient resources. No amount of good design will overcome insufficient
resources.
There may be a case for an interrupt mechanism, but this usually means
suspending the current transition and instead running an interrupt handler.
In SDL terms it seems (at least at first sight) that it should be possible
to have the timer signal handling as a separate process. It is then an
operating system resource issue to make sure that such processes get enough
resources.
> For example in TTCN, timeouts go to a special list affected to each process,
> and this
> list is different from the message queue. Some ral time systems may need
> such a feature or even more;
I am not familiar with timeouts in TTCN. Are these external monitors?
> I will not give my life for time units in SDL. It is on the table and I have
> no strong feelings about it.
Actually, I am quite in favour of stating that 1 SDL time unit = 1 Second. I
honestly do not think it adds much to the language, but it makes it easier
to explain SDL.
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 1455 55 96 55 Fax:+44 1455 55 96 58 Mob.:+44 7970 50 96 50
This archive was generated by hypermail 2a23 : Mon May 05 2008 - 20:30:55 GMT