Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There Is No Now – Problems with Simultaneity in Distributed Systems

queue.acm.org

Post reply on HN
Print view View original

61–70 of 72 posts

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#61

Post by Dylan16807 »

robotresearcher wrote: post #60
Dylan16807 wrote: post #59

Earlier quoted context omitted.

Delays do not affect ordering. Relativity means that observers with different velocities view timings differently. Mere distances do not matter. Pick a reference frame for your protocol, and relativity stops being a problem. (Hint: If all endpoints are on Earth you probably won't have enough precision to even need to compensate for relativistic effects.)

Delays alone do affect the ordering perceived by receivers at different locations.

Only for a very misleading definition of ordering. Delays affect the order in which receivers see events, but the receivers can compensate for transmission factors and calculate the exact same times for all events.

Except when relativity kicks in from the observers moving at different speeds. Now events that are outside each other's light cones have no objective order.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#62

Post by Terr_ »

Dylan16807 wrote: post #58
Terr_ wrote: post #56

Earlier quoted context omitted.

Sure, other factors predominate, but even in a significantly-more-ideal world, a signal from LA to NY is still going to be a 40ms round-trip. (3940km one-way along the surface of the earth, 200,000km/s signal speed in the glass.) That's still more than enough time to require algorithmic trickery from games in order to provide the illusion of "real-time" gaming over the internet.

Think about how many console games run at 30fps. Then consider that a fully framebuffered game running at 30fps, even under ideal conditions, has 70ms of latency by the time a frame finishes displaying. 40ms isn't a big deal.

Even assuming a perfect computer with zero input latency and zero display latency the network part still matters when it comes to knitting an area like "North America" into a game region. It feeds into longer causal chains.

For example, consider two players in LA both using an NY server over the dedicated zero-overhead fiber-optic network mentioned above, with a relatively modern game-networking stack.

(1) Player A raises an energy-shield t=0 ms. (Client-prediction.)

(2) The server agrees as of t=20.

(3) Player B shot an instant-travel hitscan weapon at t=39, while the victim was still exposed on his screen.

(4) The server gets the shot-message at t=59, and honors it (Latency Compensation), sending a damage/death message out to Player A.

(5) Player A receives the news of his damage/death at t=79.

Even in that world of unattainably-good equipment, that's 80ms of "wait, that doesn't look right".

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#63

Post by vdm »

marknadal wrote: post #30

Hallelujah, we need more articles like this. I work in distributed systems, and people hate hate hate hearing the truth, let's summarize the article: 1. You cannot beat the speed of light. 2. Machines break. Even the most reliable ones. 3. Networks are unreliable. Even local area networks. 4. It is an exciting time for distributed systems: CRDTs, Hybrid Logical Clocks, Zookeeper, etc. These are things I feel like I'v…

Nice to see another example of applying CRDTs in the browser, I only knew about swarm.js. http://swarmjs.github.io/ They have a few good posts on why you would want to do this.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#64

Post by Dylan16807 »

Terr_ wrote: post #62
Dylan16807 wrote: post #58

Earlier quoted context omitted.

Think about how many console games run at 30fps. Then consider that a fully framebuffered game running at 30fps, even under ideal conditions, has 70ms of latency by the time a frame finishes displaying. 40ms isn't a big deal.

Even assuming a perfect computer with zero input latency and zero display latency the network part still matters when it comes to knitting an area like "North America" into a game region. It feeds into longer causal chains. For example, consider two players in LA both using an NY server over the dedicated zero-overhead fiber-optic network mentioned above, with a relatively modern game-networking stack. (1) Player A r…

Lag compensation has flaws, but you don't have to lag compensate. You can delay player input until the server's processed it and responded. Even better if you're clever you can delay player input by half the ping time.

Edit: Also don't double your ping by putting relay servers only on one edge of the country.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#65

Post by nuxi »

jhayward wrote: post #17

Thanks, this is a helpful introduction to the history and literature of concepts related to time in distributed systems. Most people's concept of time is quite simple and they need to be broken loose of some intuitively held, but unhelpful beliefs before they can really do engineering with respect to time. Is there a paper somewhere that new folk should read first? One that includes: - A tutorial to describe all of t…

There was a great presentation given by Tom Van Baak on measuring time, precision, accuracy etc. at this year's FOSDEM . Abstract an video are available at https://fosdem.org/2015/schedule/event/precise_time/, he has lots of additional time-related information on his website http://leapsecond.com/.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#66

Post by stcredzero »

nosuchthing wrote: post #50
stcredzero wrote: post #26

Earlier quoted context omitted.

Interesting. However I'm not just looking for syncing stats and inventory. What I'm talking about is designing a new game mechanic around the realities of distributed gaming, then designing a more robust server around that. The server will be finalizing entity positions, damage, and collisions a half second behind "real-time," and the game mechanic will be designed around this in a way that preserves player autonomy…

In competitive video games, if you give the client a large open window of freedom sooner or later you'll notice that window being used as a door by swaths of your userbase.

I thought long and hard about this. I would love it if there were tons of kamikaze tactics exploiting the additional half second of firing you have after you died. Maybe people could use this to defeat an otherwise powerful and untenable enemy.

Great!

That would mean groups of people were playing my game and cooperating to overcome huge odds in creative ways. (Players could use alts to do this, but there is already plans for a facility to let players build kamikaze drone ships without making an alt, and rigged to make this more economical.)

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#67

Post by stcredzero »

nosuchthing wrote: post #25
stcredzero wrote: post #18

With the way the world looks now, and the way it's shaping up to be in the future, we should be thinking about designing systems where there is no "now" but rather, there is instead a notion of "everything syncs soon." There can be a robust consensus reality in such a system, but it has to exist a short interval of time in the past. I'm currently working on a multiplayer game design on these principles.

Having played a multiplayer mobile game that uses a "everything syncs soon" protocol, and at the same time relies on the main mechanics of the game being timing the moves of characters against your opponents it often can lead to making the game highly unpredictable and jittery with "alternate timeline warps" when it resyncs, having nullified important moves.

Having played a multiplayer mobile game that uses a "everything syncs soon" protocol, and at the same time relies on the main mechanics of the game being timing the moves of characters against your opponents it often can lead to making the game highly unpredictable and jittery with "alternate timeline warps" when it resyncs, having nullified important moves.

Nope. Most designers pick a particular mechanic and try to make that exact mechanic work over the network. If you abandon the particular mechanic and aim on meta-goals, one of which might be no jitters, resyncs, and (visible) alternate timelines, then you can eliminate everything you just mentioned above.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#68

Post by nosuchthing »

stcredzero wrote: post #67
nosuchthing wrote: post #25

Earlier quoted context omitted.

Having played a multiplayer mobile game that uses a "everything syncs soon" protocol, and at the same time relies on the main mechanics of the game being timing the moves of characters against your opponents it often can lead to making the game highly unpredictable and jittery with "alternate timeline warps" when it resyncs, having nullified important moves.

Having played a multiplayer mobile game that uses a "everything syncs soon" protocol, and at the same time relies on the main mechanics of the game being timing the moves of characters against your opponents it often can lead to making the game highly unpredictable and jittery with "alternate timeline warps" when it resyncs, having nullified important moves. Nope. Most designers pick a particular mechanic and try to…

If you'd like to share I'd love to hear how you approach solving sync issues with multiplayer time sensitive games.

Starcraft/Warcraft RTS games seem to force every client in the same "room" to slow down if other clients report back bad/slow sync clocks, FPS games like CS/HL engine based will penalize single clients if they lag, and the worst I've seen was a mobile game by SNK which seems to rely on and give too much information to the client which has resulted in many users abusing such protocols.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#69

Post by robotresearcher »

Dylan16807 wrote: post #61
robotresearcher wrote: post #60

Earlier quoted context omitted.

Delays alone do affect the ordering perceived by receivers at different locations.

Only for a very misleading definition of ordering. Delays affect the order in which receivers see events, but the receivers can compensate for transmission factors and calculate the exact same times for all events. Except when relativity kicks in from the observers moving at different speeds. Now events that are outside each other's light cones have no objective order.

That definition of ordering is of course the standard, everyday definition. And to guarantee correct compensation for transmission factors in the same frame, do we not require perfectly synchronized local clocks: impossible in general?

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#70

Post by Dylan16807 »

robotresearcher wrote: post #69
Dylan16807 wrote: post #61

Earlier quoted context omitted.

Only for a very misleading definition of ordering. Delays affect the order in which receivers see events, but the receivers can compensate for transmission factors and calculate the exact same times for all events. Except when relativity kicks in from the observers moving at different speeds. Now events that are outside each other's light cones have no objective order.

That definition of ordering is of course the standard, everyday definition. And to guarantee correct compensation for transmission factors in the same frame, do we not require perfectly synchronized local clocks: impossible in general?

>That definition of ordering is of course the standard, everyday definition.

I would disagree and say the standard definition is the order things happen in, not when you feel the effects. There's rarely a different in practice, though, because people usually experience things via sight at a distance of miles at most. And in one of the few places where it differs, astronomy, people talk all the time about how events 'actually' happened a massive amount of time in the past.

But that doesn't matter. We're talking about relativity. Order, when talking about relativity, clearly means the timing of the events themselves, not the reception of the events.

You need such a definition before you can understand the ways even that can vary per observer. And importantly, the specific ways it can't vary per observer.

>And to guarantee correct compensation for transmission factors in the same frame, do we not require perfectly synchronized local clocks

Not at all. We do need to agree on a same reference frame (because different reference frames give different rates of time and different distances). Thankfully everyone on earth is in the same reference frame to a very very precise degree. And if that's not good enough you can do a few calculations to get nearly perfect compensation for different altitudes and latitudes and such.

Our clocks don't have to be in the same century to say that light A went on before light B. You just take the point in time you saw each fiber light up and subtract the distance of the fiber times propagation speed. And then you could set both clocks to be in sync by using A or B as a reference point, if you wanted.

Post reply on HN