What is the barrier to increasing server response time to every half second instead of every one second?

Nullsec.

The servers already struggle over 1000 pilots with a 1Hz tick, exponentially increasing client polling simply won't help

That's a product of design. What network infrastructure would be needed to make it work?

That's a product of design. What network infrastructure would be needed to make it work?

Likely nothing that currently exists.

Network performance isn't the issue. Raw number of calculations per second is. When you double the polling rate the absolute number of calculations increases to the square.

So say you have 400 pilots scapping, and say (totally made up number) that it requires 100,000 calculations a second. This is firing solution, ship vectors, bumping, refits, damage calculations, bonuses going up and down, session calculations, drawing models and what not


100,000 square is 10 billion, its not a linear progression.

So more processing power and memory? I am genuinely ignorant of how CCP runs all this craziness ... not a troll thread, promise :D

thanks for the Red Storm reference... that's quite a machine

Another thing to understand is that EVE's base code is 10 years old... made when the most powerful CPUs were largely single cores. CCP bet on single core processing power to continually increase and wrote the code with that thought in mind.

As a consequence, most of EVE's architecture cannot multi-thread and so cannot take advantage of multiple core CPUs. The DEVs have been trying to rectify this for a few years now... breaking down parts of the system so that they can be processed parallel to each other (see: "Brain in a Box")... but it's slow work.

So more processing power and memory? I am genuinely ignorant of how CCP runs all this craziness ... not a troll thread, promise :D

So, if that has trouble running current fights... Imagine what would be needed to double it.

2 Hz would be fine under most conditions. If server load increases then it could go back to 1 Hz and then tidi would kick in at the normal point.

It's not like it would have to be 2 Hz all the time.

Pretty sure the game has to do this anyway due to tidi.

Network performance isn't the issue. Raw number of calculations per second is. When you double the polling rate the absolute number of calculations increases to the square.

So say you have 400 pilots scapping, and say (totally made up number) that it requires 100,000 calculations a second. This is firing solution, ship vectors, bumping, refits, damage calculations, bonuses going up and down, session calculations, drawing models and what not


100,000 square is 10 billion, its not a linear progression.

What is the barrier to increasing server response time to every half second instead of every one second?

*This comes to mind after reading some posts earlier today about the delay between the time commands are issued and implemented*

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.

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.

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.

Doubling the calculation frequency is a linear progression... Pay more attention in class.

- 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.

actually this is not true.

there are inconsistencies in the planets types / size / orbits vs the stars (the stars themselves are not valid in fact, between their actuall size vs type).

if you stick to the model, physics say NO (wrong orbit for a temperate vs the size of the star and / or star type for ex.)

if you stick to the datas, physic also say NO (or some planets should then be INSIDE of the star they are orbiting)

so, while i agree to believe they actually used a valid model, the datas associated, whether used for modeling, or in the various infos are not coherent with said model

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.

For people interested why this is very complicated math without understanding all the terms mentioned here it is very nice to read up on the N-Body Problem.
It is actually quite fascinating that simple gravitaional interactions start becoming unsolvably difficult just past 3 objects and simulation systems need to develop quite elaborate algorithms to do approximations.
Adding bodies can increase actual complexity quite a lot quicker then just O(n^2).
Doing the same thing twice as often though is quite trivially twice as much calculation per unit of time.

Doubling the calculation frequency is a linear progression... Pay more attention in class.

I definitely agree this should happen for non-giant population systems. Drone control since the AI patch has been a ***** because it takes a second for your drones to react.

not only drones, it happen more and more often that you activate a module and it take a second more to actually activate.

when this happen on a gate, where you try to point something, you succesfully ock, you are in range, but the module just doesn't start....... or some odd times, it cycles, but you don't have agression and the tgt still warp out .
no stabs involved, talking about shuttles or hictor focus point, also occurs with regular point vs regular ship but then, the wcs is a possibility so hard to tell (well, i'd say if cycle + aggro timer => wcs, if not, server fail).

tbh, this is infuriating, to actually point something and see it go anyway because of this tick crap

point should apply on same tick as lock if preactivated, you lock it with preactivation, point is applyed 100%

Have you noticed this more since Rubicon 1.1? I remember thinking that there was a twofold delay although the module was preheated ... maybe it wasn't "just me being tired."

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.

Have you noticed this more since Rubicon 1.1? I remember thinking that there was a twofold delay although the module was preheated ... maybe it wasn't "just me being tired."

Porting from Python to something that can do multi-core work a la Red Hawk would basically be Eve 2.....they would be starting from the ground up with a completely different environment.

That's if you increase the number of pilots / entities on grid. Not if you double the frequency of calculation.

Doing the same calculations for one tick now, and then doing it again in .5s or in 5 minutes will use the same amount of processing power for the tick.

Python can do multi-core processing just fine if that's how you program with it.

CCP has said this is impossible.

without a complete base code rewrite.

ftfy.

Nothing is impossible. It either isn't worth the effort/money or we simply don't know how to do it yet. In this case, not worth the effort to dedicate the entire staff for the year or so required to make it happen.

Python yes.... There still working largely with slack-less python. While in there server cluster they have anywhere from single core to multi core and multi cpu systems, Slack-less python runs everything single threaded... You can spawn micro threads inside of a slackless python environment which is what Tranqulity does but its still running off one core of any given system literately the system would burn out a single core of a processor without touching any other core. During Incarna they were and did Carbion engine and were working on carbon io to address slackless python issue's and allow the servers to run on true multi thread and multi processor hardware.. No idea how far they are into this when you take old code and re write it into newer eco system programming differences crop up stuff that used to work will have issues.

Even if they were to migrate to a new version of slack-less that supports Multi core multi threaded or PyPy you still have the issue alot of your code needs completely re written. Even if its the same software... Newer versions bring great features sometimes quality of life but older stuff does break.. That is the nature of programming.

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.

Just Google slack-less python. and read about it :P Fundamentally its actually really good.. CCP's issue is there still running largly versions that dont have multi cpu and multi threaded support.. (hardware level)

Cheers for all the informative replies! Learned alot from it.

The answer to the thread title is ugly. Bugs would be introduced, performance would degrade, for a marginal improvement that only insta-locking legions and thrashers would notice.

It is stack less not slack less...

I noticed that when my modules were preheated the 1tick-delay was not noticeable at all ... could this be because all of the input was processed at the same time rather than getting target lock and then applying module effect?

... I'm not really sure of the right way to word that ^ ...

[Cynabal, test]

4x 425mm AutoCannon II (Barrage M)
Medium Energy Neutralizer II

2x Large Shield Extender II
Adaptive Invulnerability Field II
Warp Disruptor II
10MN Microwarpdrive II

Nanofiber Internal Structure II
2x Gyrostabilizer II
Tracking Enhancer II
Damage Control II

Medium Polycarbon Engine Housing I
2x Medium Core Defense Field Extender I

just checked, and whther a point is preheated or not, it take at least 2 ticks to actually apply, 1 for lock if lock < 1s (in fact, minimum lock time is 1sec as per the srver tick), then next tick, point apply.

wich mean, anything warping under 2 sec is uncatchable, and under 3 sec almost incatchable at a gate (because of the reaction time when he decloack).

as now, any ceptor / shuttle / pod (and some fast frig) cannot be catched unless smartbomb / bomb / bubble if the first order given is a "warp to" order (and provided they are still cloacked when order is issued)

it is so bad that such fast entitys often show up on overview being 200+ km away @ 3500+ m/s (i.e. already in warp)

and yet i have a very good connection, with a 16ms +- ping, i can't imagine the nightmare for AUS or NZ ppl for example, when their ping adds to the reaction time and stuff

just for giggle, i tested, and a cynabal flown by a pilot with a full low grade nomad, shield dps fit witha t1 polycarbon rig and a nanofiber align in 1.97s..... so even some cruisers can achieve it

Likely nothing that currently exists.

Network performance isn't the issue. Raw number of calculations per second is. When you double the polling rate the absolute number of calculations increases to the square.

So say you have 400 pilots scapping, and say (totally made up number) that it requires 100,000 calculations a second. This is firing solution, ship vectors, bumping, refits, damage calculations, bonuses going up and down, session calculations, drawing models and what not


100,000 square is 10 billion, its not a linear progression.

Yes, but if you take the number of quamtum calculations and multiply it by a finite number of idioms, then the resulting equation is equal to the number of server ticks multiplied by the quantum capacitors ability to keep pace with the full cycles of the square root of the hypotinuse. And all this depends on the processing power of the current hardware minus the overhead of the cycles lost in heat generating calculations of the parallel equations...

KAAAAAAHHNN!!!!!!!!

wut?

That was a Star Trek reference to the adversarial relationship between JT Kirk and Kahn. The underlying implication is that, like Kirk, I have too many feelz and need to vent my frustration with not having found a way around 2-tick clicking associated with a 1Hz cycle.

*also, thank you for testing my hypothesis!

You really think so?

Meet TQ.
TQ is a Beast. To double the polling rate, you'd need *four* such beasts. How much are you willing to pay per sub to support such a monster?

More like "How much are you willing to pay your subs to finance the R&D required to design/manufacture CPU going at 4 time the current wall." since we currently can't offload the process to other cores so adding a load balancing infrastructure is bound to be just as fruitless.

CCP was awoxed a long time ago when Intel and AMD quit the GHz race.

Meet TQ.
TQ is a Beast. To double the polling rate, you'd need *four* such beasts. How much are you willing to pay per sub to support such a monster?

No! It is silly to think a game like Eve requires more power than anything else the world has ever seen. It is just a matter of having enough power. The question is weather it is cost effective for CCP to do so.

CCP should consider moving their data center to Amazon to take advantage of spot pricing on AWS servers. That way instead of buying a ton of servers that are overkill 90% of the time, you only pay for server time as needed. They could do some really cool stuff like automatically bring additional nodes online based on the number of players in an area.

I know that would be a huge undertaking, but if Amazon works for Netflix, I am sure it could work for CCP.