Started by freddyhayward, September 24, 2020, 08:48:53 AM
0 Members and 1 Guest are viewing this topic.
Quote from: Matthew on September 28, 2020, 11:49:02 AMFreddy, thank you for reworking the debug sums system to get more useful results. I take it that this can be combined with the new pause-on-desync feature to identify the convoy that caused that desync (where that is the cause). Could you please post a simple explanation of how to join the dots in the log file?
Quote from: freddyhayward on September 28, 2020, 11:51:06 AMI have edited this into the original post. Please let me know whether anything there needs clarification.
Quoteserver=[ss=432121 st=36010 nfc=1 rand=2601725695 halt=1415 line=1 cnvy=2049 ssr=2031812834,0,2031812834,2031812834,2601725695,2601725695,2601725695,0 str=963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,4175980762 exr=4175980762,2031812834,2031812834,0,0,0,0,0 sums=505501,924070409,24433,25200,6,0,0,0,94234,94022]client=[ss=432121 st=36010 nfc=1 rand=4025026073 halt=1415 line=1 cnvy=2049 ssr=2031812834,0,2031812834,2031812834,4025026073,4025026073,4025026073,0 str=963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,963854789,4175980762 exr=4175980762,2031812834,2031812834,0,0,0,0,0 sums=505501,924070409,24433,25200,6,0,0,0,94234,94022]
clear_random_mode( INTERACTIVE_RANDOM );sync.sync_step( delta_t );
Quote from: Matthew on June 26, 2021, 11:03:28 PMAfter several weeks generally free of desyncs, I have had several this evening (Europe). They have this pattern:Freddy also had desynchs following this pattern a few days ago (17 June).I think that indicates that the desync is between debug sums 3 and 4, whicb contains these lines of code:Code Select Expandclear_random_mode( INTERACTIVE_RANDOM );sync.sync_step( delta_t );That second line appears to be the convoy movement code. But the game does not report a particular convoy as having problems in the last line of the 'desync report'. So I am not sure how to investigate further.
Quote from: Matthew on August 21, 2021, 03:53:18 PMAs of today's update (#f00df43) I am desynching about every 15 minutes, which is worse than before. So far the desync is always between rands 3 and 4, i.e. in sync.sync_step, but obviously that doesn't tell us much. I'm on Linux. I realize this unlikely to be fixed immediately, but thought it might be useful data.By the way, I can't find commit #f00df43 in the repo, so maybe last night's build included something that has subsequently been reverted?
Quote from: jamespetts on August 21, 2021, 04:14:28 PMI believe that the reason that the build numbers on the compiled binaries is different to the numbers on the Github repository is that there has to be a merge to the build server because some configuration files have changed sligthly.
QuoteCan I ask how frequent the losses of synchronisation were before the latest update?
Quote from: zook2 on September 01, 2021, 12:04:48 PMI had a desynch at about 13:00 GMT. I pinged the server a few times; average times were between 120ms and 230ms. I have no idea what a good latency would be.
Quote from: zook2 on September 21, 2021, 03:13:43 AMJust an observation that could be a random effect: tonight I cut a rail line, causing an incoming train to stop with a "No route" message. I desynched before I could rebuild that one tile. My next four or five attempts to log in failed with immediate or almost immediate desynchs. That was pretty late and, after Freddy left, with no other player on the server for hours. Finally, I managed to quickly fix the line, the "No route" nagging stopped and so did the desynchs.
Quote from: zook2 on September 21, 2021, 06:40:38 PMWarning: NWC_CHECK: time difference to server 33600
Quote from: jamespetts on October 18, 2020, 12:51:17 PMNonetheless, it is worthwhile to try to remedy these if possible, especially the most common types. The most common types so far seem to be convoy movement based losses of synchronisation (debug sums) and halt based losses of synchronisation (rands). As to the latter, the code in the haltestelle_t::step() function most likely to show a divergence of random numbers is check_transferring_cargoes, which, when dealing with passengers, invokes the RNG by generating local pedestrians whenever passengers are released from their transferring state. We already have a system to check part f this, being debug sums 6 and 7 for checking the number of transferring cargoes before and after the passenger and mail generation have run. May I suggest that future loss of synchronisation logging should explicitly check whether there is any divergence in debug sums 6 and 7 when recording a loss of synchronisation at rands?
Quote from: Matthew on September 21, 2021, 08:32:00 PMMaybe people more experienced than me will see some flaws in this idea, so please speak up if you see them!
QuoteThis suggests that your PC is not fast enough to keep up with the server.
Quote from: zook2 on September 21, 2021, 08:36:55 PMWhat if the server switched pedestrians off completely to see if that makes a difference?