## 5 Network Setup and Results: A Case Example
### Simulation Results  
During the simulation, SHINe collects several measurements to be analysed at the end of the run, either directly in OMNeT++ through the embedded data manipulation and visualization tool (_scavetool_) or exporting the data for further elaboration (e.g., in MATLAB or GNU Octave). In the following, some measurements related to the SpaceFibre output port of the Routing Switch connected to the Sink node are shown and analysed. They are:  
* Virtual Channels utilization. This parameter is analysed to prove the correct implementation of the SpaceFibre protocol, especially for what concerns the Quality of Service mechanism.
* End-to-end packet latency. From this value, the impact of the wormhole routing can be studied, taking into account the interaction between the SpaceWire and SpaceFibre protocols.  
For what concerns the Virtual Channel (VC) utilization in the Routing Switch output port, it is important to check the simulated results (see Figure 11) against the Expected Bandwidth values. It can be seen that VC0, VC2 and VC3 use just slightly more link capacity than expected, with the expected being 10%, 30% and 35% for VC0, VC1 and VC3 respectively, while VC1 is under-using its bandwidth. This happens because VC1 is shared between the SpaceFibre and the two SpaceWire Data Sources. When the <OutputPort, VC> of the Routing Switch is assigned to one of the SpaceWire nodes, NChars are transferred slowly, precisely at 40 Mbps (i.e., 80% of the SpaceWire input link rate). This value is much lower than the 20% of the SpaceFibre output link rate (i.e., 400 Mbps) assigned to Virtual Channel 1, causing the Virtual Channel to slowly accumulate credit. Instead, when VC1 of the SpaceFibre Data Source gets the wormhole, the accumulated credit is spent, causing a short utilization peak.  
The other metric under study is the packet latency from each source to the sink. The latency is measured from the time the packet enters the transmission FIFO in the source node to the time the last byte is read out of the reception FIFO in the destination node. The results are shown in Table 4. As expected, the packets originated from the SpaceFibre source by VC0, VC2 and VC3 are not influenced by the SpaceWire nodes transmitting, being allocated to different Virtual Networks and therefore not sharing any network resource with them. Hence, the latency they experiment depends  
Figure 11: Link utilization per Virtual Channel of the Routing Switch SpaceFibre output port.  
only on the link speed and the portion of the link bandwidth (Expected Bandwidth) they have allocated (the larger the Expected Bandwidth, the faster a packet is transmitted along the link and thus the shorter its latency).  
The packets originated by the two SpaceWire nodes (the simulated one and the HIL) have higher latency, due to the packets being transmitted over much slower SpaceWire links. Finally, a similar latency is obtained for the SpaceFibre source node on VC1. This happens because it shares the Virtual Channel with the two SpaceWire nodes and, when they get the wormhole in the Routing Switch, the SpaceFibre packet has to wait for their slow complete transmission.  
The results match exactly with the expected values, proving the correct implementation of both the SpaceFibre Quality of Service mechanism and the functionality of the Hardware-in-the-Loop.