Re: Roundtrip latency problem using Gnoga, on Linux, when testing at localhost address

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 31/03/2016 07:23, Jeffrey R. Carter wrote:
> On Wednesday, March 30, 2016 at 11:35:59 AM UTC-4, Olivier Henley wrote:
>>
>> I am trying a small multiplayer 2d game using Gnoga and Phaser.io and and I
>> am experiencing some 80 ms for any roundtrip test when trying my game at
>> 127.0.0.1:8080. I profiled javascript and it looks like it take 0.4 ms on
>> the client side to process round_trip().
>>
>> Anyone has an idea about what is wrong?
>
> AFAICT, nothing is wrong, unless you have timing requirements that aren't being
> met. Since you're talking about a game, and 80 ms is too short for a human to
> notice, I don't see that you have a problem.

Still it could be indication of a problem or a bug. Usual suspects are:

1. The measurement procedure.

1.1. Artifacts of process switching.
1.2. Wrong clock used. System clocks may be very coarse. In many OSes 
they are driven by the timer interrupts or from an inferior clock 
source. Real-time clock at the processor's or the front bus' tact must 
be used in round-trip measurements.

2. HTTP. It is a very poor protocol. Much depends on the 
connection/session settings. E.g. if a new session is created for each 
measurement it is to expect a quite poor performance. Creating and 
connecting sockets is expensive.

3. Socket settings

3.1. TCP_NO_DELAY and sending packets in full is essential to short 
latencies. The frame coalescing algorithm timeout depends on the system 
settings. Usually it is close to 100ms. Which means that you could have 
sporadic latency spikes depending on the state of the TCP buffer when 
the traffic is low.

4. OS, TCP stack system settings

4.1. Poor Ethernet controller, especially bad are integrated ones. The 
worst are ones connected over USB/COM. Many boards have ones sitting on 
top of an UART.

Then, it could be a software bug. The Simple Components server gets a 
notification when there is free space in the output buffer, ready to 
send more data out. When the traffic is low, the output buffer is never 
full and this means that, in effect, the buffer-ready signal is always 
set. Thus dealing with the socket output becomes in effect busy waiting. 
That in turn leads 100% load of the CPU's core running the server. In 
order to prevent that the server stops waiting for the buffer-ready 
signal when there was nothing to send. When a new portion of output data 
appears the socket waiting is resumed. There is a certain timeout to 
look after the socket regardless. If there is a bug somewhere that 
prevents the resuming, it may expose itself as sporadically increased 
latencies during sending data out. The latency must then be close to the 
timeout value. [This is similar to the effect of TCP_NO_DELAY not set]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de