Super-lag during large fleet battles, node crashes, etc

I meant “you can’t parallel the events”, my bad.
A “tick” is just the synchronization point, when the server propagates the data modifications to the clients. The ticks are not part of the issue here. The issue is that the events can’t be handled in parallel.

The ticks are the events. Or, actually they are groups of events which are all happening simultaneously in that particular ‘tick’ or instance.

Yes, naturally you can’t parallelize across ticks. That isn’t what is causing the issue. The whole point of having ticks is to have time flow, and reality as we know it couldn’t exist without it. The issue is there is too much stuff going on within each tick that the current design cannot handle. My contention is that they aren’t parellelizing, and my contention is that it is parallelizable, unless and until someone demonstrates or gives good reason why it isn’t.

That’s completely wrong. You can’t prove that something does not exist, unless the definition of this thing (ie its property) makes no sense, eg “a triangle with 4 sides” .

Yet, I used this to explain you that this solution (making graph of the interactions between the items to solve connected graphs each on a different node) is not one : you need to make a modification, to simplify a problem, but actually the modification costs as much as the resolution of the problem. THUS this specific solution is not one.

Not at all. Events are handled by the server ASAP. Ticks are just the transmission by the server of the modifications.
It would be completely stupid to do nothing but store events during 1s, then at the end try to handle all those events at the same time …

SOME added events appear just before the tick eg entering warp, starting to align, I guess end of timed effects - so ticks add already some computation to the server just for processing events, plus propagating the modification of the battlefield.

You are claiming that a parallel solution doesn’t exist. Then you are claiming you can’t prove this and it makes no sense to ask you to prove it. So at this point you are speaking pure nonsense, and I’ll allow you time to go off and reflect on it.

Then we are equivocating. Look, it doesn’t matter what you want to call it. There is undoubtedly some ‘time slice’ or simultaneity which is being simulated in the server - time0, time1, time2, etc. I was calling this a ‘tick,’ but we can call it whatever you want. And those events occurring within this ‘time slice’ are what need to be parallelized, and I was saying you wouldn’t parallelize across time slices.

I’m telling why ONE solution that seems obvious will actually not work. That is, to show you that what seems obvious in informatics is most of the time false (well like any science actually).

I am claiming that you don’t know what “parallel solution” means, and that comparing eve to other existing solutions makes no sense, thus affirming that the design could be changed to be paralleled is plainly wrong.

You can do anything in informatics. You just need an infinite amount of time and energy for most.

Prove it. Seriously, prove it.
It’s totally possible that there is no such a thing.

Obviously you don’t know what you are talking about, since my entire livelihood for years completely depends on knowing what a ‘parallel solution’ means. Please dispense with ad hominem attacks and speaking about things which you haven’t the slightest clue.

You’ve just degenerated into babbling nonsense at this point. I see no further reason to continue with you, unless and until you start speaking coherently.

With this statement, all knowledgeable people here can conclude that you don’t have any earthly idea what you are talking about. So I bid you good day. You are a waste of time.

Parallelizable in principle isn’t always feasible in practice.

If EvE was as (crowd) funded and as new as Star Citizen then the situation might be different but then it would still be “in development” :stuck_out_tongue:

CCP is a relatively small games company considering the complexity and scope of EvE. They’ve also had to restructure recently so are no longer growing/expanding which means limited resources available to address problems, so prioritisation.

Additionally, as the game is now 15 years old we’re talking about legacy code which would be difficult to parallelise. They’d probably need to “port” to a new cluster but aren’t in a position to do that currently for the above reasons.

Lastly, there is the EvE player culture (which is hardly surprising in game about empire building and destruction) of wanting “epic” fleet fights yet expecting them to be lag fests. I suppose this is to some extent the “stupidity of the crowd” effect. Players know what might happen if they keep sending pilots to the same system but they do it anyway, almost as if they’re deliberately pushing the cluster to see how far they can go before they break it. However, it doesn’t help that the game mechanics have always rewarded “bringing more” so any FC who calls for backup is arguably just being responsible!

I left nullsec politics behind years ago but I’ve been in my fair share of fleet fights pre-2012, only a few of which were truly epic, but when things did work as intended it was incredibly awesome. There is no game which can match EvE in this respect. I think it’s the promise of this and the occasional success which entices players to keep coming back for more.

1 Like

And yet you are affirming nonsense as “the important thing is if it can be done”, by saying I should prove it can’t be done.
No, the important thing is “how much will it cost to be done”. With infinite money and time we can have infinite computing power on one node, thus absorbing any load excess.

So I will teach you something : nobody has infinite time nor money.

really ?

I asked you to prove that the server is splitting the time in slices that can be parralleled. This was your affirmation. So it’s nice when you realize you are the one babbling nonsense.

No, the question THERE wasn’t whether it was splitting time in slices that could be parallelized (that was another question). It was whether it was splitting the time in slices AT ALL. I said it was, and we were equivocating on the term ‘tick.’ You said it wasn’t, and ‘prove it.’

Cut and paste:

You were the one talking about parrallel in the time slices.

Anyhow, your proof is ?

What exactly needs to be proved? We agreed you don’t parallelize across time slices, so the only alternative is to parallelize the slice.

What you were affirming in my quote, dumbass.

Prove that the server actually simulates some time slice.
What I was telling you is that this is not needed, because the events can be as well handled FIFO and the “ticks” are just an “interrupt” (not processor interrupt, just a flag to pause) in the events handling loop that copies the current state to clients.

something like

while started 
  if tick
    pre_tick()
    propagate()
    tick=false
    schedule_tick()
  else
    if(events.peek() as event)
      handle(event)
    else
      yield()

does not need to model the time slices. It just handles event as they come in, and propagate the state whenever the tick is scheduled.

To put it simply : prove that the engine is aware of some “time slice”.The ticks are not a time slice, it’s just a clock (that is slowed for tidi on the schedule() call)

I already said that if you think this needs to be proved, you have already demonstrated your ignorance of how this would ever work to anyone reading this who is knowledgeable. So there is no further need to waste time on you.

And I proved that you are wrong.

Then you don’t show any element of proof.

Which means, you are just affirming things out of your ass because you can’t accept to be shown wrong.
Guess what ? I don’t care if you’re wrong, I’d prefer if you showed me I was. But with this childish answers of yours, you make a show of yourself as unable to understand half what I said - so totally unable to answer it.

Heh. Let me say you that even if they do such things in parallel nobody will ever notice. Exception exists for sure but to prove anything you would need to spend huge amount of effort. The most difficult will be to negate network latency.

So in general the whole system can be heavily simplified and still be enough.

Q: can the core systems of EVE Online be improved by parallelization and multithreading?

A: Yes and no. Techniclaly, it is feasible. But improving those systems would require a massive rewrite of nearly every piece of code in EVE Online, since everything in the game interacts to that core. It would be literally making EVE 2.0. That’s something CCP can’t afford to do without completely neglecting EVE 1.0 for three to four years, since the networks experts are exactly the same people and can’t work on both EVEs at once.

EVE Online has done great things, but the core design dates back to 1999.

BTW, if you want to know how EVE works at server level, this search should deliver most of the relevant devblogs:

Searched for “Sol” since this is the name of the service that calculates interactions, so any devblog on how does Tranquility work should mention it.

2 Likes