EVE Information Portal

Read the Devblog and must say, looks like you guys out in a lot of work to make TiDi less frustrating, thank you a lot for that :)

Is it possible for you to make an addition to the Devblog explaining how the load is distributed in w-space by chance? We now know and understand in detail what is happening in known space, but it could be very cool to know how you solve w-space, even though it might be "dumb but efficient" :)

(Also, please tell me if SSC is producing the TiDi so I can have a reason to evict them )

How is work progressing with the dynamic node reinforcement where you move sols between nodes while players are busy in those sols?

is there any possibility of only loading systems when 'stuff' happens in them? Thus when nothing is due to happen in a system for half an hour you could "unload" the system until that POS reaction has to be serviced, or someone decides to jump into the system. Heck, if you move POS reactions to a separate service (and thus unlink it from the sol simulator) you don't even need to load the sol at all. When I approach the gate between Lanngisi and Tvink, the gate could have some kind of notice attached indicating that Tvink isn't loaded yet, is currently being loaded, or is ready to jump into. As a blockade runner pilot, I might want to stay cloaked, so there might be a mechanism to ask traffic control to insert me in the queue, at which point Tvink would be loaded, the gate would display the appropriate notification, and off we go. What if gates could be de-illuminated to express the state of being "off" due to the remote system not being loaded?

And as a result, load balancing would only be a case of, "someone wants to load this sol, which server has the lowest load? put this sol on that server!" And load balancing would thus be automatic, as would reinforcement (when one server gets heavily loaded, it won't inherit new sols, and existing ones will end up pruned). You could even preemptively "reinforce" nodes by adding a weighting to the "which server is least loaded" algorithm where an SBU adds 1000 virtual players worth of load to the system for balancing purposes, along with the historical load that your pre-balancer is using.

As a bonus, "downtime" could happen opportunistically, except for continuously populated sols for which the downtime counter would be applied as a timer for that sol, similar to the incursion bar: if I'm missioning in Lanngisi which is supposed to get downtime but has had 100 missioners in it for the last 36 hours, I'd see a non-modal warning that this node is going to experience downtime in 20 minutes. Thus I can choose to do something else (e.g.: fly to Hek to buy some stuff off the market). Then when Hek is due to shut down, I fly back to Lanngisi to continue my missioning. Downtime gets done, player gets a downtime-free playing experience. Of course there is the issue of patching the client.

If a node needs servicing, you could remove it from the opportunistic loading queue, shuffle the current sols to different nodes based on load, then you're free to shut the node down to replace it.

And then you could choose to not apply downtime to sols which don't need it because they don't have infrastructure that requires downtime.

Of course you've all been through this already in your various dev chats internally, and removing downtime is probably going to be easier than moving to a "just-in-time" sol loader with dynamic sol rehoming, and I should just shut up.

I'd just like you to consider that AU-TZ players would love downtime operating per-system on a round-robin basis almost as much as removing downtime altogether.

Would it be possible to do something like this?:

- freeze game (TIDI 100%) in old node
- spawn new node with 100% TiDi
- Show players info about load balancing or something to let them know they are changing servers
- move people to new node with all player/ship states untouched and make it take as long as it is needed
- all new player system entrences during the node movement is put too new node
- after all players are moved OR certain timer have passed despawn old node and set TiDi to appropriate level on new node

We're still waiting for that dev blog mate

You're equating two completely different scenerios. 2000 people in Jita doing trading on the market does not equal 2000 people on space, activating 10+ modules, 5 drones, the server keeping up with what ship is where, it's speed, it's speed relative to other ships, effects being applied to various ships via points, RR, ecm, and doing damage calculation, all while handling jumping in and out of the star system, POS timers, station timers, all while handling other systems on the same node.

It's no comparison.

I'm sure CCP is continuing to look into lag and bottlenecks. Drones is probably a good thing to look into. Possibly fleet jumps and maneuvers as well (so that it doesn't hhve to loop with each ship, but treat all ships as a whole in a fleet object). But they've said a while ago in a devblog that they're getting to the point where there's not a whole lot of optimizations that are left to be done.

TiDi was never a fix, nor intended to be a fix. It was intended to mask the lag and give the server time to respond to the many different commands that were incoming. it was never a fix.

Nor was a fix ever intended to be soon. I would assume dynamically allocating resources would be as close of a fix as anything. Who knows where that is, or if it's close. That is a massive undertaking and could be another few years maybe.

not empty quoting

Yes, that's the naive first solution I was thinking of, but it's a colour problem as 'checkboarding' the graph isn't possible with two colours- you will end up having white adjacent to white nodes (take three systems all connected to each other for the simplest example- White, White, Black). The whole idea of colouring is to minimise the numbers of colours needed, so you're coming up with the minimum number of involved nodes to ensure every edge is a change in node (for most cases, you will not likely need more than 3 colours/nodes).

If you colour the universe map then load balance each colour individually, you should end up with a similar load distribution but with every jump an inter-node jump. The best aspect of this is the colouring only has to be done once.

so not sure if anyone has asked this yet but...
If you are load balancing based on the "nodes" or CPU cores could you not have the script run dynamically? like below:

1. Systems not used i.e. no players logged in have no node assigned (well they have a theoretical node assigned but not loaded upon that node)
2. As players log in to systems where there is an unusual level of "logging in" (jumping into the system or logging into the game) you move non active systems of that node to a dedicated "reinforced" node. this could be measured using the number of active players (im sure there is a database query that could be run every 15 minutes)
3. As players jump from there staging system to another system nearby (probably where there going to be attacked/ attacking) they would move of a non reinforced node and onto a reinforced node....

this makes a few assumptions which i can not state from a technical standpoint is always true but may aid in handling load.

1. that the systems near the staging system are empty (ok so not usually but you never know)
2. that the reinforced nodes are just kinda sitting there as unused hardware and you are not running a virtual machine cluster that hands off load across multiple virtual servers (i assume this as load balancing is needed at a game level not a "VM" level)
3. that the solar-system level start-up could be delayed using a command along the lines of " wait till client call "login" at solar-system "id" parse system start-up to "node as defined under normal circumstances"" (yes that's sudo code not actual code and sorry for the number of quotes)
4. that if the "node as defined under normal circumstances" for start-up of a system is at TIDI activation capacity shift "node as defined under normal circumstances" to reinforced node is a viable option.

And I'm sure if this was a simple exercise it would be done but have to ask. Any dev care to comment as to why the above is not a deploy-able solution? or why there is not a VM layer to the cluster(does it add so much overhead that load-balancing becomes worse??) ?

So...where does w-space fit in, and how many nodes does it have, and how is load assigned to w-space? it is interesting to me, not so much because I've experienced TiDi in a wormhole, but because it is a bit pot luck sometimes when you jump 30+ people through a wormhole whether you will load grid in 5s or 10s.

Given wormholes are very dynamic connections, especially the S199, A641 and other k-k connections, you can essentially bridge two nodes together which are not usually connected. Does this even matter to the server balancing, as now two disparate systems are directly connected to one another and this ought to influence the algorithm for nearest-neighbour weighting.

Just curious!

Login tidi and undock tidi in a staging system is the devil. B-D never forget