These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

In-Game Events and Gatherings

 
  • Topic is locked indefinitely.
 

Eve-Bet Revenant Event Feedback

First post First post
Author
Previous Topic Next Topic
Sales Alt negrodamus
Sanctuary of Shadows
#61 - 2014-09-15 11:49:54 UTC
Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
Fix Lag
The Scope
Gallente Federation
#62 - 2014-09-15 13:41:31 UTC
fix it fix it fix it

CCP mostly sucks at their job, but Veritas is a pretty cool dude.
Barbaydos
Kraken Exploration and Janitorial Services
The Initiative.
#63 - 2014-09-15 13:50:53 UTC
CCP Explorer wrote:
  • The last part is more tricky and the one we would appreciate feedback: How can we spread large fights over multiple systems in such a manner that it's fun for everyone involved? Some sort of a simultaneous mega-objective across multiple systems but only when there are many involved so you could still have single-system fights depending on man-power (we don't want to require people to always have 3000+ pilot fleets). This happened in B-R since there were fights in the staging systems and Titans and fleets were intercepted en route to B-R.
    • [/list]


    2 ideas here

    would it be possible that if multiple systems are reinforced within the same region or constellation they could have a linked timer? i.e. an ihub and a station within the same constellation are both reinforced and because of the linked timers they come out at the same time.

    if you dont hit both targets and succeed with both timers within say 15mins of each other then the target that was not successfully hit within that 15min window gets an accelerated regen rate until it resets back to either the previous timer or full hp.

    OR

    for each timer you hit a anomaly or plex site spawns with a target that must be killed within a certain time. killing the target would result in a reduction in hp of the main target whilst defending the target would result in a hp bonus to the main target.

    so basically if you attack the secondary site you help your main attack on the main structure, whereas if you dont then you only just make the job harder for yourself.




    CCP Explorer
    C C P
    C C P Alliance
    #64 - 2014-09-15 14:59:28 UTC
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    Sierra Payne
    Federal Navy Academy
    Gallente Federation
    #65 - 2014-09-15 15:53:35 UTC
    CCP Explorer wrote:

    Team Gridlock is continuing on rewriting Dogma and on the Brain-in-a-Box project. There are also other things on the table such as drone-swarms where all drones act in a swarm like one drone, this would be similar to the grouped gun system. Given the O(n^2) nature of drones this would significantly reduce load in certain scenarios.


    Would it be an idea that when TiDi goes under 10%, that each player gets a sort of notification that's non-intrusive that tells them their command has been send to the server? That way you may reduce some input lag as well?
    Arthur Pendrag
    The Scope
    Gallente Federation
    #66 - 2014-09-15 16:22:06 UTC
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.



    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.
    Chagatai Chinua
    Garoun Investment Bank
    Gallente Federation
    #67 - 2014-09-15 16:23:20 UTC
    CCP Explorer wrote:
    MonkeyBusiness Thiesant wrote:
    Couple quick thoughts:


    1) Is it possible to just turn off crimewatch in a LS system undergoing this level of tidi? Not an ideal solution, but at the same time not really a big loss in giant fleet situations either.

    2) How about stopping drone use entirely in particularly heavy tidi? People can still turn up, just have to use non-drone ships. Obviously this sort of artificial limitation isn't at all ideal, and the droneswarm changes mentioned above will deal with the issue longterm, but if it makes big fleet fights more bearable that's clearly superior to the current situation.
    No on both, because if we did that then Time Dilation stops being a method to mitigate/spread load and instead becomes a game mechanic.


    In Real Life, the mechanisms which maintain social order, such as policing, do in fact break down in the face of "unexpected load." Lots of things that would get you arrested on a normal day will pass unnoticed in the middle of a large demonstration, to say nothing of a riot.

    So it wouldn't be unrealistic per se to have an actual mechanic where law enforcement response - CONCORD and even security status penalties - become degraded in the face of massive system population.

    I don't think its stretching the lore too far to suggest that the physical substrate of drone communication, whether it be EM spectrum or some hyperwave thing, is not infinite and thus there is a cap on the total amount of drone activity that can occur on a given grid.

    It's true that this is basically retconning a mechanic that suits the limitations of the current implementation, but to be honest that's something every game does, not just MMOs or computer games.
    Xenuria
    #68 - 2014-09-15 17:26:20 UTC
    I realize that some of the hardware is classified but I would appreciate any transparency that is possible.
    It's nice to know that some super amazing hardware is doing hardware stuff but I for one would like to have charts and infopics on the utilization of the hardware. I want to see actual technical specs like speeds and such.

    Obviously that cannot be done for the jita server because it's supa sekret. I just want to see much more transparency on the technical aspect.

    CSM 12 Candidate
    Max Kolonko
    Caldari Provisions
    Caldari State
    #69 - 2014-09-15 17:39:35 UTC
    Arthur Pendrag wrote:
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.



    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.


    This comes up all the time and answer is the same. Difficulty comes from the fact that eve is single threaded. It would have to be rewritten to support multi-threading.

    Read and support: Don't mess with OUR WH's What is Your stance on WH stuff?
    Arthur Pendrag
    The Scope
    Gallente Federation
    #70 - 2014-09-15 17:45:55 UTC
    Max Kolonko wrote:
    Arthur Pendrag wrote:
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.



    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.


    This comes up all the time and answer is the same. Difficulty comes from the fact that eve is single threaded. It would have to be rewritten to support multi-threading.


    I thought that referred to the client and not necessarily the server side.
    Max Kolonko
    Caldari Provisions
    Caldari State
    #71 - 2014-09-15 18:22:11 UTC
    Arthur Pendrag wrote:
    Max Kolonko wrote:
    Arthur Pendrag wrote:
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.



    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.


    This comes up all the time and answer is the same. Difficulty comes from the fact that eve is single threaded. It would have to be rewritten to support multi-threading.


    I thought that referred to the client and not necessarily the server side.


    That definitely refers to server side.

    Read and support: Don't mess with OUR WH's What is Your stance on WH stuff?
    Locke DieDrake
    State War Academy
    Caldari State
    #72 - 2014-09-15 19:54:08 UTC
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?


    The game code was made before multi-core/MPP systems became the standard hosting paradigm. Meaning, in order for EVE to run on a single solar system on multiple pieces of hardware (IE: clustering) they would have to rewrite a great deal of the base code. Something they have been utterly unwilling to do. See POS code, corp code, basically every major issue with the game... it starts right here.
    CCP Explorer
    C C P
    C C P Alliance
    #73 - 2014-09-15 20:30:36 UTC
    Sierra Payne wrote:
    CCP Explorer wrote:
    Team Gridlock is continuing on rewriting Dogma and on the Brain-in-a-Box project. There are also other things on the table such as drone-swarms where all drones act in a swarm like one drone, this would be similar to the grouped gun system. Given the O(n^2) nature of drones this would significantly reduce load in certain scenarios.
    Would it be an idea that when TiDi goes under 10%, that each player gets a sort of notification that's non-intrusive that tells them their command has been send to the server? That way you may reduce some input lag as well?
    Commands are sent by the client, received by the server and put into the processing queue in a matter of a couple of seconds at most even under heavy load and lag. Even for exceptionally large events, such as this one, we rarely if ever see scheduler lag. We then rarely see any processing queues build up, except for the damage calculation queue (this system is called Dogma).

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    CCP Explorer
    C C P
    C C P Alliance
    #74 - 2014-09-15 20:33:48 UTC
    Arthur Pendrag wrote:
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.
    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.
    All of the above. It's not really even a matter of hosting a solarsystem on multiple nodes since we would have to reap the benefits in big fights where all the action takes place on a single grid and everyone is potentially affecting everyone else and at least everyone needs to know about everyone else (and all their drones).

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    CCP Explorer
    C C P
    C C P Alliance
    #75 - 2014-09-15 20:36:10 UTC
    Xenuria wrote:
    I realize that some of the hardware is classified but I would appreciate any transparency that is possible.
    It's nice to know that some super amazing hardware is doing hardware stuff but I for one would like to have charts and infopics on the utilization of the hardware. I want to see actual technical specs like speeds and such.

    Obviously that cannot be done for the jita server because it's supa sekret. I just want to see much more transparency on the technical aspect.
    We will write a devblog on the new hardware once we have replies to the RFPs and have made a decision on both what we are buying and when. Currently this in RFP stage.

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    CCP Explorer
    C C P
    C C P Alliance
    #76 - 2014-09-15 20:38:01 UTC
    Max Kolonko wrote:
    Arthur Pendrag wrote:
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.
    Does the difficulty arise from trying to keep multiple nodes synchronized, serialize events, or ??? Finding a way to parallelize the handling of a solar system seems like a fascinating challenge with a huge payoff if you can make it work. With the way Intel keeps managing to cram more cores into every cpu generation yet not significantly increasing the execution speed of single threads it just begs you to spread the work load around.
    This comes up all the time and answer is the same. Difficulty comes from the fact that eve is single threaded. It would have to be rewritten to support multi-threading.
    Multi-threading is not the silver-bullet you are looking for. Big fights often happen in a single grid where everyone and their drones are affecting everyone else (and their drones). This is a lot of shared state, synchronization and thread communication were it to be multi-threaded.

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    Sales Alt negrodamus
    Sanctuary of Shadows
    #77 - 2014-09-15 20:41:12 UTC
    CCP Explorer wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    In terms of hosting the simulation itself (both the physics simulation and the damage simulation) on multiple devices then that is very difficult.


    Eh, worth a thought.

    Personally I think a lot of milage is to be gained by going to multithreading and then to a cluster. The work required to do that would probably make it possible to do on the fly (dynamic!) node reinforcement which would be Neat(tm).

    Generally though it seems like you guys are fighting a losing battle. I don't know what the interaction scaling is for all the crap that goes on in a node during a big battle, but I hear O(n^2) often enough that I'll take that at face value.

    You got two choices with a problem like that. You can either throw more computational resources at it (multi-threading, clusterization, etc) or you can make n smaller. It seems you guys are going down the 'less crap to compute' route with doing stuff like brain in the box (progress on that? sounds neat), reduction of drone interactions, weapon and eventually drone (?) grouping, etc.

    CCP Explorer
    C C P
    C C P Alliance
    #78 - 2014-09-15 20:47:11 UTC
    Locke DieDrake wrote:
    Sales Alt negrodamus wrote:
    Explorer, just out of curiosity, how big are the technical hurdles to hosting a single eve system on multiple physical devices (read: cluster)?
    The game code was made before multi-core/MPP systems became the standard hosting paradigm. Meaning, in order for EVE to run on a single solar system on multiple pieces of hardware (IE: clustering) they would have to rewrite a great deal of the base code. Something they have been utterly unwilling to do. See POS code, corp code, basically every major issue with the game... it starts right here.
    You are very conveniently ignoring Crime Watch and Industry that we very recently revamped. Before that we replaced the network layer, moved the database to 64 bits, implemented Time Dilation, moved load from the simulation nodes into speclized nodes such as the Character Service nodes, worked on various improvements to the rendering performance. In addition to general development of new and improved features. Even if we haven't yet embarked on fixing the areas you are most concerned with then you can't use that to generalize that we are "utterly unwilling" to improve the game when it entails rewriting significant parts of the base code.

    Also, TQ is a cluster. It's approx. 60 blades hosting 248 nodes (with further 10 blades hosting 47 traffic routing proxies (that also have some logic)). There are specialized nodes within the cluster for the market, for corp. and alliance processing, for all services relating to characters, for planetary interaction, etc, etc. Most of the nodes host simulation, which is primarily the physics simulation, the damage calculations and the overall item inventory of the universe.

    Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @CCP_Explorer
    Sentient Blade
    Crisis Atmosphere
    Coalition of the Unfortunate
    #79 - 2014-09-15 21:28:55 UTC  |  Edited by: Sentient Blade
    CCP Explorer wrote:
    You are very conveniently ignoring Crime Watch and Industry that we very recently revamped. Before that we replaced the network layer, moved the database to 64 bits, implemented Time Dilation, moved load from the simulation nodes into speclized nodes such as the Character Service nodes, worked on various improvements to the rendering performance.


    It's a fair point, but by contrast these are pieces of low-hanging fruit and with the exception of int64 and tidi are what I would term functional gameplay changes.

    To me as a software engineer, the single-threaded nature of the EVE server code is the elephant in the room that everyone knows is, includes it in conversation, but nobody dare not have a glance cast its way. I note I'm a software engineer because I am very much familiar with the feeling of "Touch that, and I might not be seen again for 10 years".

    Unfortunately for CCP I get the impression that it's clearly the single biggest cap on the lifetime of the code, as the meta moves towards larger and larger fights it will become more and more important, and no amount of clever trickery or improved processors will get away from it.

    At the very least I would have expected a move towards thread-per-grid on a single machine.
    Vincent Athena
    Photosynth
    #80 - 2014-09-15 23:44:13 UTC  |  Edited by: Vincent Athena
    How about: One thread per pilot?

    Also:
    CCP Explorer wrote:
    Sierra Payne wrote:
    CCP Explorer wrote:
    Team Gridlock is continuing on rewriting Dogma and on the Brain-in-a-Box project. There are also other things on the table such as drone-swarms where all drones act in a swarm like one drone, this would be similar to the grouped gun system. Given the O(n^2) nature of drones this would significantly reduce load in certain scenarios.
    Would it be an idea that when TiDi goes under 10%, that each player gets a sort of notification that's non-intrusive that tells them their command has been send to the server? That way you may reduce some input lag as well?
    Commands are sent by the client, received by the server and put into the processing queue in a matter of a couple of seconds at most even under heavy load and lag. Even for exceptionally large events, such as this one, we rarely if ever see scheduler lag. We then rarely see any processing queues build up, except for the damage calculation queue (this system is called Dogma).

    CCP Explorer, I think you missed the point here. I, as a player in a laggy situation, click on something. I see nothing happening. So I think "Either I'm getting lag, or somehow my client did not register my click, or I mis-clicked".
    What to so? Spam that button!
    But that sends a ton of commands to the server, causing more lag. What I need is some indication of "Yes you did click that, and your command has been sent to the server".

    Know a Frozen fan? Check this out

    Frozen fanfiction