EVE Information Portal

Greedy minimal-first without locality.

I know The timeline really is that it's going to be released when ready

It is balanced statistically, they just added geographic correlation to contain TiDi to the location which causes it.

Why? As of now they can't do load balancing more than once a day. And if that daily balancing works fairly well, why not apply it to low and high too?

If by iterate you mean them reworking the algorithm I guess the answer is "never if it works", but I think you mean how often the system balancing is done and as I understand it the answer is "every day at DT".

No, cause in this scenario the "empty" nodes in the north would handle a lot more systems each than the "busy" ones where the fighting is happening. I think your misunderstanding is that you think they're doing the balancing purely geographically, but of course that's not the case, if it were they wouldn't need an algorithm, they could've just had a kid draw equally sized circles around systems on the map with a crayon.

Can we get a copy of that map with System names instead of IDs?

At the risk of drunk posting.
I think that's what they're hoping for but have not quite got right yet.

As the above is inarguably true, why not load-balance highsec by locality as outlined in the devblog, and balance null-sec by minimizing intra-node jumps?

(edited again) or, similarly:

a) partition space by repeatedly dividing it in two as in the devblog
b) categorize the resulting partitions as regions of either consistently high or consistently low activity
c) discard the low activity partitions and return all of their systems to a single set
d) stir vigorously, assign to remaining nodes

Awsome dev blog, really enjoyed the extra techical information to chew on.

moar! Moar! MOAR!

I'M BACK!

I just want to clear up some confusion I'm seeing first: this is not meant to be the Holy Grail of lag reduction. This is a static load balancer. It is in no way the end-all solution to our load problems, it's an initial step that's required before anything further can be done. Optimizing underused resources is just wasted work. Well it's not wasted but it makes more sense to do it the other way around.

There is no load reduction going on here. Todays total load pressures with, or without, my code would be exactly the same. But with my code it will be more evenly distributed between nodes so that the probabily of a "wild" TiDi appearing have been reduced. TiDi in unreinforced systems with a massive fleet presence will still happen as it always has. We'll need to reduce the CPU footprint per user if we want to prevent Fleet TiDi (and my money is on that only increasing fleet sizes until TiDi becomes unbearable again).

So with that being said I'm going to try and answer some of the more frequent questions here.


"Adjacent systems" are bad for fleet movement / staging.

They always have been. They've actually been worse because the old system would be so aggressive on grouping systems of the same constellation together that it would, is so many cases that I was given time to work on this, chose to overload the node rather than split up the constellation.

If your Staging system is not reinforced, it's probably going to share its node with other systems. If the fleet is large enough to cause TiDi it will cause TiDi no matter what these other systems are. It's even possible that this staging system had enough load caused on it the day before to be reinforced on its own because its simply too loaded to share its node with any other system. But that will not help you with TiDi if your fleet is large enough to overload that node.

If you control the space around your staging system, you can now command people to stay out of those systems to avoid TiDi-ing your fleets staging system. I'd love to offer you a map of all node allocations so that you could discern wether or not that was needed.. but I'm certain people would metagame TiDi into existance through that.

I'm not sure what more to say. Nobody likes being TiDi'd. I'm not going to try to convince you to like it. But you'll be able to anticipate it now. And in case it's not clear: Nullsec and Empire do not run on the same nodes, and they have not for many years. Fleets in Nullsec do thus not cause TiDi in Empire, or vice versa. They cause TiDi in other Nullsec systems. This means that under the old system a staging system from the north could be allocated to a node already running a staging system from the south. That can no longer happen. That's something, yeah?


This does not help with sudden escalations.

Absolutely not. This is a static load balancer that balances system between nodes at server startup. I'm actually reading a paper from some people at the University of Bonn about predicting destinations based on previous system jumps. It's pretty interesting but my brain now hurts. But if we could hook something like that in we could detect staging systems forming. We'd still not detect sudden escalations. Sudden escalations need dynamic load balancing if we're to handle them gracefully under the current CPU per User fingerprint.


What about reinforced nodes?

Reinforcing nodes means that we, usually, move that system to a single node that is running nothing other than that system. We currently have three nodes on standby for the premapper to use according to reinforcement requests. Any system marked for reinforcement, at startup, is completely excluded from this premapping process. They're effectively marked as "Fleet Fight Systems" rather than "Null Sec Systems" and thus the "Null Sec System" load balancing method will not include them.

Dynamic V Static Load Balancing.

As I mentioned dynamic load balancing would solve a lot of our issues. But there are massive hurdles to that happening. I know that sounds weird to some people that work in an environment where it's easy as pie. But that's not our environment. We simply are not in the state where we can move a system between nodes without offlining everyone first. Would we like to be in that state: Ofcourse! But we're not. So we're stuck with the static approach until that changes.

So instead we run three other spare nodes (that are not the fleet fight nodes mentioned above) that we can allocate systems to if we need to separate them from a system with a sudden escalation fight in it.


Why is Empire split from Null?

Because Empire has a completely different load fingerprint than Nullsec (Crimewatch has been mentioned). Players in Empire also have a fairly different behaviour than players in Nullsec. Wormhole space is also seperated from these two groups of systems for the same reasons.

Sadly I think we have to few WH space nodes allocated now. If Empire runs smoothly today and tomorrow then I'm thinking I'll move one or two empire nodes into the WH space rotation for a better weekend experience.

And now I have to run to a meeting (probably already too late by the time I finish editing this on the forums). Sorry if these answers feel a bit abrupt, I was in a hurry.

Thank you for the delicious technical details, Prism X. These are by far my favorite type of dev blogs.

I've mentioned it elsewhere, but why are these machines not virtualised (or are they?) surely something like vMotion would be able to move high-use systems onto dedicated hardware without the need to pause anything.