Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » keeping larger state tables in something more efficient than arrays
keeping larger state tables in something more efficient than arrays [message #1822217] Sun, 01 March 2020 22:04 Go to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 106
Registered: July 2017
Location: Berlin, Germany
Senior Member

In many use cases in the Osmocom (http://git.osmocom.org/osmo-ttcn3-hacks/) test suites we are creating state tables of a given protocol layer in order to run multiple parallel test components on top.

This is a re-appearing pattern you can find in many telecom protocols. In the end you have N tunnels, N channels, N subscribers, ... and you want to have one component that receives messges from the underlying transport and which then dispatches to the per-subscriber/channel/tunnel component on top. In osmo-ttcn3-hacks, we call those the FOO_Emulation component.

In those components, you typically create some kind of state table based on some higher-level identifier, e.g. the IMSI of the subscriber. This IMSI is what de-multiplexes the received messages to individual per-subscriber TTCN-3 components.

So far, we've used statically-sized TTCN-3 arrays and linear list iteration for the related data structures. That's fine if you want to run a handful of parallel test components, like 16 or 32.

But what if you want to scale higher? For e.g. 1000 records I wouldn't want to use linear iteration over the array at every lookup. It seems neither TTCN-3 nor TITAN provide any built-in support for more efficient data structures like trees, hash tables, dictionaries, etc.

Does anyone have good ideas on how to address this? I would assume that anyone doing load/performance testing of stateful systems would run into the same kind of problem. Yes, I understand TTCN-3 is primarily used for functional and conformance testing, but given the performance of the actual TITAN-generated code, and the fact there is a "load testing runtime"... why not?

Yes, it might be possible to use a C++ implementation of a related data structure, import that as native functions into TITAN and then use such functions to look-up entries. However, I suspect the devil is in the details - like having to write lots of boilerplate code for each and every to-be-suppored data type / table.
Re: keeping larger state tables in something more efficient than arrays [message #1822229 is a reply to message #1822217] Mon, 02 March 2020 08:33 Go to previous messageGo to next message
Gábor Szalai is currently offline Gábor SzalaiFriend
Messages: 45
Registered: December 2015
Member
Check the git://git.eclipse.org/gitroot/titan/titan.Libraries.CLL.git

It contains implementation of string2integer and integer2integer hash maps and free-busy queues. Unfortunately it is not easy to separate them from the rest of the library

Re: keeping larger state tables in something more efficient than arrays [message #1822240 is a reply to message #1822229] Mon, 02 March 2020 10:19 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1063
Registered: January 2015
Senior Member
Hi Harald,

a lot can be accomplished by using "record of " structures instead of arrays.
These are a lot more flexible, can be grown or shrunk at will, "lengthof" will return the position of the last pointer etc.
If not properly managed though, they can consume the whole memory if extended uncontrollably, or lead to memory leaks if not properly freed and so on;
but symptoms will manifest only for applications running for a longer period of time intensively, such as load generators for stability test etc.
Titan is being used to a great extent in load generating applications, and speed of execution was a permanent concern for design.


Best regards
Elemer
Previous Topic:SCTP support in Eclipse Titan part 2
Next Topic:ctags for TTCN-3 / vim?
Goto Forum:
  


Current Time: Sat Jul 11 09:10:45 GMT 2020

Powered by FUDForum. Page generated in 0.01534 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top