How can CCP increase node performance?

With how common high end workhorse GPUs are now, and Xeon Phi co-processors, I believe with a rewrite of the node systems code, node performance can be greatly increased to the point of minimal lag. This in turn will attract so many more players, and bring back old players. Why haven’t they done this? With modern processors and a 15+ year old game, there shouldn’t be any lag no matter the battle size…

1 Like

You can see for yourself what kind of hardware CCP has

They already use the Everest nodes for large battles. Before it was 2k players that capped out a node, then CCP upgraded and now it is 5-6k and we continue to push the limits.


If only they had left it at 2-3k people. this way, there would have been enough processing power available to make big fights happen with limited tidi and performance issues, and they would be more enjoyable.

They didn’t cap systems at 2-3k players (to my knowledge). That was just what it took for the server to poop its pants and start crying while its friends look at each other awkwardly.

Now the capabilities of the server are higher, that 2-3k becomes 5-6k.

1 Like

The cap wasn’t a system cap but a performance cap. You can’t do arbitrary system limits as they would be gamed by one side or the other to prevent a fight.

1 Like

Someday processing power will exceed the PCU count and we’ll all rejoice.
It remains to be seen which side of that equation goes up or down

1 Like

They’re making remarkable advancements in quantum computing. I have to imagine that will help dramatically, when that becomes a mature technology. Exciting times!

1 Like

Well, the expert has spoken. Now that OP has told CCP how easy it is I’m sure we’ll have a solution by the end of the week.


On a reinforced node only. When the onlining Keepstar in Jaymass was destroyed, the unreinforced system was max’d out at barely 2000 with maximum Tidi and lag.

1 Like


Had the players who intended to destroy the keepstar notified CCP, that node would have been reinforced though.

I do agree that TiDi and excessive server load break the enjoyment of the game… it becomes an objective to accomplish rather than “hey I’ma go shoot that thing for a pretty explosion”. You do it because you know it needs to die… not because you want to kill it.

For my part, my suggested solution was to allow for greater division of nodes. Up to (in my suggestion at least) 4 Everest nodes per system, with reasons for players to spread out and actually be on those 4 separate servers. Yea you’d have issues like session changes… but they’d be WAY less aggravating than what we saw at 9-4.

Either way… it was an unprecedented load. Some foresight can be expected, but…

1 Like

I’m a programmer. I’m just stating they’re using general purpose CPU’s when they could be offloading a significant portion to something that can do parallel processing much better, like the phi coprocessors.

Don’t forget that EVE is running on one single server, 2 if you count the Chinese, I can’t mention any other MMORPG that does that. Granted that the single EVE server there is is divided up into several smaller nodes. I’m also pretty sure that EVE is more calculation heavy than most other games I know.

It’s not just a simple fix to just upgrade the Hardware. They also have to rewrite/replace the Legacy code which much of EVE still run on, which is also one of the main limitations on the server performance.


I’d chime in to claim that you’re not a very knowledgeable one, then… Multithreading is hard and you also can’t just replace a CPU with a GPU-based architecture and watch the performance skyrocket. It’s more likely to go down the drain.

No, it won’t. I don’t know where this notion that quantum computers have insane processing capabilities comes from, but it’s wrong. They only have that regarding very specific problems, not across the board. Compared to a non-quantum computer, the quantum computer will on-average always be slower. You also can’t just compile your existing code for it and expect it to magically work, as you’d need to rewrite your algorithms (where possible) with quantum physics in mind.


Never said it would be a drop-in fix… yes it would absolutely require a re-code from the ground up. It’s an entirely different architecture.

That said, it could be that I misunderstand quantum computing, but it is my understanding that when you’ve got x number of the same calculations to do, you can do them in parallel.

One example that comes to mind is a rack of guns firing. It is my current understanding (which again I will say could easily be flawed) that each gun is calculated separately. If each gun is calculated separately, you could in fact just run the same calculation in parallel, which in the case of a ship with 7 guns on it, would result in accomplishing 7 calculations for the cost of 1.

Again, I could be wrong about both quantum computing and the way CCP actually does the above example. It’s based on what I think I know.


I’m sure CCP has never considered making the EVE computation loop multithreaded - not with their own programmers, and not with all the people making the same suggestion. For years.


Yes, you do. :slight_smile: But in fairness most people do, and most of it has to do with hype. It is unlikely that quantum computing will have much effect on the normal data systems we use in life. (Unless you are a physicist or cryptographer.) (This could be proven in the future to be wrong, but it is the current view of the future.)

With enough qbits and a quantum algorithm, in theory, yes.

If the guns are grouped together, they’re already calculated as one unit (I’d laugh very hard if not). But even if they aren’t and you’d do this calculation in parallel it wouldn’t be much of an improvement as the overhead is just elsewhere.

Actually, I have the faint memory of CCP Veritas talking about it at some point. It’s just not as easy as just snipping a finger and you also can’t just run everything in parallel.

I’m trying to explain it in a simple way:

When the output of process A is the input of process B, you can’t just start process B before process A is done.
But if two unrelated processes A and B both provide input for process C, you can compute A and B in parallel.

1 Like

As a programmer I can see 2 major problems with why they currently cannot make it faster.

First is every time a weapon is fired the inventory system has to make a change to the database server. While the processing needed for each individual ship to activate/deactivate modules is relatively small. Consider 5k players on a 3.5Ghz processor, each player gets 700Khz of processing power, 2.8Mhz on a quad core system. This would include moving that players drones and missiles.

But there is an even worse culprit. The collision detection system. consider 2 players. you have one test to determine if there is a collision, with 3 players you have 3 tests, with 4 players you have 6 tests, with 5 players you have 10 tests. each player adds a n-1 number of tests. So with 5000 players you would have 12,497,500 collision tests. On a 8 core 3.5 Ghz processor you would have only 2240 cycles per test.

Could this benefit from a GPU? Possibly, but it would also require a complete rewrite of that part of the server and completely new hardware. Hopefully something they are at least looking into for the next generation servers.

1 Like

EvE Online, not since the days of the first MUD has a game’s player-base been comprised completely of programmers. (At least according to their posts on the forums.)

The problem is the definition of “programmer” has changed. I know someone who claims he’s a really good programmer but the only thing he knows how to do is a visual script thing where you drag a control onto the “program” then connect wires from outputs to inputs… I showed him one of my projects and he ■■■■ himself at how complex it was. :slight_smile: F’ing script kiddies.

I personally have been programming since 1984. Started on Applesoft basic, then 6502 assembly. Migrated to x86 when I finally was exposed to them in collage in 1989. (A fault I will never forgive my high school for).