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

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

Jita Park Speakers Corner

 
  • Topic is locked indefinitely.
 

Bake Sale (plex drive) for a second "Jita" node

Author
1Robert McNamara1
Ministry of War
Amarr Empire
#1 - 2014-01-20 20:37:06 UTC
I'd really like to see a second Jita sized node available for Eve. I'm even willing to pitch in some plex to make it happen. I figure there's other null pilots and even Jita traders who feel the same. I know it would just be a band aid. I acknowledge my bros in the CFC or my enemies in PL/N3 can just bolster even more numbers with even more sentry drones. But that's OK! Here's why:

Hardware architecture and underlying code for Eve are not likely to change soon. This investment would remain valuable for 3+ years. Any optimizations and improvements made by CCP will not negate current hardware design, but instead improve functionality on the existing platform. Thus, and improvement that benefits normal nodes also improves the super node and raises the soft-cap on huge fights. Lastly, there are limited nodes available and staging systems alone can require reinforcement. Rather than add +1 to that pool, better to add +1 Jita level node to allow for truly epic fights.

Naturally I would want CCP to pony up the cash themselves as part of their SLA to us. I can see how this may not be optimal or high enough on their priorities. CCP is likely focusing resources at the code level to address these problems, and I think they should continue. I think that a plex drive would demonstrate just how important this issue is, provide a vehicle for quick resolution, and give both Null Blocs and Jita traders a means to 'help themselves' without waiting for red-tape and budget cycles.

Transparency: I'm in a Sov holding alliance to participate in big fights with big toys. I want to know that when all sides of a bloc war say 'CCP ****'s gonna get real.' there will be no hesitation in providing us the best node available.
Lisara Khatam
Aliastra
Gallente Federation
#2 - 2014-02-20 19:17:12 UTC  |  Edited by: Lisara Khatam
IIRC, the battle for 6VDT-H held around 4100 pilots in local, on the same node that hosted Jita. At the time, Jita was also in TiDi with over 2000 pilots. That's over 6000 people on the same node!

The most recent battle, B-R5RB, had only 2000+ people in local. The node that it was on was reinforced after the battle had begun.

CCP has a tool for dictating when large fights will occur, so that on the day of the fight, they can place it on Jita's Supernode. B-R happened by complete accident, and was rushed to make sure the node remained stable.

There shouldn't be another Supernode at this point.
1Robert McNamara1
Ministry of War
Amarr Empire
#3 - 2014-02-24 20:16:01 UTC  |  Edited by: 1Robert McNamara1
Lisara, you are factually incorrect.

6VDT-H had 4.1k in local yes, but that node resource was not shared with Jita local as well. Jita had a separate node with less horsepower. I think Jita should not suffer whenever 0.0 has epic fights, there should be two Jita sized nodes (or 3 if Amarr also has its own Uber node).

B-R5RB was random but big warzones could benefit from more reinforced nodes anyway. B-R was a staging system. I'd like to see each staging system in a major bloc war have their own node.

The 'tool' is a form submission. CCP reviews the submissions and chooses which node to use. 6VDT got the best node in the game because literally every null sec group said 'we're bringing big numbers.' and the Fountain war was plagued by awful server accidents. 6VDT had to go perfect. In contrast B-R got a normal reinforced node because Halloween War has been pretty smooth from a server perspective (HED the one exception).


I don't mind you disagreeing with me, just please know your facts first.
Anhenka
Native Freshfood
Minmatar Republic
#4 - 2014-02-27 21:36:19 UTC  |  Edited by: Anhenka
The CCP server is divided into server blades, of which each contains 8 cores. On the server blade that hosts Jita, only four of the eight are in use to permit greater use of those four, with the other three dedicated to fleet fight reinforcement requests.

CCP Explorer wrote:
TQ-SOL0100 is actually an 8 core machine, with 4 cores turned off so we can run the other 4 overclocked. Jita is on one of 4 nodes (we run a node per active core) and the other 3 are reserved for fleet fights (see https://community.eveonline.com/support/fleet-fight/). Amarr also has a dedicated node, but less powerful hardware.

There are effectively four "Jita nodes" available for use without the use of any them having a significant influence on the others.
Aside from the three dedicated fleet fight nodes, there are less powerful server blades for systems needing reinforcement not expecting load levels requiring one of the "Jita nodes", such as Amarr.

Many of the issues with collapsing nodes during fights in the recent wars were an artifact of database issues that occur when you have millions of calculations and information requests bouncing between thousands of sources occurring in a short period of time. Many of these were software issues not directly related to the processing power of the node it was using at the time and have since been fixed, resulting in a near total reduction of collapsed nodes since.


1Robert McNamara1 wrote:
I don't mind you disagreeing with me, just please know your facts first.
Balder Verdandi
Wormhole Sterilization Crew
#5 - 2014-03-05 04:20:54 UTC
So the obviously dumb questions ......



  • Why are we using physical nodes instead of virtual ones?

  • Wouldn't it be easier to add/remove resources on the fly when big fights happen?

  • Why couldn't those "big fights" be moved to a virtual "mega-node"?

  • Would the server side code prevent these ideas from happening?



  • Anhenka
    Native Freshfood
    Minmatar Republic
    #6 - 2014-03-05 04:40:42 UTC
    Balder Verdandi wrote:
    So the obviously dumb questions ......

  • Why are we using physical nodes instead of virtual ones?

  • Wouldn't it be easier to add/remove resources on the fly when big fights happen?

  • Why couldn't those "big fights" be moved to a virtual "mega-node"?

  • Would the server side code prevent these ideas from happening?


  • I'm no expert on this sort of thing, but I'm 99% sure you can't run a single thread process on whatever the hell a "mega-virtual-node" is better than you can run it on the fastest single core processor available.

    A single threaded process like EVE seems by definition to be something you can't run on any sort of conglomerate processing mechanism, due to the enforced sequential order that the server receives, processes, and sends out information.

    If it were that easy, we wouldn't be having the hardware issues we are having, would we?
    Balder Verdandi
    Wormhole Sterilization Crew
    #7 - 2014-03-05 04:57:41 UTC
    Anhenka wrote:
    I'm no expert on this sort of thing, but I'm 99% sure you can't run a single thread process on whatever the hell a "mega-virtual-node" is better than you can run it on the fastest single core processor available.

    A single threaded process like EVE seems by definition to be something you can't run on any sort of conglomerate processing mechanism, due to the enforced sequential order that the server receives, processes, and sends out information.

    If it were that easy, we wouldn't be having the hardware issues we are having, would we?




    In a virtual environment, you should be able to move a virtual machine from one physical box to another when the first physical box doesn't have enough resources to function normally. We do this all the time with Windows (I know, bleh) servers when a particular physical machine can't handle the load of the multiple virtual machines running on it.

    The principle would be the same here by moving a particular node from one physical blade, or to a virtual server, to another with more resources. You could also move underutilized nodes to the same blade or blades without a significant load to free up other nodes for some of the big battles that have been known to crash servers.

    This way, we don't have huge null-sec/low-sec battles affecting game play on the other side of the known universe.
    Anhenka
    Native Freshfood
    Minmatar Republic
    #8 - 2014-03-05 05:46:37 UTC  |  Edited by: Anhenka
    Balder Verdandi wrote:

    In a virtual environment, you should be able to move a virtual machine from one physical box to another when the first physical box doesn't have enough resources to function normally. We do this all the time with Windows (I know, bleh) servers when a particular physical machine can't handle the load of the multiple virtual machines running on it.

    The principle would be the same here by moving a particular node from one physical blade, or to a virtual server, to another with more resources. You could also move underutilized nodes to the same blade or blades without a significant load to free up other nodes for some of the big battles that have been known to crash servers.

    This way, we don't have huge null-sec/low-sec battles affecting game play on the other side of the known universe.


    We already have variants of that in how the server groups systems for nodes, so that nowdays, large battles tend to have a more localized effect, not random systems across the universe. But unlike Windows where the operating system is divided into a massive number of individual components, EVE is a single threaded process. You can shuffle a particular system or node around all you want, but it's still going to have to be completely run on one single discrete processor, one operation at a time. The capability of that particular processor is the upper limit on what any individual in game system can do.

    As for the type of dynamic allocation you are asking for, they have manually performed certain operations even during use, but they ask for people to submit fleet reinforcement tickets in advance for a reason. Attempting to migrate resources to or away from a non reinforced node during operation is a very tricky situation at best that in the past at least has resulted in a temporary shutdown of the systems being maintained by the processor capability they are attempting to free up (And in one memorable typo occasion, the shutdown of the system they were attempting to reinforce on the fly). The eve server code, unlike Windows, was never built with the sort of underlying foundation that would permit rapid automatic reallocation to another processor easily.

    TLDR: Ehhhh..... No. not for the foreseeable future from what the EVE devs have leaked about their hardware/software.
    1Robert McNamara1
    Ministry of War
    Amarr Empire
    #9 - 2014-03-21 14:57:45 UTC
    Anhenka wrote:
    The CCP server is divided into server blades, of which each contains 8 cores. On the server blade that hosts Jita, only four of the eight are in use to permit greater use of those four, with the other three dedicated to fleet fight reinforcement requests.

    CCP Explorer wrote:
    TQ-SOL0100 is actually an 8 core machine, with 4 cores turned off so we can run the other 4 overclocked. Jita is on one of 4 nodes (we run a node per active core) and the other 3 are reserved for fleet fights (see https://community.eveonline.com/support/fleet-fight/). Amarr also has a dedicated node, but less powerful hardware.


    That's some great info I missed earlier. Thank you.

    I wonder if a separate machine with its own RAM/chipset would be faster than sharing those motherboard resources between 3 Jita sized overclocked nodes or processors. Maybe just marginal gains though.