Return to Question

I have a server-client setup where each client has a number of screens attached, and the screens together form the display. As such, the visuals displayed by each client needs to be roughly in sync. Luckily the domain is not high speed, so I don't have to have them all perfectly in sync, but obviously more in sync is better.

I am targeting a 100ms lead time between receiving states and acting upon them, I'm operating in a LAN so that is plenty, packets are sent out at 100Hz and interpolation is handled through a buffer which automatically selects the right packets. So I don't have to worry about that. Visuals are running at 60 FPS so there is minimal difference frame to frame.

Right now there are two basic solutions: 1. have each client sync with a time server over the internet or locally, or 2. emulate the same logic in the code and do the synchronization as part of establishing connection. What would be the best way to synchronize time?

I'm concerned that I'm running into an XY problem here assuming that synchronizing time this way is a good idea at all.

I have noticed that existing questions on this topic are about 1 server connecting to several clients, each showing their own visuals. I think this problem of requiring sync between clients to maintain visual continuity is a bit different, so maybe there will be different approaches. I am aware of other questions that discuss the more common situation though.

EDIT: To clarify, tests will be run later, however I am hoping someone will have some experience with synchronization and be able to suggest suitable architecture or share their own experiences to head off any problems down the line. Waiting until the last minute to adjust architecture is not ideal from my perspective.

I have a server-client setup where each client has a number of screens attached, and the screens together form the display. As such, the visuals displayed by each client needs to be roughly in sync. Luckily the domain is not high speed, so I don't have to have them all perfectly in sync, but obviously more in sync is better.

The physical network: About 10 clients need to be synced together. All clients that need to be synced are on the same gigabit LAN, latency is sub 1ms.

The network protocol: Clients are running 100ms behind real time (so there is a 100ms buffer for the server to send out updates).

The digital environment: Realistic environments moving at generally a slow speed (think rate of turn in the order of 10 degrees/minute generally, however it's possible to increase up to maybe 720 in extreme circumstances).

Requirements: There should be as little visible lag between clients as possible.

Requirements for answers: A concept is enough, pointing out the limitations or advantages to different methods would be appreciated. It would be great if it's something you've tried and had failures or successes with in the past, but spit-balling is ok too.

What a good answer would look like: "Using NTP is fine up to X ms or syncing Y clients, but if you need more accuracy than that you should look into doing Z". It doesn't need to be crazy in depth!

I have a server-client setup where each client has a number of screens attached, and the screens together form the display. As such, the visuals displayed by each client needs to be roughly in sync. Luckily the domain is not high speed, so I don't have to have them all perfectly in sync, but obviously more in sync is better.

I am targeting a 100ms lead time between receiving states and acting upon them, I'm operating in a LAN so that is plenty, packets are sent out at 100Hz and interpolation is handled through a buffer which automatically selects the right packets. So I don't have to worry about that. Visuals are running at 60 FPS so there is minimal difference frame to frame.

Right now there are two basic solutions: 1. have each client sync with a time server over the internet or locally, or 2. emulate the same logic in the code and do the synchronization as part of establishing connection. What would be the best way to synchronize time?

I'm concerned that I'm running into an XY problem here assuming that synchronizing time this way is a good idea at all.

I have noticed that existing questions on this topic are about 1 server connecting to several clients, each showing their own visuals. I think this problem of requiring sync between clients to maintain visual continuity is a bit different, so maybe there will be different approaches. I am aware of other questions that discuss the more common situation though.

I have a server-client setup where each client has a number of screens attached, and the screens together form the display. As such, the visuals displayed by each client needs to be roughly in sync. Luckily the domain is not high speed, so I don't have to have them all perfectly in sync, but obviously more in sync is better.

I am targeting a 100ms lead time between receiving states and acting upon them, I'm operating in a LAN so that is plenty, packets are sent out at 100Hz and interpolation is handled through a buffer which automatically selects the right packets. So I don't have to worry about that. Visuals are running at 60 FPS so there is minimal difference frame to frame.

Right now there are two basic solutions: 1. have each client sync with a time server over the internet or locally, or 2. emulate the same logic in the code and do the synchronization as part of establishing connection. What would be the best way to synchronize time?

I'm concerned that I'm running into an XY problem here assuming that synchronizing time this way is a good idea at all.

I have noticed that existing questions on this topic are about 1 server connecting to several clients, each showing their own visuals. I think this problem of requiring sync between clients to maintain visual continuity is a bit different, so maybe there will be different approaches. I am aware of other questions that discuss the more common situation though.

EDIT: To clarify, tests will be run later, however I am hoping someone will have some experience with synchronization and be able to suggest suitable architecture or share their own experiences to head off any problems down the line. Waiting until the last minute to adjust architecture is not ideal from my perspective.