EVE General Discussion

We came across low sec node issues a few years back. Seems low sec is low, on the order of all things server side. Remember having bad lag with around 70 in local.

Not worth doing for the same reason that having one grid per node is not worth doing - namely that since 99.9% of the action is one that one grid, the resources going to any other grids are so tiny that they would not make a difference.

Read it, didn't contain anything new except for a few choice quotes .. run of the mill clusterfuck .. been there done that, woke up in station

What struck me was that the vast majority of supers, were never in any real danger as they essentially all (heinously low bodycount!) made it out when the call came to skedaddle .. the fact that a random fight over a random moon on a random day even has supers on field is evidence that there are far too many of the blasted things floating around and that they need to die in far greater numbers.

So let me repeat myself (because repetition creates truth): Supers should lose their immunity when operating in Empire space and have it replaced with 5-7 points of warp stabilization.

Other than that, good write-up, not to biased which would have made it a chore to chew through.

Hell yes, great improvements on that front. The first 6-12 months of FW had people losing connections and nodes crashing when random roams butted heads .. excruciating that was.

I refuse to accept the 'no solution' excuse. Smart people would have solved this problem years ago. Not-so-smart people would have solved this problem by now (10 years after launch.) I'll let you figure out what we have left.

Critical goal: Make activating modules, swapping modules and basic navigation commands in big fleet fights work for everyone every time (provided they're not spamming) in a reasonably timely manner.

Willing to sacrifice (once TiDi reaches max, or perhaps as it approaches max): Graphical effects, local, all chat, ungrouped guns, basically everything but the overview and even that could be put on a 30-second refresh. Any player activity (spamming) designed to overtax the server could be deemed an exploit or could result in said's players commands being completely ignored or in said player being forcibly disco'ed. Or maybe you could have an x actions per minute limit.

tl;dr It is vastly more important that big fleet fights on unreinforced nodes be playable than that they be pretty.

Guess what. They are playable.

I had no trouble activating modules in a timely manner considering the amount of time everything was taking (i.e. considering that TiDi was over 90%, things took 10 times as long for everyone, so 10+ seconds to activate a module is timely).

As to your suggestions:
Graphics are dealt with on your local client (did you really think EVE's graphics only take up the 6kb/s of bandwidth EVE requires?).
Local and chat are (from what I understand) now on a different server than space.
And then you suggest discarding player actions to improve response to player actions? Wat

Last I checked, currently moving your char from one system to another involves a lot of processing to detatch you from the current node and reattach you to the new node (if applicable). Cutting that down to something which is working on a per-grid basis is only going to cause this processing to happen more often, i.e. every time you stop warping.

And, this still doesn't stop us from hitting a hard processing power wall when 3000 fat nerds decide to try to fight over a few supers or an ihub or whateverthefuck.

If you could essentially pause a fight using 100% tidi would it not then be possible to have a few separate nodes specifically designed for bigfites(tm) . I know this would be quite a change to architecture. For example, Fight reaches a critical size, 100% tidi becomes active, data is transferred to a new special node for that grid only. New players joining the fight would experience a delay joining that grid as it would become a session change, however considering the lag in such big fights anyway this would probably be only a minor hindrance.

The result would be a little more clunky than the current system but you'd be able to run 1 fight on a truly dedicated node that deals with nothing else. I get it would represent a huge change and quite a lot of work to how the server handles things, however it seems that a dynamic system is the only possible long term solution. To try and give enough power to every system would be a massive waste of resources 99% of the time, and not possible with CCP's budget.


I think the only thing Asakai proved was that the reinforced node form is a joke, when a simple misclick from one pilot causes the biggest fight in the game it is clearly not a solution.

There's not really that much which should suggest this should be impossible. CCP would only have to implement the possibility to transfer the data and get their proxy servers to redirect the players' data from one physical node to another.


Having a dynamic system which can react to load is, indeed, the "only possible long term solution". The main problem, however, is that the current way the eve cluster is designed, i.e. one solar system per node, means that there's a finite limit to how many people can be doing things in one solar system.

If CCP could reliably transform the way the servercluster was architectured to f.ex do the processing of player actions on a per player level and leave the solar system to just keep track of which players were where, then the architecture itself would scale much, much better.

If CCP did this, they could also do fancy things like make some sort of usage statistics to see which players are most commonly sitting in Jita doing absolutely nothing (and as such can easily be lumped into one node with other players routinely doing absolutely squat), while the players who f.ex routinely run around in large fleets and routinely launching fighterbombers etc could be evenly spread out across the entire server farm. There'd still be limits, but designing the architecture in this fashion would mean that the processing required would be spread across a lot of servers, and as such these limits would be much harder to reach, and much easier for CCP to "throw hardware at".

The downside to this is that there would be a lot of potential syncronization issues, timing issues because one guy is on a node which for some reason is more heavily loaded than others, etc etc etc. There are lots of very good and valid reasons why the current architecture is still a mostly monolithic 1 second tick design, and while it is easy to say "well they should just do x" (like move to a per-player processing architecture), actually executing that, reliably and robustly, is much, much harder.


Not only would it be a massive waste of resources 99% of the time, we'd still find the limit. How many do you think we'd shove into a single system if we could? 2k? 5? 10? more?

Of course it would be more, and no matter what hardware CCP throws at this, given the current architectural design, we'll always find the limit.


No, what Asakai proved was that while CCP has made huge strides in making large fleet fights viable, there's still room for improvement. 5 years ago, a "huge fleet fight on a single node in 0.0" was 100v100, and bluescreens were rampant even then. Now we had well over 2700 in a lowsec system. In case you don't see the significance of that, keep in mind there are a ton of rules which are active in lowsec (and as such sucks up precious processing power) which aren't a factor in nullsec fights.

And while reinforcing that particular system on its own superpowered node would've increased the playability, all we'd end up doing is stuffing more bodies in there, until we reach exactly the same problem of "oh god it's so slow".

Putting a solar system on a reinforcement node is a bandaid, tidi is a bandaid, but they're bandaids which, despite all the whines, actually does work in extending the limits of the current server cluster architecture.

Moore's law is only still working if you put threaded code ont he amchine. The IPC of any CPU is currently slowboating to higher level. As long as EvE is not completely re-written to handle more core efficiently, Moore's law cannot be applied to it. Rewriting all of it will cost thousands of man-hours. Will it be done? Maybe. In the meantime, TiDi is the solution to prevent the node crom crashing.

CPU design have hit a "wall" on clockspeed so more cycle/time is hard to get. Making these cycle more efficient by procession more instruction (IPC) is also hard and not really advancing that much ATM.

It seems TiDi is working as intended. The fight, entirely unexpected, happened, and was finished. There was an outcome other than 'the server crashed and dropped all connections for hours'.