Hi, I am under the impression that the latency delays introduced by the latency feature should be random, but they do not appear to be, even with correlation set to 0%.
There is a clear bias for higher latency values and resultant jitter is consistently lower than expected. I.e.the randomness of the jitter is not spanning the full expected range.
If you try and set the min latency to 100 and max to 300, with 0 correlation. As the minimum latency goes up you will see that the distribution starts to edge up.
SoftPerfect Connection Emulator
Latency/delay is not perfectly random
Started by Cesar
Cesar
Latency/delay is not perfectly random 13 March 2023, 15:31 |
Re: Latency/delay is not perfectly random 13 March 2023, 15:50 |
Admin Registered: 10 years ago Posts: 893 |
Thank you for providing feedback on the latency test findings. We have rerun the tests with the delay of 100-300ms, and the results were mixed. During the first session, the ping times edged up towards 200+ milliseconds, like in your case. However, in the second session, after a reboot, there was an even distribution between 100 and 300ms.
Based on this analysis, there may be two factors at play here:
Based on this analysis, there may be two factors at play here:
- The random number generator may produce an uneven distribution. We have just updated the application to re-initialize the PRNG before each session to ensure it produces an even distribution every time.
- It is more likely that other traffic passing through the Emulator during the session caused the latency issues. For example, if Windows decided to download updates during a session, its packets would be queued up with the packets from the connection we want to apply latency to. This could result in extra time added to the latency. In such cases, if the software queues 100 packets from the connection we are not interested in and 1 packet from the connection we are interested in, the last packet may experience more delay while the software clears up the 100 packets before it.
To deal with this issue, I suggest setting up a filter within the Emulator that only applies latency to the traffic of interest. This will prevent any other traffic from being queued up and passed through directly, resulting in stable and evenly distributed latency between set values.