| treating time [message #1774539] |
Mon, 16 October 2017 22:48  |
 reza ahmadi
Messages: 47
Registered: September 2016 |
Member |
|
|
Hi,
I have tried UML-RT timing services and I am now sure that it has a high precision even with very small timeout values.
However, in a scenario, I am connecting three capsules, where one signals the other by. The third one receives the output of the second one; like a triangle.
Since I have many timers and some of which have high timer values I am scaling them down: in an integrated maner to make sure all are scaled down across the model. Anyways, the timer values does not work perfectly, since if I scale down time to say 0.001 (assume it is originally 10 seconds), then I see misbehaviors. Is it possible that sometimes communication between capsules can be that heavy that a timeout fires in the meantime? I mean, I do not have any IO blocking code in my action code and I wonder how simple communication commands can take that much time to make a, say 1-second timer to time out in the meantime.
THanks for any idea.
|
|
|
| Re: treating time [message #1774585 is a reply to message #1774539] |
Tue, 17 October 2017 14:01  |
Ernesto Posse
Messages: 438
Registered: March 2011 |
Senior Member |
|
|
Can you clarify what kind of misbehaviours do you see? Can you provide an example? When you say you set your timer to 0.001, what is the unit? seconds or nanoseconds?
Generally message passing should be rather quick, but you have to take into account thread allocation: are the sender and the receiver allocated to the same controller or different controllers? If they are in the same controller, they both run in the same OS thread, and there may be a time interval between the sending and the reception since when the sender sends the message, this is queued in the receiver's controller's queue, which may already have many entries.
Nevertheless, the default message passing in UML-RT is *asynchronous* which means that there are *no* time guarantees about when a message is received. This means that if you have a capsule A which sends a message (asynchronously) to B at time t0, and at the same time B sets a timer with duration d, the reception of the message by B can occur before or after t0+d. This is perfectly consistent with asynchronous communication. In fact this is the meaning of asynchronous communication. So whenever you send a message asynchronously you cannot make any assumptions about when the message is going to be delivered.
|
|
|
Powered by
FUDForum. Page generated in 0.22387 seconds
] 
Search
Help
Register
Login
Home
