| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has quit IRC (Ping timeout: 256 seconds) | 03:19 | |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has quit IRC (Read error: Connection reset by peer) | 06:28 | |
| *** Flash <Flash!~Flash@user/flash> has quit IRC (Ping timeout: 255 seconds) | 08:31 | |
| *** Flash <Flash!~Flash@user/flash> has joined #bzflag | 08:38 | |
| BZNotify | bzflag: atupone opened pull request #312 "Do not block on tcp recv" (https://github.com/BZFlag-Dev/bzflag/pull/312) | 08:50 |
|---|---|---|
| tupone | I need review on that before merging, as it is critical code | 08:51 |
| *** I_Died_Once <I_Died_Once!~I_Died_On@c-73-184-170-223.hsd1.ga.comcast.net> has joined #bzflag | 09:03 | |
| *** Optic_Delusion <Optic_Delusion!~Optic_Del@2600:4041:194:ff00:c9a:496b:8927:798b> has quit IRC (Ping timeout: 264 seconds) | 09:56 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has quit IRC (Ping timeout: 240 seconds) | 11:18 | |
| *** the_map <the_map!~the_map@user/the-map/x-5158391> has joined #bzflag | 11:26 | |
| blast007 | tupone: is there a way to force a situation that triggers the issue? maybe a reduced MTU on a server to force fragmentation and then using the 'tc' (Traffic Control) command to induce a bunch of packet loss/corruption? | 12:19 |
| tupone | a reduced MTU maybe can help | 12:20 |
| tupone | if there is packet loss while trasmitting big messages then tcp should wait until the next fragment is retransmitted | 12:22 |
| tupone | and also only having MTU less then the biggest packet transmitted on TCP should raise the problem (increased jitter) | 12:23 |
| blast007 | regarding adding loss to TCP with tc, "When loss is used locally (not on a bridge or router), the loss is reported to the upper level protocols. This may cause TCP to resend and behave as if there was no loss. When testing protocol reponse to loss it is best to use a netem on a bridge or router" https://wiki.linuxfoundation.org/networking/netem#caveats | 12:24 |
| tupone | well TCP does recover loss, but there will be delay between one fragment and the other | 12:26 |
| blast007 | yeah | 12:27 |
| tupone | even packet reordering could help or packet delay, but we need to be sure that messages are broken in two | 12:29 |
| blast007 | hehe, I was just typing a message that was basically the same :) | 12:30 |
| blast007 | I'll see about spinning up a VM this weekend to come up with some worst case scenarios | 12:31 |
| tupone | our transmitter try to avoid that disabling NAGLE algorithm, but you never be sure what happens | 12:31 |
| tupone | if that change works, maybe we do need to do the same server side, while receiving from client. Code is not the same, and I have not analyzed what to do | 12:33 |
| blast007 | might be harder to determine if the server is affected since you can't visibly notice the graphics freeze :) | 12:38 |
| blast007 | I guess if the spike is distinct enough then profiling that code (or at least writing out the durations for that code block) could help identify the issue on the server-side too | 12:41 |
| blast007 | https://news.ycombinator.com/item?id=10608356 Might be interesting to try using TCP_QUICKACK (or equivilent) instead of TCP_NODELAY. | 13:59 |
| blast007 | wonder what our shortest packets are and how often they are sent | 14:00 |
| blast007 | (that link might be down at the moment) | 14:10 |
| *** Sgeo <Sgeo!~Sgeo@user/sgeo> has joined #bzflag | 15:25 | |
| BZNotify | bzflag: atupone synchronized pull request #312 "Do not block on tcp recv" (https://github.com/BZFlag-Dev/bzflag/pull/312) | 17:11 |
| tupone | also FPS increases (seems, not sure) | 17:31 |
| *** Harlin__ <Harlin__!~DonQixote@75-163-171-189.clsp.qwest.net> has quit IRC (Read error: Connection reset by peer) | 21:15 | |
| *** Harlin__ <Harlin__!~DonQixote@75-163-171-189.clsp.qwest.net> has joined #bzflag | 21:16 | |
Generated by irclog2html.py 2.17.3.dev0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!