Pages: [1] 2 3 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 02:17:00 -
[1] - Quote
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* http://www.devilswarrior.info/kb |
Marie Hartinez
Aries Munitions and Defense
559
|
Posted - 2014.02.06 02:19:00 -
[2] - Quote
CCP would need twice the number of hamsters?
Surrender is still your slightly less painful option. |
Onictus
Silver Snake Enterprise Fatal Ascension
801
|
Posted - 2014.02.06 02:20:00 -
[3] - 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
|
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 02:21:00 -
[4] - Quote
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? http://www.devilswarrior.info/kb |
Mallak Azaria
GoonWaffe Goonswarm Federation
4590
|
Posted - 2014.02.06 02:24:00 -
[5] - 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?
Likely nothing that currently exists. This post was lovingly crafted by a member of the Goonwaffe Posting Cabal & proud member of the popular gay hookup site, somethingawful.com |
Onictus
Silver Snake Enterprise Fatal Ascension
802
|
Posted - 2014.02.06 02:27:00 -
[6] - 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. |
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 02:27:00 -
[7] - Quote
Mallak Azaria 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? Likely nothing that currently exists.
You really think so? http://www.devilswarrior.info/kb |
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 02:29:00 -
[8] - Quote
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 http://www.devilswarrior.info/kb |
Onictus
Silver Snake Enterprise Fatal Ascension
802
|
Posted - 2014.02.06 02:35:00 -
[9] - 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.
|
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 02:39:00 -
[10] - Quote
thanks for the Red Storm reference... that's quite a machine http://www.devilswarrior.info/kb |
|
Onictus
Silver Snake Enterprise Fatal Ascension
805
|
Posted - 2014.02.06 02:41:00 -
[11] - 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. |
ShahFluffers
Ice Fire Warriors Late Night Alliance
4811
|
Posted - 2014.02.06 02:53:00 -
[12] - Quote
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. Change isn't bad, but it isn't always good. Sometimes, the oldest and most simple of things can be the most elegant and effective. |
Onictus
Silver Snake Enterprise Fatal Ascension
806
|
Posted - 2014.02.06 03:09:00 -
[13] - 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. |
Batelle
Komm susser Tod
1577
|
Posted - 2014.02.06 04:47:00 -
[14] - Quote
CCP has said this is impossible. "CCP is changing policy, and has asked that we discontinue the bonus credit program after November 7th. So until then, enjoy a super-bonus of 1B Blink Credit for each 60-day GTC you buy!"
Never forget. |
Rich Uncle PennyBags
EVE Online Monopoly
118
|
Posted - 2014.02.06 05:09:00 -
[15] - 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
I don't think there's been any recent update on server specs... But they're pretty standard server farm stuff. Quite a large one though. I'm recalling a number of around 3500GHz total processing power.
The server they use for reinforcing large fights was talked about at ff a little while ago. It's a military/stock market machine. Cooling requirements include a dedicated air conditioning unit. |
Rich Uncle PennyBags
EVE Online Monopoly
118
|
Posted - 2014.02.06 05:10:00 -
[16] - Quote
I don't think there's been any recent update on server specs... But they're pretty standard server farm stuff. Quite a large one though. I'm recalling a number of around 3500GHz total processing power.
The server they use for reinforcing large fights was talked about at ff a little while ago. It's a military/stock market machine. Cooling requirements include a dedicated air conditioning unit.[/quote]
So, if that has trouble running current fights... Imagine what would be needed to double it. |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:34:00 -
[17] - 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. |
James Amril-Kesh
4S Corporation Goonswarm Federation
8921
|
Posted - 2014.02.06 06:39:00 -
[18] - Quote
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. My EVE Videos 59-15 |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:44:00 -
[19] - 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. |
James Amril-Kesh
4S Corporation Goonswarm Federation
8921
|
Posted - 2014.02.06 06:45:00 -
[20] - Quote
Pretty sure the game has to do this anyway due to tidi. My EVE Videos 59-15 |
|
SmilingVagrant
GoonWaffe Goonswarm Federation
2427
|
Posted - 2014.02.06 06:50:00 -
[21] - Quote
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: |
Onictus
Silver Snake Enterprise Fatal Ascension
809
|
Posted - 2014.02.06 06:57:00 -
[22] - 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. |
Ines Tegator
Towels R Us
351
|
Posted - 2014.02.06 07:25:00 -
[23] - Quote
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. - Mission Overhaul - Bridging the PVP / PVE Gap - -áIf the game stops teaching people to fear lowsec, maybe people will start going there? |
Pew Terror
Blue Republic RvB - BLUE Republic
53
|
Posted - 2014.02.06 08:12:00 -
[24] - Quote
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.
Doubling the calculation frequency is a linear progression... Pay more attention in class. |
Kagura Nikon
Mentally Assured Destruction The Pursuit of Happiness
1247
|
Posted - 2014.02.06 09:21:00 -
[25] - Quote
Jamwara DelCalicoe Ashley wrote: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*
CCP already said> NO .. it will NOT happen because DOUBLED server CPU usage. "If brute force does not solve your problem..... -áthen you are -ásurely not using enough!" |
Tuttomenui II
Aliastra Gallente Federation
203
|
Posted - 2014.02.06 09:21:00 -
[26] - Quote
Ines Tegator wrote: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.
There is nothing saying they haven't been working on it. It is just they wouldn't tell you if they were if it is still in the secret squirrel stage.
|
Kagura Nikon
Mentally Assured Destruction The Pursuit of Happiness
1247
|
Posted - 2014.02.06 09:22:00 -
[27] - Quote
Ines Tegator wrote: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.
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. "If brute force does not solve your problem..... -áthen you are -ásurely not using enough!" |
Adrie Atticus
Unicorn Love Hurts
2
|
Posted - 2014.02.06 10:21:00 -
[28] - Quote
Ines Tegator wrote: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.
Fully synchronized multi-threaded environment requires symmetrical input to work efficiently.
EvE data is most likely not symmetrical by nature and is made like that with the current ticks. As stated previously, the increased amount of processing required when going from 1Hz to 2Hz poling rate would require a big overhaul on how the server farm is set up.
Possible? Yes. Probable? Holy **** debugging multi-threaded code is ugly. |
Grayland Aubaris
Ocellus Technology
17
|
Posted - 2014.02.06 10:42:00 -
[29] - Quote
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. |
Jamwara DelCalicoe Ashley
Arbitrary Spaceship Destruction The Devil's Warrior Alliance
114
|
Posted - 2014.02.06 14:10:00 -
[30] - Quote
Pew Terror 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. Doubling the calculation frequency is a linear progression... Pay more attention in class.
i think we're square'ing at this point which would not be linear. however, since i'm not mathematically inclined i will leave that debate to the smrt people http://www.devilswarrior.info/kb |
|
|
|
|
Pages: [1] 2 3 :: one page |
First page | Previous page | Next page | Last page |