EVE General Discussion

it's just a matter of where you draw the magical time difference. As far as EVE the universe is concerned some part of it needs to run slower so the entire galaxy doesn't collapse. That can be at the fleet planetary system level, node level (cluster of PS's), or the entire universe (superset). The line should have be drawn at PS's level. CCP implemented it at node level because they can't handle the incoming fleets into the target battle system instead of dynamically adding PS's to the dilation zone as needed (they went with simpler coding). That's what's screwing non-fleet participants over.

Gee, I was able to lock people and the system was down to 10%. Stop whining. Everyone but you thinks time dilation is an excellent solution to reducing the EFFECTS of lag (since there's no way to remove lag completely, stop telling them to "fix the game" when players keep finding new and creative ways to break it)

The entire cluster is not threaten if a solar system thread on a node gets overloaded..
It just means that at some point the node will crash and pull every solar system thread with it that is running on that very same node (and they will get the lag before that event too ).

CCP implemented the software so, that the lowest level is the thread of a solar system.. that is one thread, one physics simulation.
As CCP doesn't have one node per solar system thread (too expensive), most of them will share the nodes all the time, except for notorious overloaded systems like Jita. There the physics simulation is running on one node all the time.

Now Zleon, with that knowledge and given parameters to work with - how is CCP supposed to just TiDi a single thread on a node which is overloaded?

PS: no, as I said earlier.. they can't pull threads from the node to mildly reinforce it yet, as the pleyers would be disconnected.

'Cause the problem is the one thread (or probably at most 3 threads) causing the overload, not the entire node. So dilate the one thread and there you go... there is no reason to hit an entire node with TiDi.

This issue is closely related to design simulations done in the engineering community - time scaling and microtime problems have been worked on for years in EDA. Maybe CCP needs to consult with them.

Abusable. You could just create a fake alliance and set standings in such a way that you can fill the system up with your fake "allies" who sit there and do nothing while your reds run rampant with nobody to oppose them thanks to traffic control.

Trust me, there is no better solution than Time Dilation short of starting over from scratch - which would kill CCP, btw, as they would have to take down the servers for several years while the rewrite the game from the ground up to support multithreading.

EDIT: Not to mention that multithreading has limited usefulness unless your algorithms are "embarrasingly parallel", which EVE is not.

It excuses them just fine.

The odd crash when something like this rolls out on the live server is pretty much to be expected. The “outbreaks of lag” were most likely there all along (so no outbreak) — it's just that now, we have a nice little meter to show that it's there.

Sadly I know what im talking about. And Indahmawar Fazmarai I mean server , not client.

-Every SOL is running IN ONE THREAD ON ONE CORE (usually more SOLs on one core, unless its reinforced system).

-You cant partition load on few cores, you cant even divide SOL into grids so if there are 10 battles in one SOL they ALL run in ONE THREAD ON ONE CORE.
-There is no mechanism for live migration, CCP cant just freeze SOL and migrate it to another core :/ It should be easy now that they figured out time dilation - freezing is just slowing time to infinity :)




not server, one THREAD bound to ONE cpu core :((( Instead of letting server compute more of the battle they are throttling the battle to "fit" on one CPU.




Not true, There are FPS games (for example Mount And Blade Warband) currently that run smooth with >200 players bashing each other with melee/thrown/shooting weapons in the face. With server tick time 0.1sec (means steps per second stuff is updated server side). Eve has server tick time 1sec so by extrapolating those FPS games could handle 2000 FPS players at 1sec tick, all unning around, changing directions, waving melee weapons, hitting each other, shooting at each other, all on one map.
EVE doesnt really have directions, when it comes to calculating tracking it doesnt matter where your ship is pointing. EVE is EASY compared to FPS engines, all you need to worry is position and status of incoming/outgoing damage.




+There was an example of optimisation on dev blog ~year ago that showcased some piece of code that was O(n2) for every missile shot (or just object in space, dont rememer). There are still monsters like that in the code.
Stupid client side example - EVERY TIME session changes (jump/undock) your ASSET window is drawn at least 3 times.
-First it is initialized from some dataset in the memory, drawn with default alphabetical order of items.
- then it is REINITIALIZED and sorted according to your selection.
- then it is AGAIN reinitialized and drawn with remembered positions and station item trees open/closed.

Whole GUI was refactored, yet it is still inefficient and is redrawing parts of the screen that dont change at all, it seems nothing is being kept in buffers, compositioning just doesnt exist. You open Market screen and it will call GPU EVERY frame drawing every single font one by one instead of generating that window ONCE into a bitmap buffer and just using it untill something changes. Even Android finally uses proper compositioning and only redraws part of the screen that change - GUI in your phone is smarter than GUI in this game :)




They are working on those things, just toooo slow. There was a time Market was running on same cpu core as the rest of the system, afaik now there are dedicated market nodes. Next step would be enabling separate grids to run on different cores and live migration between CPU cores, preferably over the network so they could migrate them between servers and not only between cpus on same machine.
Of course best case scenario would be rewritting "battle code" into something MULTITHREADED so one big battle can use more than one CPU on a Node (nodes are multi CPU, CPUs have HT) dividing load. Calculating distances, misses, damages, movements, it could all be multithreaded and done at the same time instead of doing it in sequence.

As for the 'too slow part'.. by know everybody should know that the last 3-4 years had been not very optimal for CCP in regards to resource usage. Just read the last bit of the last minutes.. doesn't sound like this company was running well organised.
Let's hope it's becoming better now and Core does some good stuff next..


I wish there was a new Dev blog about this.. just some small talk about concept stuff to wet our appetite, ya know?
I mean, they must have some ideas already about multi-threading vs physics simulations.

please fix lag and combat altogether.

Introduce new Area of Effect weapons, which instantly finishes blobs. If someone blobs and stands still, weapons of mass destruction can hit the centre of the blob and wipe them out.

Pilots will have to think smaller, maneuverable groups.

Didn't everybody just come to the fight with ships that can take the WoMDs -the last time this was the 'motd'?

Also, afaik the current objectives don't support/prefer small, mobile groups.. and I don't see CCP addressing this yet.
Things that play a role for this:
- ease of travel cyno/jumpbridges vs gates
- hitpoints of structures
- local chat as intel tool
- income sources in low/null too risky for soloers (so they don't try or better they already got wiped out)
- hotdrops