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:
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.