I just repeated the test locally with your server config. No timing issues encountered, as expected since the values aren't that far off default.
Why 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.
server_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.
I 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.
For checking packets, try Wireshark or Tshark, or even good 'ole tcpdump would do.
Also, if any other players could post their logs ( simu.log after running 'simutrans-experimental -debug 3 -log' ), that could confirm it's not just me seeing this. I can't 100% rule out something with my internet connection, although I had a steady 111-113ms ping to the server the whole time during my test.