Noteworthy-Reports.md

@@ -37,4 +37,31 @@ The second page of the report shows the same Linktest run for a different node i
 
 This information is useful from an optimization standpoint as it suggests that communication should best be kept within a CCX. If that is not possible certain quadrant-to-quadrant communications are faster than other.
 
-In conclusion this case study demonstrates that Linktest can be used to benchmark inter- and intra-CPU communication between cores. Benchmarking of CPUs in such a fashion can help to optimize software for certain architectures by providing the necessary information on how best to communicate within a CPU.
\ No newline at end of file
+In conclusion this case study demonstrates that Linktest can be used to benchmark inter- and intra-CPU communication between cores. Benchmarking of CPUs in such a fashion can help to optimize software for certain architectures by providing the necessary information on how best to communicate within a CPU.
+
+# Difference Between Uni-, Bi- & Semi-Directional Reports
+The Linktest testing method defines the results that you will get. It is up to you, the user, to interpret these results and to understand how the testing methodology affects results.
+
+When the network topology between two nodes is isotropic, a fancy terminology to say that the two nodes can communicate with the same speed in both directions the test results when using uni-directional and semi-directional testing do not differ much. Bi-directional testing results may differ, but we will get back to that later.
+
+The reason why the uni- and semi-directional results do not differ by much is because of how the connections are tested. In the uni-directional case the time-measuring node send a message to its partner and waits for a receipt message with zero length before stopping timing. To average out random variations in network performance and to reduce the effect inherent measuring delays caused by starting the and stopping the stopwatch the sending of the message and weighting for the zero-length receipt is looped over and the average time for each iteration is computed at the end.
+
+Semi-directional results are generated in a similar fashion, the difference being that the zero-length returned receipt is now the original message that was sent. Additionally the measured time is  divided by two to get a better estimate of the actual message transit time under the assumption that the two nodes can communicate with each other at the same speed.
+
+This assumption is the problem. If the two nodes can not communicate with each other with the same speed, i.e. the network topology between the two nodes is anisotropic, then the unidirectional measurement will still approximately measure the correct time for one of the nodes to send a message to its partner, assuming that sending the zero-length receipt takes a negligible amount of time. Note that the measured times for the two nodes will now differ. The semi-directional result, however, will again be similar, but be somewhere in between the two unidirectional results. This is because the semi-directional result corresponds to the average result between the two nodes.
+
+So the question is then when to use uni-directional and when to use semi-directional testing? Uni-directional testing should be used if it is expected that the connection speed between two nodes depends on the communication direction. If this is not the case, semidirectional testing will theoretically give a tighter upper-bound estimate on the actual unidirectional communication time as waiting for the zero-length receipt is not factored in to the time. Semidirectional testing should also be used if it is of interest to get an estimate of the communication performance between two nodes if they will be communicating with each other in equal parts.
+
+Bidirectional testing is a different type of test entirely. Uni- and semi-directional testing have the partner node wait till it has received the message before sending the receipt back. In bidirectional testing both nodes send a message to their partner at the same time and timing stops when the message is received. Recall that the sending of messages occurs in a loop, if this loop has only one iteration special effects can be observed. The node with a slower sending communication with its partner will counter intuitively measure lower times. This is because sending is a non-blocking communication operation, when sending a message you do not wait for it to arrive at its destination before continuing with work. However, when receiving you do wait for the message. This causes the node that is slower in sending the message to receive the message sooner that its partner, which in turn causes it to measure a lower time. If the testing loop has multiple iterations this effect averages out as in the next iteration the node with the slower sending communication needs to wait disproportionately longer for the message from its partner.
+
+What this means for bidirectional testing is that it should be used only when bidirectional communication is expected to cause communication congestion that will cause both messages to be transferred slower, or to test if this is the case. Bidirectional testing cannot pick up on network-topology anisotropy between nodes, it can, however, measure congestion effects when trying to communicate in both directions at the same time.
+
+Let us now illustrate this with an example. We have a network with two nodes `Mew` and `Mewtwo` and an auxiliary node, the `Pokémon Center`. We now conduct uni-, semi- and bi-directional tests between the nodes and find that the results between the nodes for all three tests are very similar. Here are the reports:
+
+Now `Mewtwo` catches `Pokérus`, which causes it to have to send messages with a size greater than 1 kiB via `Bill's PC`, which is only reachable via the `Pokémon Center`. All of a sudden messages from `Mewtwo` to `Mew` take a lot longer to arrive. This effect can be measured. Redoing the three tests we find very different results. Here are the reports:
+
+The changes make sense when we think of the discussion above. The network topology is now anisotropic between `Mew` and `Mewtwo`, which causes the unidirectional connection between `Mewtwo` and `Mew` to be slower. This has knock-on effects to the semi- and bi-directional tests causing the measured times to be larger. 
+
+Pokémon and its derivatives are a trademark of Nintendo, however, we believe this constitutes fair use. Note we are aware that `Pokérus` is generally a beneficial virus for Pokémon to catch, in this case though we needed a negative status ailment and `Pokérus` is the only official (computer) virus with a name.
+
+Here are the SION files: