Live data from Hacker News

There Is No Now – Problems with Simultaneity in Distributed Systems

queue.acm.org

51–60 of 72 posts

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

#51
post #11

Keeping an always consistent state in a large distributed you are fighting against the law of physics. Like it is mentioned, Google did it with their F1/Spanner SQL database. But that also mean GPS receivers with antennas on the roofs of data centers. Which is yet another thing that can fail and it, either by itself or in a cascade of other failures will lead to unspecified and possibly undesirable behavior. Recently…

> Recently I see a lot of advocates of dropping NoSQL databases and moving back to Postgress or other SQL databases. This is just from a vocal minority on HN. You just need to look at the facts. Companies like Mongo, Datastax, Aerospike etc are growing bigger by the day, with increasingly higher valuations. Old school database companies like Teradata are now all about datalakes incorporating Hadoop and Mongo. And tec…

The advocates of dropping NoSQL and returning to SQL databases are indeed a minority — as the majority never went away from SQL databases, especially for the purposes they fulfil well.

Right tool for the job and all that stuff.

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

#52

Earlier quoted context omitted.

> Recently I see a lot of advocates of dropping NoSQL databases and moving back to Postgress or other SQL databases. This is just from a vocal minority on HN. You just need to look at the facts. Companies like Mongo, Datastax, Aerospike etc are growing bigger by the day, with increasingly higher valuations. Old school database companies like Teradata are now all about datalakes incorporating Hadoop and Mongo. And tec…

The advocates of dropping NoSQL and returning to SQL databases are indeed a minority — as the majority never went away from SQL databases, especially for the purposes they fulfil well. Right tool for the job and all that stuff.

Again the facts simply don't agree with you. Companies have been moving away from SQL databases in droves compared to the 1990s. And why wouldn't they ? Vendors like Oracle, Microsoft, IBM etc have been screwing them over for ages. Low cost data lakes are the new norm.

Of course I am talking about middle to enterprise companies. I am sure for individuals a typical LAMP setup is still going to be fine. But then again many of those are running their apps in the cloud and hence want a database that is resilient in the face of node outages. MySQL and PostgreSQL are both a PITA to get this right compared to almost every NoSQL database.

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

#53
Another fun exercise is dealing with players who say "OMG teh netcode sux" for online first-person shooters, especially when they have patently unrealistic expectations for how well the software should break the speed of light.

Sometimes the hardest part is getting them to understand exactly how much of what they take for granted is an illusion... Often even before any packets leave their machine.

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

#54
post #53

Another fun exercise is dealing with players who say "OMG teh netcode sux" for online first-person shooters, especially when they have patently unrealistic expectations for how well the software should break the speed of light. Sometimes the hardest part is getting them to understand exactly how much of what they take for granted is an illusion... Often even before any packets leave their machine.

It's less speed of light at fault than other factors, though. Bufferbloat is terrible, and it's hard to make netcode that reacts well when a few percent of packets are lost or slow.

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

#55

Earlier quoted context omitted.

The advocates of dropping NoSQL and returning to SQL databases are indeed a minority — as the majority never went away from SQL databases, especially for the purposes they fulfil well. Right tool for the job and all that stuff.

Again the facts simply don't agree with you. Companies have been moving away from SQL databases in droves compared to the 1990s. And why wouldn't they ? Vendors like Oracle, Microsoft, IBM etc have been screwing them over for ages. Low cost data lakes are the new norm. Of course I am talking about middle to enterprise companies. I am sure for individuals a typical LAMP setup is still going to be fine. But then again…

> Again the facts simply don't agree with you. Companies have been moving away from SQL databases in droves compared to the 1990s.

Do you have any links to said 'facts'? Otherwise your comments are just hearsay and anecdote.

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

#56
post #53

Another fun exercise is dealing with players who say "OMG teh netcode sux" for online first-person shooters, especially when they have patently unrealistic expectations for how well the software should break the speed of light. Sometimes the hardest part is getting them to understand exactly how much of what they take for granted is an illusion... Often even before any packets leave their machine.

It's less speed of light at fault than other factors, though. Bufferbloat is terrible, and it's hard to make netcode that reacts well when a few percent of packets are lost or slow.

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.

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

#57
post #55

Earlier quoted context omitted.

Again the facts simply don't agree with you. Companies have been moving away from SQL databases in droves compared to the 1990s. And why wouldn't they ? Vendors like Oracle, Microsoft, IBM etc have been screwing them over for ages. Low cost data lakes are the new norm. Of course I am talking about middle to enterprise companies. I am sure for individuals a typical LAMP setup is still going to be fine. But then again…

> Again the facts simply don't agree with you. Companies have been moving away from SQL databases in droves compared to the 1990s. Do you have any links to said 'facts'? Otherwise your comments are just hearsay and anecdote.

Indeed. I suppose it depends on the circles in which one runs but there are still companies actively writing COBOL (or were as of 2011 as far as I can personally verify).

And they were making millions of dollars from that one small segment of the company.

I'd wager that in the enterprise (whatever that means) that where NoSQL is used in companies more than, say, 10 years old, it is generally for non-critical, exploratory one off projects. I don't even think NoSQL is close to 50% market share among what I'll call the silent majority of more conservative, more enterprisey tech companies/IT departments. I have no figures to back that intuition up with, however.

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

#58
post #56

Earlier quoted context omitted.

It's less speed of light at fault than other factors, though. Bufferbloat is terrible, and it's hard to make netcode that reacts well when a few percent of packets are lost or slow.

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.

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

#59

Spanner is externally serializable so you do get a 'now'. You just don't know what the agreed now was until after the write. The idea that there is no 'now' is of course, preposterous, we have very strict laws of physics supporting the concept of now (sans relativity) and eventually our engineering will be able to track that very accurately. Spanner is a step on that journey. These kinds of 'impossible' articles will…

> we have very strict laws of physics supporting the concept of now (sans relativity) Laws of physics "sans relativity" aren't the actual laws of physics in our universe. There very much is no now except the now that is also here . Its quite accurate to say that simultaneity does not exist in distributed systems, and simultaneity is less valid as even an approximation the more widely distributed a system is.

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.)

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

#60

Earlier quoted context omitted.

> we have very strict laws of physics supporting the concept of now (sans relativity) Laws of physics "sans relativity" aren't the actual laws of physics in our universe. There very much is no now except the now that is also here . Its quite accurate to say that simultaneity does not exist in distributed systems, and simultaneity is less valid as even an approximation the more widely distributed a system is.

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.
Post reply on HN