From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Roundtrip latency problem using Gnoga, on Linux, when testing at localhost address Date: Thu, 31 Mar 2016 09:38:27 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <8f3d3515-aa1a-4d7c-b465-3ad25c902ae5@googlegroups.com> <2fa7a9d8-57c6-4a9f-a81f-7f341da17cb8@googlegroups.com> NNTP-Posting-Host: bqgfK7NL3xTHnr0WRaLl4g.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:29931 Date: 2016-03-31T09:38:27+02:00 List-Id: 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