Missing queuing latency handling for buses

[reteprelief]

We currently deal with sampling latency for periodic protocols and buses.
We could do queuing latency based on the number of connections bound to the bus

[reteprelief]

For periodic protocols and buses we interpret the Period property on the protocol or bus to determine a sampling latency, i.e., the latency to wait for the protocol or bus slot to come around. This is similar to periodic threads sampling their input.

When buses or protocols are not periodic and multiple senders submit messages, they go into a queue to be transmitted. Similar to a thread port having a queue with a specified queue size, we can allow the specification of a queue size for a bus or protocol. In the case of a thread the queuing latency is the size of the queue times the size of the data sent through the port and the amount of time it takes for each of the messages in the queue to be processed (deadline or execution time).

A queue on a protocol or bus has to handle messages of different sizes determined by the source port of the connections bound to the bus.

A simple way of dealing with this is for users to just specify the maximum queue size in bytes independent of the number of bound connections (often done when configuring communication systems). Note that the standard Queue_Size property has number of messages and here we would need a new property indicating the size in bytes.

An alternative way of doing it is to make the assumption that all connection sources send at the same time, i.e., the queue has one message from each sender in the queue.
The queuing latency would be calculated based on how long it takes to transmit each message (based on the transmission time property).

There are several test examples with an Actual_Connection_Binding property, e.g, package transmission_time that can be modified.

[AaronGreenhouse]

I think I need to update FlowLatencyAnalysisSwitch.processTransmissionTime(). Still looking at how it all it works. I found the following handy methods:

• getMaximumTransmissionTimePerByte()
• getMaximumTransmissionTimeFixed()
• getMaximumTimeToTransferData()

Also min versions.

Going to need a way to find all the connections bound to the same bus.

[AaronGreenhouse]

No. I need to update processSamplingTime(), called by processActualConnectionBindingsSampling().

[AaronGreenhouse]

The method processSamplingTime() is currently

	public void processSamplingTime(NamedElement boundBus, LatencyContributor latencyContributor) {
		/**
		 * we add the bus/VB sampling time as a subcontributor.
		 */

		// XXX: [Code Coverage] boundBus cannot be null.
		if (boundBus != null) {
			double period = GetProperties.getPeriodinMS(boundBus);
			if (period > 0) {
				// add sampling latency due to the protocol or bus being periodic
				LatencyContributor samplingLatencyContributor = new LatencyContributorComponent(boundBus,
						report.isMajorFrameDelay());
				samplingLatencyContributor.setBestCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);
				samplingLatencyContributor.setWorstCaseMethod(LatencyContributorMethod.SAMPLED_PROTOCOL);
				samplingLatencyContributor.setSamplingPeriod(period);

				latencyContributor.addSubContributor(samplingLatencyContributor);
			}
		}
	}

Only does anything when the bus itself has a period associated with it. Need to make it work when the bus does not have a period.

Need to find the other connections bound to the same bus and fix as described in the original message.

[AaronGreenhouse]

Test case:

package QueuingLatency
public
	data D1
		properties
			Data_Size => 8 Bytes;
	end D1;
	
	data D11
		properties
			Data_Size => 16 Bytes;
	end D11;
	
	data D111
		properties
			Data_Size => 24 Bytes;
	end D111;
	
	system s1
	end s1;
	system implementation s1.unbound
		subcomponents
			sub1: system a1;
			sub2: system a2;
		connections
			conn1: feature sub1.f1 -> sub2.f2;
			conn2: feature sub1.f11 -> sub2.f22;
			conn3: feature sub1.f111 -> sub2.f222;
		flows
			etef1: end to end flow sub1.fsource1 -> conn1 -> sub2.fsink2 {Latency => 10 ms .. 25 ms;};
			etef11: end to end flow sub1.fsource11 -> conn2 -> sub2.fsink22 {Latency => 10 ms .. 25 ms;};
			etef111: end to end flow sub1.fsource111 -> conn3 -> sub2.fsink222 {Latency => 10 ms .. 25 ms;};
	end s1.unbound;
	
	
	system implementation s1.async extends s1.unbound
		subcomponents
			theBus: bus {
				Transmission_Time => [
					Fixed => 1 ms .. 2ms;
					PerByte => 2 ms .. 3ms;
				];
			};
		properties
			Actual_Connection_Binding => (reference (theBus)) applies to conn1, conn2, conn3;
	end s1.async;
	
	system implementation s1.periodic extends s1.unbound
		subcomponents
			theBus: bus {
				Period => 5 ms;
				Transmission_Time => [
					Fixed => 1 ms .. 2ms;
					PerByte => 2 ms .. 3ms;
				];
			};		
		properties
			Actual_Connection_Binding => (reference (theBus)) applies to conn1, conn2, conn3;
	end s1.periodic;
	
	system a1
		features
			f1: out data port D1;
			f11: out data port D11;
			f111: out data port D111;
		flows
			fsource1: flow source f1 {Latency => 1 ms .. 2 ms;};
			fsource11: flow source f11 {Latency => 1 ms .. 2 ms;};
			fsource111: flow source f111 {Latency => 1 ms .. 2 ms;};
	end a1;
	
	system a2
		features
			f2: in data port D1;
			f22: in data port D11;
			f222: in data port D111;
		flows
			fsink2: flow sink f2 {Latency => 3 ms .. 5 ms;};
			fsink22: flow sink f22 {Latency => 3 ms .. 5 ms;};
			fsink222: flow sink f222 {Latency => 3 ms .. 5 ms;};
	end a2;
end QueuingLatency;

System s1.periodic binds the connections to a bus that has a period value binding. System s1.async binds the connections to a bus that does not have a period value binding.

Currently, flow analysis generates a sampling delay for the bus in the periodic case, but not in the asynchronous case.

[AaronGreenhouse]

This is a bit tricky to work out because of the data size of the messages. The data size is built up from the original size of the data component, plus overhead additions from the different connections, and bindings it passes through. I need to have the data size for the connect at the particular bus component. I think the easiest way to do this is the following (especially considering that the sampling delay is initially computed before the transmission delay):

1. In processSamplingTime, if there is no period binding, then we record the connection instance (which is not currently present in processSamplingTime), the bus component instance, and the latency contributor. We build up a collection of these records.
2. In some combination of processTransmissionTime and processActualConnectionBindingsTransmission we record the transmission times for all the pairs connection instance and bus.
3. In a new step, we then use information from (1) to look up the necessary transmission times from (2) and insert the result based on the recorded latency contributor.

[reteprelief]

Here is what I was thinking.
Get all connections that are bound to the bus.
Forall connection (except the one for which we want to record the latency) we calculate the transmission time (we already know how to do that for transmission time where we take care of message overhead), add them up and record the result as queuing time in a LatencyReportEntry. We do this instead of the sampling latency for periodic buses. Then as usual we calculate the transmission latency for the connection of interest and record it as transmission latency in a LatencyReportEntry.