Hacker News Reader

Comment by IanCal | Hacker News Reader

One kinda related thing I find constantly amazing is that your processor running at x GHz will have had several more ticks in the time it takes the photons to go from your screen to your eyes.

(Light travels at about 30cm/1ft per nanosecond)

View on HN

In game development we can abuse this fact with things like client-side prediction in authoritative online environs. The server plays along with the client in a no-graphics mode and plays the inputs from the client, validates said moves on the server, and if all goes well sends back the response allowing for client action all before the blink of an eye. In the case of an invalid move, the server yanks the client back to the state preceeding. Pair that with some lag compensation and you've got yourself a stew.

Do you have more detailed links about that?

There's a great article by Valve: https://developer.valvesoftware.com/wiki/Source_Multiplayer_...

The Valve paper posted is amazing but huge shoutout to Photon (not affiliated) as their docs break it down really well. Their Bolt and now Fusion offerings are a boon!

https://doc.photonengine.com/fusion/current/tutorials/host-m...

what kind of latency budget do you have to do all that? even at like 15fps i cant imagine that you can provide a non janky experience when this “server yanks client back to valid state” move is done. i mean obviously you guys have figured it out, just the math doesnt quite make sense to someone like me not in gaming

Not an expert but:

The lag compensation is, more intuitively, just allowing the client to move on its own without needing server verification yet. The server maintains the authoritative game state, but (assuming no cheating is going on) the clients are able to move as they think they will. In the background, the client is actually sending its inputs to the server, and they technically haven't happened until the server verifies them (however many milliseconds later), but we allow the client to move on its own regardless.

The yanking back only happens if the client's new state (position etc.) don't match the server's state.

Think of it like the NTP protocol to for machines to sync wall-time. The idea is that there's an authoritative source of data, in this case the local time on the server. Your machine also does its best to independently track and maintain the current time. But it may be fast or slow, or experience some other issue that causes it to drift. And the longer its left by itself without syncing to an NTP server, the larger that potential drift.

So the server and the client are both independently calculating the state. But whatever the server calculates is authoritative, and the client's version is just a local simulation that is very accurate, but not 100%. Especially when it comes to other players, where your client is typically just executing under simplistic assumptions of things like constant forward movement.

However, luckily for the client, it receives a data sync from the authoritative server several times a second, so all that potential drift gets quickly corrected while the differences are still extremely small. For your own actions, where your client had access to all your input, the differences are probably even too small to notice. For other players though, it will be more noticeable, especially if there's an abrupt change in input.

My understanding is that this puts a fundamental limit on how fast CPU clocks can be. If the CPU die has a diameter of 3 centimeters, and the clock speed is a hypothetical 20 GHz, light (and electrical signals) can traverse at most half the size of the die in the course of one clock cycle. It's hard to imagine how such a CPU could work, since components at opposite sides of the die cannot communicate within a cycle.

Definitely nitpicking here, but for a modern pipelined CPU there's already lots of components of the die that aren't designed to be able to exchange data within a single clock. I don't see what would be fundamentally different about laying out a CPU die such that operations that need to happen in the same clock are physically nearby, and it seems like it would (at worst) have similar properties to multi-socket and pipelined CPUs today where cache coherency operations and branch mispredictions have multi-cycle penalties associated with them. I'm pretty sure that multi-socket CPUs can't talk in less than one clock cycle anyway.

I only had an intro course in CPU architecture, but AFAIK pipelining depends on parts of the pipeline running on the same clock. I'd say CPU manufacturers already sidestepped this limitation by using multicore dies.

No, it doesn’t. Putting aside that there is an entire field of clockless designs, asynchronous logic, free-running clocks, etc.

You should think of this as “when the cpu is processing an instruction, what does it need to track to dispatch and retire it?” Designing to a click tick is one version and kind of where things were in the 1970s. It’s an educational model.

That just means you can't have a single simple clock source fan out in a simple way across the entire chip, but that kind of design performs badly anyway.

There are lots of ways to have multiple clock sources kept in sync or to alter the clock's phase to compensate for distance, so you can keep the entire CPU synchronized even if crossing it takes multiple clock cycles.

That's not nitpicking at all. The argument about light-nanoseconds crossing a chip is very common and completely wrong.

Was going to say the same. My mind was fairly blown when I realized that light only travels approx 4 inches in a clock cycle.

Then again, every time my computer pauses for multiple seconds, me knowing how many billions of clocks cycles I’m waiting for doesn’t help my already challenged patience… haha.

Not to mention eons required for our optical organics to start registering the photons!

The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over.

In this time, my year old consumer graphics card has performed more floating point calculations than my entire town could in their entire lives.

Occasionally I work this stuff out and it's frankly hard or impossible to truly appreciate just how fast these things are.

(36 TFlops, 250ms reaction time = 9e12 calculations. One calculation every four seconds from birth to age 100 for 10,000 people is about 8e12 in total)

And once you understand how fast modern computers are, you realize how absurd it is when software is still slow. How is it that Microsoft Teams takes 15 seconds to load? How many billions of calculations does it take to put a list of names on the screen?

Never forget what they took from you.

Although it can be laziness/ incompetence wasting cycles, sometimes the problem is that only the CPU got so much faster, and only in certain ways.

If Teams talks to a remote server, doesn't matter how fast your CPU is, it takes time for the question to get to the server, time to get back, that's some time regardless. Now yes, maybe they write code which goes

Hi! / Yes? / I'm a Teams client / That's nice / And you? / I'm the Teams server, what username? / SamBankmanFried / OK, and password? / Hunter2 / OK, you're logged in SamBankmanFried / OK do I have new #catpics ? / Nope / How about #emergency ? / Nope / How about #general ? / Yes, six messages ...

And that's a lot of round trips whereas they could have done:

Hi, I'm a Teams client, hopefully you're a Teams server / Yes, I'm the Teams server, what username & password ? / SamBankmanFried password Hunter2, also summarise my new stuff / Hello SamBankmanFried, you have six #general messages ...

Which is far fewer round trips.

> The race is about to begin. I wait for the screen to flash green, finger hovering over the enter key. It flashes and I press the button immediately, and the race is over.

And you missed your window to get into BIOS, you need to reboot and try again. /s

I'm fairly sure this is more than one somebody's recurring nightmare.

No lie, my eye twitched.

Reply on news.ycombinator.com