Practical options for EVE performance issues

Communications Center General Discussion
1

As a software engineer and system designer, I find it interesting to think of a practical way to address the current EVE design and performance crisis. Here are a few ideas that come to mind, which can work both as short term and long term solutions.

A) Shift large scale warfare into instanced encounters with hardware bound player limits.

EVE already has notions of grid, deadspace and beacons. Just add support for instanced deadspace encounters that can be run on a designated server, cluster, or server node. Extend them with polices, so that encounters could be arranged and agreed upon by all parties involved. E.g., if the encounter has 2000 player limit and is created for two battling alliances, each side can invite other parties it wishes to take a part in the event and if necessary redistribute their side of the player limit among them. Once some players drop out of the encounter, they can rejoin it or others can join in instead as long as the encounter is active and they match the set policy.

This simple option can be used as a foundation for Faction and Sovereignty Warfare. Just make it based around certain events or objectives that will be run in instanced, hop in / hop out, environments that will run with a measurable and predictable server performance within the set player and bracket limits.

It is a scalable option that can make the warfare manageable within the existing hardware infrastructure and extensible with new server clusters that can be rented or joined on demand.

The size of such deadspace encounters can vary as necessary, from the size of the grid to a certain AU limit, or maybe even spread across multiple pockets, so that it allows for various gameplay options within it.

B) Allow instanced encounters appear on maps and in system space via beacons.

Based on the type and set policies of the encounters, players would then be able to discover them and possibly join at will if the encounter allows it.

C) Introduce an escalation mechanic that can turn any local encounter into an instanced deadspace encounter once it reaches a certain player threshold.

Once any local engagement in a solar system escalates to a point where it becomes a burden for the server node, transform it into an instanced deadspace encounter. The policy of such escalations could be initially free-for-all, but there could be options for players to negotiate the policies of ongoing large scale encounters, for example through vote or diplomacy interfaces. The exact details of such transitions can be thought of further as necessary.

The deadspace in such instances can occupy the same location in the system where it originated, just appear in a sort of a parallel bubble that exists only as long as the encounter lasts. As with other such encounters, it can become visible via a beacon to other players in the system who may decide they want to join it if they wish so.

1 Like
2

So I can’t bring a random fleet, say a spectre lead fleet to join the fight trying to kill both sides? Wouldn’t that defeat the whole purpose of having a single shard universe?

I could not make the last big fight but prior ones I have joined. Not as a participant but to simply drop a few bombs for fun. How would I factor in?

4 Likes
3

One of the cornerstones upon which Eve is built is that you can ruin someones day, anytime, anywhere.

Instances of every kind have been discussed to death over the last 14 years, they break that cornerstone, thus they have no place in Eve.

3 Likes
4

I see no problem with mixing both approaches at the same time. It doesn’t have to be black or white. You may look at it as an extension of existing gameplay that would make large scale warfare viable for those who want to take a part in it. Rather than say, taking a day off from work, losing a whole day’s income for that reason, and in the end being not even able to login to the game, because the game doesn’t support such events at the moment.

So, no, it can have a massive place in EVE without breaking any foundations, but extending the existing ones.

1 Like
5

Any thought of having an instanced battle is counter to what Eve Online stands for which is everyone interacting in in a single shard environment with no instancing. And besides, as the recent battle of the 9-4 Keepstar has revealed, everyone wants to dog pile. Battles are only going to get bigger and bigger which means more players want in on the action. 6,000 players in local is a huge lode on the server nodes already.

So instead of limiting the number of players engaged in battle, CCP is figuring out how to mitigate or keep under control the lagfest that occurs when you have that many players duking it out in null-sec. TiDi was the initial solution to the problem. But of course we know TiDi has its flaws and limits. But fight are better today than how it was before TiDi was first implemented.

Thus CCP is eventually going to be forced to have to rethink their server architecture that allows for bigger fights with more players in local and still have less lag than before. Instanced battles are not an option in the case of Eve Online which is mainly known for never having instanced battles.

2 Likes
6

Actually it does.

If you’re in an instance and the hard limit is reached, I can’t come along, uninvited, with some friends to mess with you; being able to do that is the very soul of Eve.

1 Like
7

I find it fascinating to be able to fly in and interfere with a fight at any time at my leisure.

1 Like
8

lol I’m far more likely to sell you the stuff to do it with than I am to do it myself.

However, fine people like yourself killing all of the things, keeps us industrial and trading types in business.

9

First of all, it’s not a “current design and performance crisis”. The server hardware they have allows 1000 vs. 1000 battles, where most other MMO games lag out at 40 vs. 40. It is something that CCP is very proud of, and they are constantly pushing the limits of what current server hardware can do. It’s not a crisis.

Second,

A. You’re assuming NO processor overhead from all of the stuff you’ve suggested, but the reality is that the same server processors that are busy calculating damage for 800+ players will now have to also execute all of your per-player options for inviting other parties, distributing the attendance tickets, enforcing the attendance policy, hopping in, hopping out, letting others join, etc. Your stuff is going to add MORE LAG to the whole thing, and not for the purpose of allowing more players, but to limit the players and to enforce “the options.” It’s not going to be well-received; if they currently can do a battle of 800 vs. 800 or whatever, and with your options they can only do 500 vs. 500, so that the server can have spare processor cycles for all these extra rules.

B. Sure. Neutrals crashing a party usually goes one of two ways - either they’re obliterated as they enter, because the people who are already on-grid have the grid already loaded and are already organized into ambush groups, OR, it’s a large alliance bringing a whole armada of super-carriers and titans to what would otherwise have been a small skirmish between two small entities.

C. There’s a rather large issue with “session changes” - transferring a player from one environment to another. Session changes require a large amount of processor time, for no effect other than moving the player / ship somewhere. A local encounter turning into a “deadspace” encounter would pretty much freeze everyone with a “loading screen”, and then when they finally regain control of their ships, they see… nothing different!!! It would suck.

3 Likes
10

Instances are never going to be in Eve. Plus all of your ideas either break the Eve Sandbox (literally the whole thing this game has going for it) or are incredibly easy to abuse.

Breaking systems to multiple nodes, however, same idea but different concept. Lots of different “instances” with no way to prevent players from entering any of them:

1 Like
11

Eve operates on the concept of a 1 second server “tick” which gets extended if the CPU needs more time to get the work done. There is no reason why the workload can’t be split up into multiple threads that use all the resources of the CPU. Current generation E7 Xeons have up to 24 cores - spread the work evenly across those cores and there would be no TIDI.

Rewriting that code would be a lot of work and the circumstances when it is needed are rare - should it be a priority?

12

Dont go to the big fights.

Performance fixed.

Simples.

1 Like
14

There are already “instances” in EVE, namely the grid, where encounters can actually take place. And warp times are usually long enough that a concurrent thread could load in the data for the encounter even if it ran on a server located on another side of the real world.

I believe it could be possible to make grid encounters as actual instances that can be offloaded to a different server, given the right coding, and at the same time make them work in game just as they do now, so that technically unaware players wouldn’t even see the difference in the gameplay.

As for the encounter escalations and server transfer, yes, it may incur some extra time, but EVE is bloated by time consuming animations and mechanics, like the said warp times, so it won’t be much different from the rest of game feel anyway, imo.

As for the encounter polices, they could be in place only for the large scale encounters that require player restrictions due to hardware limits. It’s not about - you can’t join in because it’s an instance. It is about - you can’t join in because you are too late and server can’t handle your addition unless someone else drops out.

As for the flexibility that polices on instances can provide, well, that could be used in faction and alliance warfare, where there are usually pre-designated conflict points with certain parties involved. I’m not saying it has to be, just that it could be. Such option will be technically there, if anyone will want it to be put in place.

15

So if it is transparent, how do you know they don’t do this already.

Also they stated in multiple past threads that they actually decouple many things into seperate microservices if possible at all to spread the load. So if a grid is something that could be instanced in such a fassion they would have probably done that already.

And even if that would be possible, that does not solve the issue where you have 6000 players on the same grid like in the actual event we are talking about.

EDIT:
Oh wait, you talked about actual instances.

How about NO!?

16

My point was that you can technically make actual instances for the grid encounters and then glue them together on the solar system map and make it so that hardly anyone will notice the difference between the gameplay as it is now and then. The only difference will be in the server side infrastructure and code.

EDIT: The way EVE works now, there is only one cpu core on one server that processes a certain part of the EVE’s galaxy map, with everything that happens on it, and that kind of design, extended by legacy code and what not, is the major bottle neck for the EVE’s performance.

17

And my point was, if you can’t notice it, how do you know they don’t already do it this way?

18

I believe CCP Falcon explained how EVE works right now in the yesterday’s IN stream of 9-4 battle. See my edit above.

19

No it actually isn’t. As already mentioned they decoupled a lot of stuff into different microsevices already to spread the load. They don’t have only one CPU. But stuff like this is not free and easy. It adds a lot of complexity and latency as well.

20

There is no reason to believe the bottleneck is on the CPU. It can as well be network related, like “network cards can’t accept and buffer all the connexions that enter”, or, more likely, linked to communication errors with elements of the servers. In my case I could not dock to the keepstar, and it looks to me like the server did not store my state (“docked in keepstar”) fast enough, thus could not load back this state. I could not activate a module prior to docking, when I docked (tried to)nothing more happened (I received messages that server had not sent reponse for 40min - several times), I had log exit the game . when I logged back in, that is almost 1h30 later, I was docked in the keepstar.
I was in a scorpion and was able to jam maybe 30 fighters in the whole 6H I was on the field. +2H desync’d and logging back.

I think it’s a very more complex situation.

21

If you watched yesterday’s ImperiumNews stream of 9-4 battle, CCP Falcon was occasionally providing real time updates on the server status as the battle progressed. EVE has powerful servers, with a lot of CPU cores. Their load is divided into “nodes”, each covering certain regions of the galaxy map. But since the server code at the moment doesn’t support multi-threading or decentralization - i.e. cloud or distributed server infrastructure - each such “node” is physically bound to a SINGLE cpu core on the server. All CCP can do now is reinforce the “node” by designating more server resources to it, prioritizing the input, giving more RAM and so on. As it stood yesterday, the reinforced node that hosts 9-4 system was using one cpu core with constant 100% load for the most part of the battle and at some point went to allocate up to 74 GB of RAM on the server.

1 Like