Started by jamespetts, January 26, 2014, 01:35:08 AM
0 Members and 1 Guest are viewing this topic.
Quote from: TurfIt on February 09, 2014, 02:12:19 AMI just repeated the test locally with your server config. No timing issues encountered, as expected since the values aren't that far off default.
QuoteWhy change server_frames_ahead? The default should be fine, or even reduced. You're adding an extra 170ms latency to every client, even if they don't need it. If clients are ending up with 'execute in past' desyncs, they should adjust additional_client_frames_behind instead. That way clients with good connections aren't penalized.
Quoteserver_frames_between_checks = 256 is the default, but IMHO way too long. At 12 fps that's 21s between checks, a client could run way ahead in that time... I would drop that to 24-48 frames. A time check packet is a mere 98 bytes, times the number of connected clients, even once second, is still a bandwidth pittance.
QuoteI presume you changed server_frames_per_step to reduce CPU load? A setting of 5 and 12 fps is equivalent to 2.4 simloops. Offline the simloops target is 5.0. 2.4 isn't horrible, but things would be more responsive if you put frames_per_step back to 3 or 4. At the cost of extra CPU load of course.
QuoteFor checking packets, try Wireshark or Tshark, or even good 'ole tcpdump would do.
Quote from: jamespetts on February 09, 2014, 11:26:39 AMHmm - I am not familiar with these tools: do I need to restart the executable and attach one of these to the process somehow, as with gdb, or are they independent packet sniffers of some sort?
Quote from: jamespetts on February 09, 2014, 11:26:39 AMHmm - very curious. I don't suppose that it could have anything to do with the client being multi-threaded and the server single threaded, could it?
Quote from: jamespetts on February 09, 2014, 11:26:39 AMI had adjusted this some time ago, having found that clients were disconnecting often with the previous setting. Do you notice an unacceptable degree of latency? I could try to adjust this downwards if you think that it would help.
Quote from: jamespetts on February 09, 2014, 11:26:39 AMAhh, interesting - would increasing this value be likely to reduce desyncs due to the client running ahead?
Quote from: jamespetts on February 09, 2014, 11:26:39 AMThis was indeed to reduce CPU load: the current game is in the fairly early stages, and the load is not too intense.
Quote from: TurfIt on February 09, 2014, 06:01:03 PMSee my log in post #137. I'm looking for somebody else experiencing a burst of NWC_CHECK messages in a row, and then followed by the interactive messages with sync_step= counting up by 5. Or any other anomalies. Each NWC_CHECK should be immediately followed by an interactive message with sync_step counting up by 256 (for the current server settings).EDIT: you edited to post your log while I was posting. It does indeed contain the problem I'm seeing. Now for James to obtain the server side of things...
Quote from: AP on February 09, 2014, 12:53:25 PMBy the time we get to rail, there are going to be no corridors left between towns.Am also concerned that exclusively-passenger-services via canal seems to be profitable. Canals were mainly built for freight.
Quote from: jamespetts on February 09, 2014, 06:14:06 PMIs it server logs that you are after, or tcpdump statistics? I have command line access to the server, but there is no GUI installed. Should I simply upload the raw output from the command posted above? If so, for how long should I leave tcpdump running?
tcpdump: filename.cap: Permission denied
Quote from: jamespetts on February 11, 2014, 11:37:45 PMSdog - as you will see, I have merged your request with the server thread so that people can see your request directly. Players in this server game: if anyone feels inclined to produce a write-up as Sdog requests, this might be very interesting. Thank you for suggesting this.
Quote from: ӔO on February 12, 2014, 04:09:45 AMThe best part about the online game is that you can see what other players do to be successful.I wouldn't have known of the high speed corner exploit if it were not for the first game.