... | ... | @@ -12,7 +12,7 @@ A application programming interface facilitates the interaction between differen |
|
|
The act of collecting data to compare things. Linktest benchmarks communication APIs and the associated hardware by measuring how long it takes for a message to be sent back-and-forth between two tasks, which allows for the comparison to the time it takes the same message to be sent back-and-forth between a different pair of tasks or using a different communication API.
|
|
|
|
|
|
## Mode
|
|
|
The `--mode` command-line option defines which communication API Linktest benchmarks. As a shorthand `-m` can be used. See XXX for a list of supported communication APIs.
|
|
|
The `--mode` command-line option defines which communication API Linktest benchmarks. As a shorthand `-m` can be used. See [Communication API](#communication-api) for a list of supported communication APIs.
|
|
|
|
|
|
## Bidirectional Testing
|
|
|
Not to be confused with bisection testing. In bidirectional testing messages are sent between tasks asynchronously. Normally Linktest benchmarks communication times by sending a message from one task in pair to the other and then the other sends the same message back. In bidirectional testing both tasks send messages to each other at the same time. This means that neither task weights on the other before sending their message. Such communication is more taxing between two tasks but also commonly faster because neither task has to wait on the other before send their message. Bisection testing can be turned on by specifying the `--bisection` command-line option.
|
... | ... | @@ -40,22 +40,22 @@ Linktest supports the following communication APIs: |
|
|
|
|
|
Note that during Linktest installation only desired supported communication APIs are installed. As such a given Linktest executable may not support all the listed communication APIs. By default all communication APIs are supported after installation.
|
|
|
|
|
|
## <a name="Glossary-Communication_Time"></a> Communication Time
|
|
|
## Communication Time
|
|
|
The communication time in Linktest is the time it takes from when a message is ready to be sent till it arrives at the recipient and a receipt is returned. Linktest tests two-way communication times, which is the time it takes between the message being ready to be sent till that message is returned and a receipt is sent. This is referred to as the two-way communication time. As opposed to the one-way communication time which is the time from the message-being ready to be sent till a receipt is received that the message has been successfully delivered. If bidirectional testing is used, both communication partners send their identical messages at the same time and timing ends when a partner receives a receipt.
|
|
|
|
|
|
In a gross oversimplification the communication time consists of two parts, the latency and the transit time. The latency is the time from the message being ready to be sent till sending actually begins. During this time, for example, the connection used to transmit the message is initialized. The transit time is the time it then takes the message to get from its origin to its destination and for a receipt to go back to the destination that the message has been successfully received.
|
|
|
|
|
|
For small message sizes the communication time is dominated by the latency. For large message sizes the communication time is dominated by transmit time, which depends on the communication bandwidth. As such to benchmark communication latency message sizes as small as possible should be used, ideally 0, but messages must have a non-zero message size, as such 1 should be used. To benchmark transmit times, and indirectly bandwidth, as large as possible, although often as large as feasible, should be used. This ensures that the latency plays a vanishing role in the communication time. Why should message sizes as large as feasible and not as large as possbiel be used here? The answer is that as message size increases the length of time for the benchmark also grows and too large messages sizes might make Linktest take too long.
|
|
|
For small message sizes the communication time is dominated by the latency. For large message sizes the communication time is dominated by transmit time, which depends on the communication bandwidth. As such to benchmark communication latency message sizes as small as possible should be used, ideally 0, but messages must have a non-zero message size, as such 1 should be used. To benchmark transmit times, and indirectly bandwidth, as large as possible, although often as large as feasible, message sizes should be used. This ensures that the latency plays a vanishing role in the communication time. Why should message sizes as large as feasible and not as large as possible be used here? The answer is that as message size increases the length of time for the benchmark also grows and too large messages sizes might make Linktest take too long. This is often the case when testing connections serially.
|
|
|
|
|
|
## Latency
|
|
|
The time it takes before an action can be executed. For Linktest this is the time it takes between a message being ready to be sent till sending begins.
|
|
|
|
|
|
For the relationship between latency transit time and message size see `[Communication Time](#Glossary-Communication_Time)`. TODO: Link
|
|
|
For the relationship between latency transit time and message size see [Communication Time](#communication-time).
|
|
|
|
|
|
## Message Size
|
|
|
The message size is used to refer to the size of messages in bytes used by Linktest to benchmark communication. The relationship between message size and communication/transit time is complex.
|
|
|
|
|
|
For the relationship between latency transit time and message size see Communication Time. TODO: Link
|
|
|
For the relationship between latency transit time and message size see [Communication Time](#communication-time).
|
|
|
|
|
|
## Number Of Messages
|
|
|
Linktest benchmarks communications by repeating a communication many times. The amount of times it repeats the sending of messages for timing purposes is controlled via the `--num-messages` command-line argument. This defines how many times the back-and-forth sending of messages is repeated for timing purposes. The final returned times are the average time it took the message to be sent back-and-forth.
|
... | ... | @@ -69,7 +69,7 @@ By default Linktest tests as many connections as possible in parallel, this, how |
|
|
## Transit time
|
|
|
Transit time is the time it takes for an object to go from its origin to its destination. During this travel period the object is said to be in transit. For communication times, i.e. the time the message is in transit
|
|
|
|
|
|
For the relationship between latency transit time and message size see Communication Time. TODO: Link
|
|
|
For the relationship between latency transit time and message size see [Communication Time](#communication-time).
|
|
|
|
|
|
## Transport Layer
|
|
|
In the OSI model a transport layer is conceptual division of the methods and protocols related to the transport of information, generally in terms of bytes. In Linktest it defines the API (the aforementioned methods and protocols) used to communicate data between, or within, systems. It is generally used in conjunction with which communication-API Linktest should test, which is controlled over the `--mode` option. It, however, should not be confused with the communication API used for testing. The transport layer is an abstract concept. Linktest uses the communication API for the actual establishment and testing of connections. |
|
|
\ No newline at end of file |