User Guide > Timer

Timer

Timers on Ethernet frame and UDP datagram level

By applying Timers to Ethernet Ports through which traffic Flows pass, it is possible to measure the forwarding delay or latency of the individual Ethernet frames or UDP datagrams comprising the Flow, as they are forwarded through a number of Switches in an Ethernet network. Timers are applied pair-wise, typically were the traffic Flow of interest enters and exists the Ethernet network. Thus, the first Timer must be applied on the Switch ingress Port through which the Flow enters the Ethernet backbone. Likewise, the second Timer must be applied on the Switch egress Port where the Flow will exit the Ethernet backbone. The following image shows a simple network with Timers applied to selected Ports - Port with Timers has a darker color and a black border:

Timers on IPDU level

New in version 2.0 of TCN TimeAnalysis is the concept of the IPDU. A Timer can now also be applied to measure the latency of an IPDU being transmitted from its source Host and one of its target Hosts, however, as the IPDU is produced and consumed inside Hosts there is no specific visualization of Timers applied on IPDU level.

Latency distributions and latency charts

Timers on Ethernet frame or UDP datagram level will be looking for these at the Ethernet Ports they are applied; During a simulation, when a Timer sees its assigned inbound frame or datagram entering an Ethernet network, it registers the current point in time. At a later point in time, when the same instance of the frame or datagram exits the Ethernet network, the Timer collects a second timestamp. The difference between the two collected time stamps constitute the forwarding delay (or latency) of this particular Ethernet frame or UDP datagram. If a number of pair-wise timestamps are registered, a statistical distribution of forwarding delays is collected during a simulation. After the simulation terminates, the statistical distribution is visualized in a chart under the Simulation results tab.

Depending on Port loads, the priority of the flow, the Paths taken by other traffic flows etc, a certain frame or datagram can experience more or less contention when it wants to exit through different Switch Ports. If an Ethernet egress interface is busy transmitting when an Ethernet frame wants to exit through the associated Switch Port, the frame is queued up for a shorter or longer period of time. Varying queuing delay increases the forwarding delay and causes jitter to be experienced by the periodically released frames or datagrams in a traffic flow. The Latency Chart indicates the probability that a specific Flow experience a certain latency and jitter.

Much of the above is true also for Timers applied to an IPDU, however, as IPDUs originate inside a Host and can be multicasted through several different ports, the first timestamp is taken when the IPDU has been generated in the source Host and is ready to be transmitted and the second timestamp is taken when it has reached the target Host and is ready to be consumed by an application. Thus, a Timer on the IPDU level can measure the time for the IPDU to cross also CAN- and LIN-busses as well as Ethernet networks, or even a series of busses and networks connected together using gateway Hosts.

To add a new Timer to your system model, either:

This will open the Timer dialog:

Properties

Trigger on

Given a Traffic Flow that a Timer is to observe, the Timer can either trigger on the level of a specific Ethernet Frame, UDP Datagram or IPDU.

Object

Specifies the name of the specific Ethernet Frame, UDP Datagram or IPDU that a Timer is to perform timing measurements on.

Start/Stop

To measure a forwarding delay of, for example, a specific Ethernet Frame, the associated Timer must start and stop its timing measurement at certain points along the frame’s path in the topology graph. Specifically, time samples are registered when the frame enters the user specified ingress Switch Port (Start) and exists through another egress Switch Port (Stop) in an Ethernet network.

Likewise, in the case of a UDP Datagram, the start and stop positions must be in the Ethernet Ports of the source and destination Host, respectively. Finally, as an IPDU is produced and consumed by Tasks inside Hosts, the start and stop position for an IPDU are a source and target Host, respectively.

As large UDP datagrams might not fit into a single IPv4 datagram and Ethernet frame, fragmentation might have to be applied. It will then require several Ethernet frames to deliver a full UDP datagram and it is first after fragment reassembly in the receiving Host that the Timer will register a stop-time for the delivery of the UDP datagram. In a similar manner, the start- and stop-time for an IPDU is when the IPDU has been produced and is ready to be transmitted in the source Host and when it is ready to be consumed by the receiving Task in the target Host, respectively.

At Ethernet Frame and UDP Datagram levels, the pair-wise Ports in which time sampling occurs are visualized by a thicker frame around the two ports in the topology graph. For a Timer on IPDU level the source and target Hosts of the associated Timer are given a thicker frame in the topology window.

Watchdogs

Two different Watchdogs can be activated for each timer; one that keeps an eye on computed latencies and the other one observing jitter values, respectively. After a simulation terminates, a watchdog inspects, for example, all latency values computed by the associated Timer and flags any value that exceeds the user specified upper limit, please see the Simulation results article.

Actions

The following actions are available for existing Timers - right-click on a Timer in the topology or the tree view:

     
Edit Opens the Timer dialog in edit mode.
Delete Removes the Timer from the topology.