TTEnsemble

An ensemble is defined as a collection of (possibly simulated) hardware elements like processor(s), memory, storage, network interfaces, sensors, actuators, clocks, etc. It is the catch-all term for a device in the system, though we call them ‘ensembles’ to better reflect their heterogeneous nature.

The ensembles can be used in simulated and physical environments without relatively little difference from the user’s perspective and none from the program-development perspective. The TTEnsemble handles the top-level mechanisms for the ensemble. The main roles include instantiating the processes and their interfaces to each other. One ensemble exists as a TTRuntimeManager, which helps set up the network among all devices and distribute the graph. That ensemble runs an additional process to handle this management plane.

The Ensemble setup process is as follows:

  • Create a set of thread/process-safe communication channels (queues)

  • Create a set of processes for SQ synchronization, execution, and networking/forwarding

  • Configure the interfaces between each process so they can exchange information at run time

  • Set up the TTNetworkInterface (within the TTNetworkManager)

  • Contact the Runtime Manager Ensemble to request this ensemble ‘join’ the network

  • Configure the network interface to hold routing information to the other Ensembles; this information is provided bythe Runtime Manager

  • Await incoming network messages in a ‘steady state’; an example of a message is a new SQ to be instantiated on this ensemble

  • Perform SQ synchronization, execution, and forwarding as input tokens arrive as part of Graph Interpretation

  • Tear down processes and network interfaces after some timeout or s hutdown signal

class ticktalkpython.Ensemble.TTEnsemble(log_file_name, name, output_func, is_runtime_mgr=False)

Each device in a TTPython graph interpretation environment is represented by an instance of TTEnsemble or an ‘ensemble’ in our parlance.

An Ensemble also contains a collection of TTComponent instances representing the device’s capabilities. These can be added, removed, and queried for using TTComponent instances. As such, a TTEnsemble should be viewed as both the specification and realization of a TTPython-compliant device.

Each TTEnsemble implements a set of communicating processes (i.e., TTInputTokenProcess, TTExecuteProcess, and TTNetworkManager), which follow the same paradigm: each reads data (in the form of Messages) from a single input queue, and the data self-describes its function, which the process handles in turn; these processes handle nearly all runtime operations. TTEnsemble creates and manages these processes

add_components(*components)

Add one or more TTComponent instances to this TTEnsemble If a component is already present as a member of the ensemble, it will be ignored, unless it is a different instance or TTComponent with the same ‘name’ property.

Parameters:

components (TTComponent) – a list of TTComponent objects.

connect_to_TickTalk_network(runtime_manager_address, runtime_manager_name='runtime-manager')

Initiate a connection to the TickTalk network by sending a message to the Runtime Manager ensemble, whose address must be provided. To join the network, this ensemble will send a message over the network to the runtime manager, including its own address so the runtime manager can add that information to its routing table and propagate that information to all other connected ensembles. That version of the routing table will be propagated to this ensemble.

Parameters:

  • runtime_manager_address (TTEnsemble | string) – The address that the runtime manager can be access from over the network. In a simulated environment, this is simply a reference to that ensemble object (assuming the simulation environment is simpy, which runs in a single process). In a ‘physical’ environment (i.e., using a real network interface), this should be a port and ip (ip:port, e.g. ‘127.0.0.1:8425’)

  • runtime_manager_name (string) – The name of the runtime manager ensemble. Defaults to Constants.RUNTIME_MANAGER_ENSEMBLE_NAME

enter_steady_state(timeout=inf)

Put the ensemble into a steady state after all processes have been spawned. This will let them receive and exchange messages through their IPC queues, but the processes will not return or join unless an error has occurred.

This should NOT return unless a process fails or ends.

Parameters:

timeout (float | int) – The amount of time before the ensemble will end the processes and exit, defaults to no timeout (math.inf)

Returns:

None

find_component(query)
Parameters:

query (TTQuery) – a TTQuery object for a given device or devices.

remove_component(component)
Parameters:

component (TTComponent) – the TTComponent instance to be removed

setup_physical_processes(network_ip, rx_network_port=8225, tx_network_port=8425)

Setup the distinct processes that will manage the SQ synchronization (input tokens), execution, and network managemement. These are implemented to take advantage of multicore ensembles like a Jetson TX/TX2.

They must communicate using queues, which need to be created and shared between them before starting the processes to prevent runtime errors related to memory sharing.

Setting up these processes includes setting up the TTNetworkManager, which uses a UDP interface by default. It’s configuration requires a network IP and ports for transmit and receive

Parameters:

  • network_ip (string (format 255.255.255.255)) – the IP (v4) address of this ensemble

  • rx_network_port (int, optional) – The port this ensemble will expect to receive inputs from the network on. Defaults to NetworkInterfaceUDP.RX_PORT

  • tx_network_port (int, optional) – The port this ensemble will use to send inputs. Our implementation of a UDP stack includes handshaking and acknowledged delivery; using a single port helps accomplish this. Defaults to NetworkInterfaceUDP.TX_PORT

Returns:

None

setup_queues(is_sim=False)

Create the set of inter-process communication queues for this ensemble; there is one per process. In the simulated environment, we use the ordinary queue (which is faster than multiprocess.Queue due to virtual memory isolation). In the physical (non-simulated) environment, each process runs as a distinct process in the OS, so we use the multiprocess version of Queue.

Parameters:

is_sim (bool, optional) – a boolean indicator to tell whether this is a simulated runtime environment or not. Defaults to False

Returns:

None

setup_simulation_processes(sim, delay)

Setup the simulated processes for this ensemble, including one to handle & synchronize all arriving input tokens and another to schedule and execute enabled SQs.

Parameters:

  • sim (simpy.Environment) – A reference to a Simpy Environment, which is the backbone of simulation time and causality in the standalone graph simulator

  • delay (int) – Specify a delay on when to send the token. This can be used to simualte a slow network.

Returns:

None