What I find most funny about the whole situation is that nowadays one could just plug a low power gfx card into a node, run the math on it and there’d not be any issue performance wise whatsoever. Hell, even an igpu would be doing a faster job than just doing it serially on the cpu. In a max load scenario that’d really help.
If only it were that easy…
Not for this game, no, but for any upcoming one. I have no idea if that is a wide spread thing, but at the company where I am running a virtual server, they offer to hook up a gfx for cheap to use.
Though, honestly, I am really having a hard time wondering how they have implemented the heavy physics part without being able to … oh well … not worth speculating.
Things we take for granted now weren’t even fantasized when CCP made the game over 15 years ago. The decisions made back then are limiting their ability to take advantage of modern techniques. Without a full rework, some things just aren’t possible.
I think all you software types are getting hung up on the word handshaking as it applies to software engineering whereas I’m using it as areference to a class of mathematical problem. I’m not claiming any peer to peer cababilities nor federation, I’m saying the scaling on a per object present basis is very ■■■■■■■ far from linear and instead is more like n^2 at best.
For five people to have them all shake hands with each other is actually a Power Sum expression, that is 1+2+3+4+5 = 15. So, there are fifteen possible combinations to represent all possible ways 5 people in a room can shake hands.
And for ten people the answer is 1+2+3+4+5+…+10 = 55, which you happen to have correct, but is incorrect by the formula you gave in your examples.
So, if you consider there about 25K players on average playing EVE that is 312,512,500 possible combinations. If you consider a time element meaning those would be the number of calculated combinations requiring processing per an interval then you multiply that by the number of intervals. So, if an interval was 1 second then a minute is 60 x the calculated power sum value. That can get to be a big number.
https://www.emathhelp.net/calculators/calculus-2/series-calculator/?f=n&var=&a=1&b=25000
There are no handshakes of the clients with each other, as far as I can tell.
There is however the necessity for the server to make my client aware of the presence of other players on grid. Amongst other things that means a bunch of data for every additional player. Think ships/drones/missiles/etc., think vectors for them and certain data that you receive when locking someone up - at the least.
From the client side that looks to be linear, like one more package of information for each additional entity. But from the server it means one additional package for each client for each one additional player on grid.
So for the server it would basically be X * (X-1), X = number of players on grid, assuming that each players information would only be one package of information and the data for the own ship wouldn’t be send from the server, otherwise it’s simple X^2.
Let me make an abstract example (assuming that own ship data wouldn’t need to be transfered by server):
Then it’s
n = total number of “packages” (of information about other entity) send by server to clients
x = number of players
2x -> 2n (1 each for 2 players)
3x -> 6n (2 each for 3 players), ∆n = 4
4x -> 12n (3 each for 4 players), ∆n = 6
5x -> 20n (4 each for 5 players), ∆n = 8
…
39x -> 1482n (38 each for 39 players)
40x -> 1560n (39 each for 40 players), ∆n = 78
…
999x -> 997002 (998 each for 999 players)
1000x -> 999000 (999 each for 1000 players) ∆n = 1998
1001x -> 1001000 (1000 each for 1001 players), ∆n = 2000
So basically if you have 1000 players on grid, the 1001st player will put an additional load of 2000 “packages” to send on the server, which means this delta of 1 player needs more additional ressources than the totals of a grid with 40 players. And this is assuming that 1 player equals one package of information.
If every player would get a server core and all of them would have to shake hands with each other, Skynet would start launching nukes on african children hospitals. I think so. 
You forgot Unique packages!
Pro Tip: It is SENT not SEND by the way.
Yeah sorry my English sucks, I’ll try to improve it.
I’m all for a rework, willing to even go in on an EVE fundme campaign if they needed capital up front.
1 Like
No problem we all are poor at something!
Talking of unique packages, Take the scenario of jumping into a system and a moon mining operation cracks a moon chunk just as you jump in!
If 5 operations do the same thing at the same time?
More needy causes than eve to be funded on this planet to be honest!
1 Like
Sure, I think the above calculations are only for load on a common grid. I don’t think there is any communication between the server and my client about a moon chunk somewhere else in system.
So taking the common grid into account NPC’s warp in and two war targets start fighting or a gank happens! Chaos theory! there are so many different permutations of what a common grid might be in that given instance!
Theoretically yes, because the grid is defined by the distance of objects to each other. Practically it depends, as most things that happen, happen around clusters of objects you can warp to, like stargates, structures, planets or belts. In theory and sometimes in practise Player A could be on grid with Player B, but not C, while player B is on grid with both Player A and C. (However, I don’t know how the server handles that. I think it actually sends you packages for players who are not but almost on your grid and who just left grid, which could explain that you see players warping off while they are x AU away etc.)
I agree that it is difficult to predict the behaviour of “inherently unpredictable” systems as we see in Eve or any scenario to be honest. As such trying to put a predictable formula on a common grid will always fall short!
Can anyone here tell me how you can parallelize computation for a simulation that happen in real time and must keep synchronization ? I’d be very interested.
Your talks about parallelization are nice, but when things must be computed in order it’s not gonna help much, and when it must be done in real time, I can’t see a graphic card helping.
The only thing I see that can help and might not be implemented yet is a distributed predictive algorithm to run the computations in advance on other nodes. But as you need to consider players input most of your computations will be useless anyway. And you still need the verification to take less time than the original computation. And this is far from a comon technology.
1 Like
This might interest you https://dl.acm.org/citation.cfm?id=831186
1 Like
Ladies and Gentlemen… and Combat Attack Cruisers… The Solution™:
1 Like