|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Onictus
Silver Snake Enterprise Fatal Ascension
801
|
Posted - 2014.02.06 02:20:00 -
[1] - Quote
Jamwara DelCalicoe Ashley wrote: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
|
Onictus
Silver Snake Enterprise Fatal Ascension
802
|
Posted - 2014.02.06 02:27:00 -
[2] - Quote
Jamwara DelCalicoe Ashley wrote:Onictus wrote:Jamwara DelCalicoe Ashley wrote: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?
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. |
Onictus
Silver Snake Enterprise Fatal Ascension
802
|
Posted - 2014.02.06 02:35:00 -
[3] - Quote
Jamwara DelCalicoe Ashley wrote:Onictus wrote:Jamwara DelCalicoe Ashley wrote:Onictus wrote:Jamwara DelCalicoe Ashley wrote: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? 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
Google articles for Sandia Labratory's Red Storm super computer. CCP has next generation hardware....some of the best enterprise level servers on the market....but otherwise the Tranquility cluster is very much a direct descendant of Red Storm.
|
Onictus
Silver Snake Enterprise Fatal Ascension
805
|
Posted - 2014.02.06 02:41:00 -
[4] - Quote
Jamwara DelCalicoe Ashley wrote:thanks for the Red Storm reference... that's quite a machine
If you can fine the youtubes from the last couple fanfests CCP Veritas's presentations cover a lot of the hardware, network and middleware layers that are the physical side of the cluster.
Since I'm in the field anyway, I pay VERY close attention to them usually. |
Onictus
Silver Snake Enterprise Fatal Ascension
806
|
Posted - 2014.02.06 03:09:00 -
[5] - Quote
ShahFluffers wrote: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.
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. |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:34:00 -
[6] - Quote
Rich Uncle PennyBags wrote:
So, if that has trouble running current fights... Imagine what would be needed to double it.
A true multi-threaded environment....which they can't do without re-writing the engine, like I said Eve 2. Basically what happened was that when these design descisions were being made Intel was forecasting 9GHz processors inside 10 years. Well, current manufacturing processes hit a wall about 4 years ago in the 4.2-4.4 range. The forcast was off by a significant margin.
The way this was mitigated on the hardware end was by multi-threading, which is great, when you aren't running a game up 10 year old code that was written to be strickly single core. The idea of load shedding to 8 cores at a time wasn't even on the radar for 8-9 years after eve's engine was developed. |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:44:00 -
[7] - Quote
James Amril-Kesh wrote: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.
Dynamic polling rates?
I've had to help debug the code for phased array radars that have to deal with that sort of thing. Basically replace client polling rate with radar dwell search patterns.
Suffice it to say its not that digital in nature a LOT of logic has to be delt with, which causes the same issue, as calculation numbers increase so does processor load. What happens is that you end up with breakpoints where the logic to decide the rate takes up more processing resources than just staying at the lower rate.
Depending on the design margins, this can be a fairly wide range. |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:57:00 -
[8] - Quote
James Amril-Kesh wrote:Pretty sure the game has to do this anyway due to tidi.
Sort of.
Tidi is a computation to runtime. That is why the client speeds up and slows down in relation to the server, what is being suggested is increasing the server speed in relation to the client.
Depending on how the polling system is designed, its a non-trivial endeavor in master/slave relationships the master is supposed to be the control element. Hence, TiDi making the client run slower in real time, we know they can make the client run faster as well.
Making the client the control element means that you need new logic, and one that is on people's local machine and thus more easily hacked. |
Onictus
Silver Snake Enterprise Fatal Ascension
814
|
Posted - 2014.02.06 22:13:00 -
[9] - Quote
Notorious Fellon wrote:
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.
My point exactly. |
|
|
|