| Pages: 1 :: [one page] |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Datamax
Genco
Interstellar Alcohol Conglomerate
   |
Posted - 2007.04.03 08:39:00 -
[1]
Was wondering if there was a dynamic model for allocating node/processor time to a solarsystem.
after some of the large battles in which modules have failed to respond for 10 minutes or more due to lag, there comes a limit on what a client tweak can cope with, and the load is forced back to the CCP game servers..
the suggestion is an addition to the code that monitors the jump levels on a system, and current pilots.
while the system population remains steady, with only an X percent variation, it continues as usual. however, if the population rises about a preset level. and/or a large spike in player numbers occurs, the system actively phases in additional resources to reduce latency issues. |
Mainreh Rhonaki
Jazz Associates
R i s e
|
Posted - 2007.04.03 09:36:00 -
[2]
IANAD. From my limited understanding, this is how it works.
1) All star systems in a constellation are normally on the same SOL node (read 2- or 4-proc computer).
2) Each solar system can utilize only one processor (infact only one core in the case of multicore procs).
Thus, the best you can do is evict all the other solar systems from the SOL node so that the critical system is undisturbed by other activity (e.g. interrupts, bus reads, large MMU paging operations). Under these circumstances, a node seem to be able to handle about 700 pilots.
However:
1) Evicting a system to another (standby) node likely can not be done transparently to the user.
2) It is likely that other systems in the same constellation (i.e. the eviction candidate) contain pilots indirectly engaged in the same battle and would be seriously disrupted if they were temporarily shut down by the eviction (think gatecamping one system out from the critical system).
|
Datamax
Genco
Interstellar Alcohol Conglomerate
|
Posted - 2007.04.03 09:44:00 -
[3]
Edited by: Datamax on 03/04/2007 09:45:00
i would be more interested in having "standby" power available, instead of dropping systems to support another, as that has immediate implications if your staging a multi stage attack or hitting a few targets in the same area.
given that these massive fleet battles only occur 1 every few days (or longer, depending on what playercount per engagement you wish to use as a threshhold), a few backups should be able to cope with the load
i realise the transition may not be transparent.. but a pilot getting a progress bar and a message" moving to a new node" for 1 minute would be far better than waiting 10 minutes for local to load
maybe there is another level required here, might have to look at isolating 10x10 grids under extreme combat, or seperating the processor threads into various components to reduce the impact on players |
Nyphur
Pillowsoft
|
Posted - 2007.04.03 17:18:00 -
[4]
Edited by: Nyphur on 03/04/2007 17:16:02
As is said above, major modifications to the cluster system cannot be made transparant to the user. This means that if one cluster is at max load and is supporting multiple star systems, it cannot simply offload some of the lower load systems onto a node that is being taxed for resources less. Or rather, it can do that but to do so would disconnect everyone on the node.
EDIT: They currently re-arrange system distribution among the nodes at downtime based on average load over the last x days. That's the best they can do if they can't make the changeover at least mostly transparant to the user.
There is a way for them to make cluster modifications transparant to the user but they have not implemented it. What you do is something called parallel running. It's a changeover strategy usually associated with longterm changeover from one computer system in a business to another and it avoids major disruption in service. In the short-term, it theoretically applies just as well. You start a star system on a low-load node but mute its output to the main sql server. Then mirror the static data and memory from a system running on the heavy load node to the newly created system, including forwarding a copy of all input there. You now have a clone of the system running. All that's left is to synch them up and when they're running completely synchronised, switch all I/O from the old star system to the new one. At most, the user's game could stall for a few seconds or jitter momentarily if it's done correctly. The heavy load node can then shut down that star system, lowering node load.
It would require a larger number of actual computers and would need extensive testing to rule out the myriad of problems that can occur with such a system but it would work if they did it properly. Problems that can occur when switching nodes are things like duplicating of items due to bizzare problems in switchover (it has happened to other games which have zones that people can ove between), preventing a stall to the user's game while in visible play and such. All of these problems can be solved in one way or another, CCP have just been working on other things instead of considering such a system.
Additionally, as I said, it'd require more actual computers since the changeover process requires CPU itself, meaning it would need to be enacted whenever a node got to say 80-90% load. Put a cap of one changeover per half hour for a star system and you won't have systems being laggy for much more than 30 minutes unless that one system uses the entire node's load (such as how jita currently does, I beleive). Though if CCP really wanted to fix the load problems, they'd allow individual systems to be split between multiple nodes. Currently, the only parts of a star system that can be split from the node it's running on are internal station environments, local chat channel, contracts and the market. The actual system (700+ pilots, high-load mission complexes and all) will always run on at most one single node.
It's quite feasible to split off large chunks of the system and run them on separate nodes. Missions, for example, or Jita 4-4 station or perimeter stargate in jita. Large 1AU spheres of space could be split to alternate nodes with switchover to those nodes occuring mid-warp to a destination inside them just as if you're jumping to a new system. If they could manage that and node changeover could be done dynamically and transparant to the user, the only remaining problems would be if 700+ people got into the same star system and into the same grid, which is something that is being tackled on the game-mechanics side by nerfing blob warfare.
But I doubt it'll happen.
Eve-Tanking.com - For tanking spreadsheet and resources. |
Elain Reverse
Caldari
Shokei
|
Posted - 2007.04.03 17:35:00 -
[5]
I dont unerstand why it would be not posible get some reinforce to node on stress, from HW side is not imposible and from SW side it should be possible too.
Well it would be good if we know what is limiting factor causing nodes to lag.
|
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.04.03 18:36:00 -
[6]
Edited by: Tonto Auri on 03/04/2007 18:34:46
Suggested days ago...
 Originally by: Elain Reverse
I dont unerstand why it would be not posible get some reinforce to node on stress, from HW side is not imposible and from SW side it should be possible too.
Well it would be good if we know what is limiting factor causing nodes to lag.
Wrong design of the galaxy. Devs should review it but they too busy playing EVE (Can't understand why EVE still in beta stage if that is untrue)
--
. |
Vicious Phoenix
|
Posted - 2007.04.03 21:12:00 -
[7]
Originally by: Mainreh Rhonaki
2) Each solar system can utilize only one processor (infact only one core in the case of multicore procs).
If that is the case the only thing that can help lag is fixing the code so it can run one solar system across multiple cores/procs. I can understand the reasoning since dual core was a ways off when EVE first came out but there is no excuse for not re-coding it now that dual core is the standard. Actually, multi proc servers were around when it came out so why wasn't it coded for that? Guess CCP didn't expect the kind of load single systems get in fleet warfare.
CFW (Certified Forum Warrior)
I kill people ingame too. |
Elain Reverse
Caldari
Shokei
|
Posted - 2007.04.03 21:32:00 -
[8]
Originally by: Vicious Phoenix
Originally by: Mainreh Rhonaki
2) Each solar system can utilize only one processor (infact only one core in the case of multicore procs).
If that is the case the only thing that can help lag is fixing the code so it can run one solar system across multiple cores/procs. I can understand the reasoning since dual core was a ways off when EVE first came out but there is no excuse for not re-coding it now that dual core is the standard. Actually, multi proc servers were around when it came out so why wasn't it coded for that? Guess CCP didn't expect the kind of load single systems get in fleet warfare.
Actualy i know CCP is using Blade system from IBM and they are using Dualcore AMD procesors in it, it was told in few posts by CCP.
Blade are easily upgradeable server boxes to whitch you can add anything you want, more CPU, more RAM, more networkcard etc. Blades are also easily conected one to each other.
Eve Client dont suporting multithread, but I dont believe server do it same way, it would be wasting resources to limit them in this way.
|
Icome4u
IronPig
Sev3rance
|
Posted - 2007.04.04 01:46:00 -
[9]
CCP already has the answer for all the large fleet lag. They are nerfing large fleets
CCP answers to problems = Blizzard answers to problems
Easiest, cheapest fix FTW! Screw the players!
|
| |
|
| Pages: 1 :: [one page] |