EVE General Discussion

The honest to god truth is we've only been seeing minute gains in processing power over the last several years. This differs from the last generation where it wasn't unusual to buy a brand new server, plop it in your datacenter then have it be completely outclassed by the next generations models.

Maybe we'll get lucky in the next few years and see another major paradigm shift in how we build CPU's, but right now we're still trying to cram more and more microtransisters into a smaller space, and when that doesn't work we increase cores/cpu count.

Right now the biggest gains in overall computing speed to be had are found not at the compute level, but at the storage/iops level, which isn't as sexy as ghz so no one ever talks about it.

Anyone from CCP care to weigh in on how you structure your storage? :v:

If, as they've said, they wan't EVE to keep evolving for the next 20 years, they're not going to have much choice.

The base code will have to be rewritten to multi-thread. It's gonna happen or EVE will die, sooner or later. I kinda wish they'd bite the bullet and just get started on it.

CCP already said> NO .. it will NOT happen because DOUBLED server CPU usage.

People said the same about x86 computers.. yet.. they half survive even nowadays inside your new AMD64 architecture cores.

As long as somethign is lucrative.. it does not die.

This is why not:

http://oldforums.eveonline.com/?a=topic&threadID=876274

Pasted here:

The key point is a chaos-theory equation system of potential spheres of influence for every actor in a space. Essentially the algorithm goes something like this:

1) Begin server frame.
2) For each ship, calculate a sphere of possible client interaction based on the ship's dimensions, weapons systems, visual range, etc.
3) Using chaos theory equations of possible changes in a ship's behavior before the next time slice, fractally extrude out a set of event cylinders (with hemispherical caps) of the ship's possible influence before the next frame, within the 3D space.
4) Loop through the generated event cylinders and look for intersections. Lump intersecting masses together as "causality bubbles." Sets of events that could potentially influence one another.
5) Rapid cache out the causality bubbles as separate sets and defer the simulation of each bubble out through microtasklets in Stackless Python.
6) Send only the information relating to a player's intersected causality bubble/matrix to that game client. (Dump client's simulation state from pervious frame in lieu of the server's state if they disagree.)
7) Allow the client and server to run the simulation of that causality bubble in parallel. Continue the simulation on the client to make it appear seamless.
8) Yield to other causality bubble simulations in DESTINY and Sleep() for 1000ms.
9) Download any input changes by the ship's pilot from the client at the end of the server frame. As ships do not respond to inputs instantaneously in EVE, this is fine.
10) Push that input into the force equations in the physics simulation for next frame.
11) Push the causality bubbles' simulation result to TRANQUILITY, the actual server Main() process.
12) End server frame, loop while the execution context has not received a shutdown signal.

This prevents you from encountering a runaway O(n^y) algorithm of every ship in a solar system potentially acting on every other, and by only sending updates to clients based on that client's ship's causality bubble, it allows the game to be played on only dial-up modem speeds.

The only downside is in large space battles, in crowded spaces. In these scenarios, the intersection of extruded causality cylinders tends to encompass the entire system. This ship can influence this ship which can influence these ships which influence... etc. So the partitioning of simulation afforded by causality bubbles goes away. They tossed out some similarly awesome-sounding ways to fix this, that are in development, but I'm not allowed to talk about them.

Other really sweet things they did:

- Dynamically generated all solar systems in the universe using actual supercomputer-run disk accretion models. This means every solar system was formed the same way actual astronomical ones are, and no system is artificially held together by anything that would not work in real physics.

- Originally, the random seed to generate the EVE universe was taken from the server's Epoch Time at the start of the universe generation. The guy in charge decided, the night before launch, to regenerate the entire universe at the last minute with the seed "42."

- The location of solar systems relative to one another were modelled after cellular cohesion equations - the same thing that makes gold deposits form, blood vessels to grow in your body, and sets the pattern of the universe filaments as seen in the Cosmic Microwave Background Radiation.

Also, much thanks for all of the constructive feedback ... "you don't know what you don't know" ... as they say in the biz

I'm glad I asked. o/

I was just quoting the article :P I will defer to your knowledge on this one :)

Next time someone complains that 5000 ship fights causes 10% TiDi to come into affect you need to point them to the above link :)

Cheers to the OP! It's cool to see my errant idea sparked a thread. Lets hope the Devs see and respond.

I support this thread


Edit rather than double post:

Admittedly, I have very little knowledge and experience with network infrastructure beyond keeping a few ancient computers talking to one another at my RL job. That said, I recall an article where CCP said they do actually use multi-core CPUs. They just run one core and use the others as heat sinks for the operating overclocked core. While the increased poling speed would impact greater computational load in normal time, wouldn't TiDi remain relatively uneffected? Or would in further slow down?

The one advantage, among many, in increasing the polling rate and bringing down the server ticks is it would add a layer of challenge with piloting smaller class ships, but in evasion and tackle. It would improve the quality of small fleet fights and would increase the risk reward benefits of exploration, interception and fleet doctrines.

Suddenly that ceptor, that was always able to get away because of rounding on the server tick side will have to think twice or use new tactics to move around a system.

The resulting calculations are not. When you have to relay the information (say a change in a ships vector due to a double-click in space) you have to transmit that to every other ship on grid. It is precisely n^2 increased communication over the network.

Also; drop the attitude.