Check out some math and numbers that make me feel dumb, and make the server feel great with CCP Prism X's new Dev Blog.

is there any kind of support for university papers ? i might actually be interested (not on a technical level, but for markets or politics)

Ive heard the words "Brain in a Box" quite a bit and seen vague descriptions of it having to do with preparing session change data on a separate node. But is there a full description somewhere? What it does, how much load it will remove, and so on?

You really think a company, running the largest gaming cluster for over 10 years now would not have already bought a stock solution if it worked for them? Cute.

As far as the metagame is concerned, even without a published node map it's going to be exploited. For example in a defensive Sov war, if most of a region is on the same node it's not going to be hard to find a linked system by trial and error and dock/undock repeatedly to cascade the entire node (most of a region in the current scheme) into a sustained 10% tidi to discourage siege fleets from grinding structures.

"Stock Solution"?

I'm not sure you appreciate the complexity it would take to roll out such a massive deploy and use live migration all while pumping the entire local network through virtual switches.

Easy it isn't...

Environment integration and live rollout of a technology have nothing to do with it. First that technology has to solve your particular problem. And yes, VMware ESX / vMotion "live migration" is pretty much a stock solution as far as virtualization goes.

TQ "nodes" are not machines, they are processes. With each process serving multiple solar systems. For that reason, you can't move a high-use solar system by moving a virtual OS around.

As far as workarounds go, one could run one virtual server with a single process running a single solar system for every system, sure. With all the increased overhead that brings along with it. And I am equally sure some Dev at CCP evaluated that already. And the fact that they did not adopt it (or something similar) means it did not work for them.

And if all that is sorted out, the EVE server code runs at 1HZ. Freezing a node for 2 seconds to copy it over to somewhere else are 2 missed server cycles that the clients have to resynchronize with again.
Which means a major redesign and rewrite of the network code on the client and server side.

For those kind of development resources, you need a really strong business case. And while dynamically reinforcing nodes is a nice target, we push those into TiDi as well. All the time. Which means it's essentially a band-aid. Not something you get a man-year of development effort approved for.

The underlying VM has no idea at all it's been moved.

And since it's taken a nontrivial amount of time to move relative to the 1HZ physics engine, meaning that the odds are very good that your half a second will cross a tick boundary, that means that every move must be followed by a resync with adjacent systems to get everyone back on the same page, right? If one node is off by a server tick, how do you handle that?

And since it's taken a nontrivial amount of time to move relative to the 1HZ physics engine, meaning that the odds are very good that your half a second will cross a tick boundary, that means that every move must be followed by a resync with adjacent systems to get everyone back on the same page, right? If one node is off by a server tick, how do you handle that?

Vmotion at least is truly transparent to the underlying VM. You will see a "pause" but incoming network packets etc. are not dropped ,just queued while the machine is in motion afaik.

During TiDi different systems are not running in sync either.

(I'm not saying this as a proof that this will be easy, rather as anecdotal evidence for it.)

Nope.

Set up a continuous ping of a VM, then vmotion it, and you'll see a couple of dropped packets.

Ping is connectionless and has a timeout of 3 seconds.

A TCP connection is - duh! - connection based, and usually the timeout is at 30 seconds.

Perfect? No.

But a dropped ping doesn't necessarily mean a dropped connection.

Maybe I'm misunderstanding something, but as far as I can tell this will only have a negative effect on the quality of game play in regards to already painful fleet combat.

Frankly I don't remember the last time I was in a full fleet and there wasn't heavy Ti-Di. Every time a solitary 250 man fleet jumps a gate the system spikes to 10% tidi for 30-45 seconds. Even if every fleet fight was on an individual reinforced node (reinforced nodes are the exception, not the rule) the issue of gate Tidi is going to be exponentially worse under the new regional scheme since every individual fleet in the area traveling to (or from) the combat system is going to be sequentially triggering gate lag on the same node. It's going to be a particularly painful change given the recent quality of life hits to the majority of fleet ships, there's nothing fun or engaging about staring at a warp tunnel for 10 minutes per system the entire trip home.

As far as the metagame is concerned, even without a published node map it's going to be exploited. For example in a defensive Sov war, if most of a region is on the same node it's not going to be hard to find a linked system by trial and error and dock/undock repeatedly to cascade the entire node (most of a region in the current scheme) into a sustained 10% tidi to discourage siege fleets from grinding structures.

Yes the old system wasn't perfect, but the guy ratting in an empty system halfway across EvE could have just moved over to a different system and continued ratting. Maybe this is the right solution for Empire where loads are usually steady from day to day but it's the wrong approach in Nullsec.