Home » Eclipse Projects » Eclipse Titan » Architecture and speed
| Architecture and speed [message #1751194] |
Thu, 05 January 2017 14:35 |
|
Dear all,
Parts 5 and 6 of the TTCN-3 standard ( Part 5: TTCN-3 Runtime Interface (TRI) http://www.etsi.org/deliver/etsi_es/201800_201899/20187305/04.07.01_60/es_20187305v040701p.pdf,
Part 6: TTCN-3 Control Interface (TCI) , http://www.etsi.org/deliver/etsi_es/201800_201899/20187306/04.08.01_60/es_20187306v040801p.pdf )
describe a modular architecture for a TTCN-3 test system implementation:
According to this architecture, the implementation will consist of several sub-modules which are connected via internal APIs.
During execution, the TE (test execution) part continuously sends messages to and receives messages from other modules, such as the System Adapter (SA) -in charge of test ports,
Platform Adapter (PA)-taking care of timers, etc.
This is clearly illustrated in e.g. Annex B of Part 5:
This TTCN-3 fragment
module triScenario1
{
external function MyFunction();
type port PortTypeMsg message { inout integer }
ETSI
83 ETSI ES 201 873-5 V4.7.1 (2015-06)
type component MyComponent {
port PortTypeMsg MyPort;
timer MyTimer
}
type component MyTSI {
port PortTypeMsg PCO1;
}
testcase scenario1() runs on MyComponent system MyTSI
{
MyPort.clear;
MyPort.start;
MyTimer.start(2);
map(MyComponent: MyPort, system: PCO1);
MyPort.send (integer : 5);
if (MyTimer.running)
{
MyPort.receive(integer:7);
}
else
{
MyFunction();
}
unmap(MyComponent: MyPort, system:PCO1);
MyPort.stop;
}
control {
execute( scenario1() );
}
}
has the corresponding inter-module message sequence chart:
Quite clearly, this architecture is not optimized for speed of execution.
Its' advantages are coming from modularity: codecs and system adapters are interchangeable, permitting code reusage
and allowing for a relative platform independence. This would be a great advantage if there would be a high number
of TTCN-3 implementations, so their modules could be exchanged and mixed.
Nevertheless, as you observant reader may have already noticed, Titan does not follow these parts of the standard. Quite the contrary,
Titan produces a monolithic code where functions can be invoked directly. So instead of some inter-module messaging + function invokation + some messaging again, Titan jumps directly
to invoking functions for timers, message sending and so on. Obviously, this architecture favours speed more than the one in the standard.
And by speed I mean here speed of execution, although other characteristics can be categorized under this tag, speed of compilation for instance.
As we will see, these two are not independent of each other.
The reasons for not following the standard are manifold: first and foremost, Titan was already functional when the first variant of Part 5 and 6 was published;
secondly, Titan was optimized for fast execution from the very beginning -we have been pursuing load generation from start - and adhering to the standard would have degraded this capability.
Its' non-standard architecture is not the only property of Titan that permits fast execution:
-the code generator is carefully optimized for efficiency
-Titan itself can work in two modes, corresponding to two different code sets being generated : Runtime one, which favors speed, and Runtime two, which favors functional
completeness. Some complex , but inefficient behavior required by the standard has been moved to Runtime two; the division between the two modes is expected to
expand.
-as you know, Titan is a two -step compiler; in the second step , the C++ code generated in the first step is compiled into an executable using gcc or clang. For both, optimization switches can be used to enhance performance.
E.g. for gcc the "-O2" switch has the effect to add about 10% to execution performance, at the expense of decreasing compilation performance (increasing compilation time).
Clang has the opposite effect: compilation is faster, but the speed of execution decreases.
( I can't quote figures here as the exact numbers will strongly depend on your code, your execution/build platform etc.)
Although Titan does not adhere to these parts of the standard, appropriate wrappers can be used to adapt it to existing SAs or other modules.
An example of such hybrid is the ITS stack where we use Titan together with a SA written by ETSI in Java ( see https://github.com/elnrnag/ITSG5_TS_Titanized_TA for details).
One note here: ES 202 782 1.3.1 TTCN-3 Language Extensions: TTCN-3 Performance and Real Time Testing
describes an extension of the TTCN-3 language for real time and performance testing support.
Now, I believe formulation of the title is a bit misleading: adhering to this extension does not guarantee performance testing support in the sense that your implementation will run fast;
it will only guarantee consistency of measurements when it comes to execution time.
A cornerstone concept ( I have avoided intentionally the epithet "central" here ) is the presence of a central system clock
which is being read whenever necessary. Another concept is collection of timestamps at sending and receiving to permit accurate calculations of messaging speed.
Blatantly these timestamps will slow down execution even more so they will have to be used with restraint. Quoting the standard:
"Real-time measurements at ports require additional resources (e.g. functionality that monitor ports and collect
timestamps that describe the reception time of messages, calls, replies or exceptions) that may slow down the test
execution. In order to avoid unnecessary delays at ports, such resources may only be provided when needed. "
Titan inherits its time from the operating system it runs on. Although the concept of central clock does not exist currently, an appropriate timer can take its' place during execution.
Resolution of timers depends on the operating system but for a certain environment it can be measured quite accurately.
Overall, our analysis shows that, perplexingly perhaps, implementing this language extension would slow down Titan execution, with no or minimal added benefits of accuracy.
Best regards
Elemer
Attachment: tci_tri.png
(Size: 14.95KB, Downloaded 557 times)-
Attachment: B_1_2.jpg
(Size: 94.20KB, Downloaded 450 times)
[Updated on: Thu, 05 January 2017 17:28] Report message to a moderator |
|
|
Goto Forum:
Current Time: Fri Apr 26 21:33:56 GMT 2024
Powered by FUDForum. Page generated in 0.02823 seconds |
] 
Search
Help
Register
Login
Home
