| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 5 post(s) |
Detshni
   |
Posted - 2005.09.12 06:31:00 -
[1]
Edited by: Detshni on 12/09/2005 06:30:51
Edited by: Detshni on 12/09/2005 06:30:33
EvE now running at 80%? When will we again get 100%?
|
TheNecromancer
|
Posted - 2005.09.12 06:37:00 -
[2]
when they find out whats wrong :)
Give them time...they also need some sleep
|
Idio T
|
Posted - 2005.09.12 06:43:00 -
[3]
I saw the population just over 15k today. Maynot have anything to do with the 80%.. But ummm ... Could be ...
Frigate about it! |
Ulukay
|
Posted - 2005.09.12 07:14:00 -
[4]
it ran great for 80% and 15.200 players :)
|
Jim Raynor
|
Posted - 2005.09.12 07:18:00 -
[5]
 Originally by: Ulukay
it ran great for 80% and 15.200 players :)
if being too lagged to even use the chat system is great, sure.
------
FERRET DEMOCRACY |
Matthew
|
Posted - 2005.09.12 07:47:00 -
[6]
Edited by: Matthew on 12/09/2005 07:47:00
Saw minimal lag where I was. The performance we got tonight, with a reduced number of nodes, just goes to show that the main lag problem right now isn't due to overall capacity, but due to problems of "blob" capacity - overloading of core systems/fleet-battles etc, and the knock on effects these have on other systems sharing the same node.
EDIT: Oh, and the rest of the nodes will be re-integrated into the cluster during the first DT after they get fixed.
Beware those beyond here, for they cannot see evil. |
Mind
|
Posted - 2005.09.12 08:24:00 -
[7]
MY EYES HURT!!!
I thought you all where talking about the 80% CPU use i normaly have on EVE..
but nooooo. 
anyway, the main problem with lag eve have is "core" systems. Ie, one server/node hanlding 100 or so players (or whatever number is "alot" for eve).. Go to a system where you are all alone, and you wont notice any of the lag.
Thats pretty nice, atleast for me. This, amongs other things (like, suffering in the world etc) can be blamed on Agent *****s and 1.0 huggers..
|
Matthew
|
Posted - 2005.09.12 08:38:00 -
[8]
Originally by: Mind
anyway, the main problem with lag eve have is "core" systems. Ie, one server/node hanlding 100 or so players (or whatever number is "alot" for eve).. Go to a system where you are all alone, and you wont notice any of the lag.
Unforutunately, going to an empty system is no guarantee of escaping the lag. This is because there are only 50 server nodes, but 5000+ systems, so each node has to host multiple systems. If your empty system is on the same node as a heavily populated system, the you're going to see the effects of lag from the heavily populated system.
Beware those beyond here, for they cannot see evil. |
Jacob Majestic
|
Posted - 2005.09.12 11:39:00 -
[9]
It's a little more complicated than that.
EVE on the server side is programmed in something called Stackless Python, which supports "pickling" and "unpickling" of tasks. Basically, what this means is that each system runs in its own "thread". These threads can be "pickled" (i.e. converted into a file) and transmitted over to another host, where they can be "unpickled" and resumed.
What this means is that most of the systems in the game typically run on 2 or 3 of those servers. When load spikes (i.e. mining op in 00), that system is pickled and moved to another server where it can get more of the server's capacity to itself.
(This might be a primary cause of fleet lag -- if the game sees load spike in one system and decides to move that system to another server, some clients will probably time out if it takes Python too long to unpickle and restart the thread.)
|
Fun Bags
|
Posted - 2005.09.12 11:52:00 -
[10]
mmmmmmm...
pickles 
|
Matthew
|
Posted - 2005.09.12 12:04:00 -
[11]
Originally by: Jacob Majestic
(This might be a primary cause of fleet lag -- if the game sees load spike in one system and decides to move that system to another server, some clients will probably time out if it takes Python too long to unpickle and restart the thread.)
The Devs have previously stated that they cannot transfer inhabited systems between nodes. It came up in an old discussion about fleet lag when the idea of fleet-combat super-nodes was suggested. This suggests the eve server can't use pickling to transfer inhabited systems across nodes for the simple reason that things will start timing out moving even small systems around. This could be more than just clients - there are inter-system calls that would hang up if the system in question was mid-pickle at the time. An entire system is not a small or easily moveable entity, least of all in a high-load situation when you might actually want to move it.
Pickling will work well for retiring empty systems back to the dormant pool, but I doubt it could move active systems between nodes without having to trigger a proper "loading" pause on the clients, and a way to handle requests from other parts of the cluster.
Beware those beyond here, for they cannot see evil. |
|
Valar
|
Posted - 2005.09.12 14:03:00 -
[12]
Originally by: Matthew
Originally by: Jacob Majestic
(This might be a primary cause of fleet lag -- if the game sees load spike in one system and decides to move that system to another server, some clients will probably time out if it takes Python too long to unpickle and restart the thread.)
The Devs have previously stated that they cannot transfer inhabited systems between nodes. It came up in an old discussion about fleet lag when the idea of fleet-combat super-nodes was suggested. This suggests the eve server can't use pickling to transfer inhabited systems across nodes for the simple reason that things will start timing out moving even small systems around. This could be more than just clients - there are inter-system calls that would hang up if the system in question was mid-pickle at the time. An entire system is not a small or easily moveable entity, least of all in a high-load situation when you might actually want to move it.
Pickling will work well for retiring empty systems back to the dormant pool, but I doubt it could move active systems between nodes without having to trigger a proper "loading" pause on the clients, and a way to handle requests from other parts of the cluster.
Right, systems are not pickled and moved between servers. A system stayes loaded on the same node for a full run, except if the node dies. Then the system is of course loaded on another node.
And the cluster is not on 80% capacity anymore. All nodes were started up this morning.
------
Valar
Quality assurance department
CCP games
How to write a good bugreport |
|
Dark Shikari
|
Posted - 2005.09.12 14:05:00 -
[13]
Originally by: Valar
Originally by: Matthew
Originally by: Jacob Majestic
(This might be a primary cause of fleet lag -- if the game sees load spike in one system and decides to move that system to another server, some clients will probably time out if it takes Python too long to unpickle and restart the thread.)
The Devs have previously stated that they cannot transfer inhabited systems between nodes. It came up in an old discussion about fleet lag when the idea of fleet-combat super-nodes was suggested. This suggests the eve server can't use pickling to transfer inhabited systems across nodes for the simple reason that things will start timing out moving even small systems around. This could be more than just clients - there are inter-system calls that would hang up if the system in question was mid-pickle at the time. An entire system is not a small or easily moveable entity, least of all in a high-load situation when you might actually want to move it.
Pickling will work well for retiring empty systems back to the dormant pool, but I doubt it could move active systems between nodes without having to trigger a proper "loading" pause on the clients, and a way to handle requests from other parts of the cluster.
Right, systems are not pickled and moved between servers. A system stayes loaded on the same node for a full run, except if the node dies. Then the system is of course loaded on another node.
And the cluster is not on 80% capacity anymore. All nodes were started up this morning.
I was told by Oveur after the servers went up on Help chat that an active node CAN in fact be transferred to another (i.e. Yulai moved to a new node while the server is up), albeit certainly not seemlessly. Does the system allow this, or is Oveur talking out of his arse? 
--
Proud member of the [23].
Selling Capital Cargo Bays and Kernite Mining Crystal IIs, cheaper than anyone else. |
|
Valar
|
Posted - 2005.09.12 14:13:00 -
[14]
Originally by: Dark Shikari
I was told by Oveur after the servers went up on Help chat that an active node CAN in fact be transferred to another (i.e. Yulai moved to a new node while the server is up), albeit certainly not seemlessly. Does the system allow this, or is Oveur talking out of his arse?
The only way to do this, is to kill the node or maybe with some programmer manipulations end all client sessions in the system and move it over. This is not a functionality thats supported by our framework.
------
Valar
Quality assurance department
CCP games
How to write a good bugreport |
|
M3ta7h3ad
|
Posted - 2005.09.12 16:25:00 -
[15]
300+ in ours last night = about a 2 minute load time at the gate. I was mid insta gang travelling on a mission, and ended up a jump and a bit behind them.
Key systems such as Ours should at least be moved to their own "almost" dedicated server perhaps hosting themselves, and some of the dormant systems.
However for 80% capacity and the 15000 users, eve did well to handle it as much as it did last night.
|
Matthew
|
Posted - 2005.09.12 18:44:00 -
[16]
Originally by: Valar
Right, systems are not pickled and moved between servers. A system stayes loaded on the same node for a full run, except if the node dies. Then the system is of course loaded on another node.
So system's don't get released to allow shuffling if they have no players in them?
Originally by: Valar
And the cluster is not on 80% capacity anymore. All nodes were started up this morning.
Yeay 
Originally by: Valar
The only way to do this, is to kill the node or maybe with some programmer manipulations end all client sessions in the system and move it over. This is not a functionality thats supported by our framework.
So basically force or simulate a node-crash, with the accompanying CTD's of all related clients? Certainly not a method I'd want to use!
Originally by: M3ta7h3ad
Key systems such as Ours should at least be moved to their own "almost" dedicated server perhaps hosting themselves, and some of the dormant systems.
I was under the impression this was already done for the key hub systems - or at least was done during the old Superhighway-crisis days. Of course, you can't do it with too many systems, or you'd leave too few nodes to run everything else. And you'd have to be careful which "dormant" systems you chose to assign with it. Most 0.0 systems are "dormant" except for the one night a month someone wants to have a fleet battle there.
Beware those beyond here, for they cannot see evil. |
Jack Brimstone
|
Posted - 2005.09.12 19:44:00 -
[17]
All this talk of pickling is making me hungry
But yeah, I'm thinking its time to leave places like Oursulaert too, they have steadily grown in population since the CW patch and last night I didn't feel like undocking as the lag was palpable, even in station.
I dread to think what places like Rens and Jita were like, as historically they have been busier than Ours. |
|
Valar
|
Posted - 2005.09.13 12:06:00 -
[18]
Edited by: Valar on 13/09/2005 12:06:12
Originally by: M3ta7h3ad
300+ in ours last night = about a 2 minute load time at the gate. I was mid insta gang travelling on a mission, and ended up a jump and a bit behind them.
Key systems such as Ours should at least be moved to their own "almost" dedicated server perhaps hosting themselves, and some of the dormant systems.
Ours, Jita, Rens and systems with similar load are on dedicated nodes.
------
Valar
Quality assurance department
CCP games
How to write a good bugreport |
|
Jacob Majestic
|
Posted - 2005.09.13 13:17:00 -
[19]
Edited by: Jacob Majestic on 13/09/2005 13:17:00
Originally by: Valar
Ours, Jita, Rens and systems with similar load are on dedicated nodes.
How many systems in the game are continuously busy? I was thinking about how to address fleet battle lag, and realized that they are probably statistically more likely to happen in systems with conquerable stations. Furthermore, if one system in a region is experiencing a flash crowd, it is probably the case that other systems in the same region are less likely to experience a similar crowd. Therefore, you could distribute conquerable station systems across servers as you distribute known-busy systems -- simply assume that the conq station systems are "potentially busy".
P.S. MS in Computer Science represent!
P.P.S. I <3 Flash Crowds and Python 
|
Raem Civrie
|
Posted - 2005.09.13 13:20:00 -
[20]
During the initial YZ-LQL siege (BoB vs. FA), I didn't notice that much lag in-system despite both sides being in force there. I think systems with stations, both NPC and Conq, already have more resources. But, of course, I have no way to know/prove
---
Is this a constructive thread? |
Jacob Majestic
|
Posted - 2005.09.13 13:26:00 -
[21]
Originally by: Raem Civrie
During the initial YZ-LQL siege (BoB vs. FA), I didn't notice that much lag in-system despite both sides being in force there. I think systems with stations, both NPC and Conq, already have more resources. But, of course, I have no way to know/prove
But you don't exactly need more resources for a 00 NPC station, because it probably has a preductable amount of traffic. For conquerable stations, you are either going to have very low traffic (normal operations) or very high traffic (battle).
|
Avalon Beholder
|
Posted - 2005.09.13 15:01:00 -
[22]
You DO have the ability to shuffle nodes at downtime though obviously.
How difficult to implement would it be to measure the rolling average number of players (or even better, average demand on resources) in system per uptime, and allocate resources each downtime accordingly?
For example, lets say YZ-LQL has 100 people in it for 5 days, during that time as its rolling average tends towards 100, each downtime the resources assigned to YZ- would be increased.
This way systems being used frequently for example for fights, would have resources automatically assigned to them in times of war, and these extra resources would be automatically re-pooled if the area went quiet again.
|
Crusher166
|
Posted - 2005.09.13 15:14:00 -
[23]
Originally by: Avalon Beholder
You DO have the ability to shuffle nodes at downtime though obviously.
How difficult to implement would it be to measure the rolling average number of players (or even better, average demand on resources) in system per uptime, and allocate resources each downtime accordingly?
For example, lets say YZ-LQL has 100 people in it for 5 days, during that time as its rolling average tends towards 100, each downtime the resources assigned to YZ- would be increased.
This way systems being used frequently for example for fights, would have resources automatically assigned to them in times of war, and these extra resources would be automatically re-pooled if the area went quiet again.
That would be good.
Crusher - Arcane Technologies |
|
Valar
|
Posted - 2005.09.13 16:56:00 -
[24]
Originally by: Avalon Beholder
You DO have the ability to shuffle nodes at downtime though obviously.
How difficult to implement would it be to measure the rolling average number of players (or even better, average demand on resources) in system per uptime, and allocate resources each downtime accordingly?
For example, lets say YZ-LQL has 100 people in it for 5 days, during that time as its rolling average tends towards 100, each downtime the resources assigned to YZ- would be increased.
This way systems being used frequently for example for fights, would have resources automatically assigned to them in times of war, and these extra resources would be automatically re-pooled if the area went quiet again.
Our loadbalancing is similar to that.
------
Valar
Quality assurance department
CCP games
How to write a good bugreport |
|
|
Oveur
|
Posted - 2005.09.13 17:42:00 -
[25]
Originally by: Valar
Originally by: Dark Shikari
I was told by Oveur after the servers went up on Help chat that an active node CAN in fact be transferred to another (i.e. Yulai moved to a new node while the server is up), albeit certainly not seemlessly. Does the system allow this, or is Oveur talking out of his arse?
The only way to do this, is to kill the node or maybe with some programmer manipulations end all client sessions in the system and move it over. This is not a functionality thats supported by our framework.
Correct, today we would simply kill the system or the whole node so that the loaded systems would move nodes which capacity to take them.
The "not seamlessly" part of my sentence in help channel is indeed that all clients would get disconnected (or with more support for this, get frozen for some time while the system is being moved).
_____________________________
"There's no reason to become alarmed, and we hope you'll enjoy the rest of your flight. By the way, is there anyone on board who knows how to fly a plane?" |
|
Nick Curso
|
Posted - 2005.09.13 18:00:00 -
[26]
No offence valar but ure one ugly mofo
|
Muthsera
|
Posted - 2005.09.13 18:18:00 -
[27]
Edited by: Muthsera on 13/09/2005 18:21:48
Is there a possibility to create a dedicated "backup server" to boost sertain nodes that is heavily pressured when needed? During fleet encounters and etc?
Edit: I suddenly understood the connection whit what the other was talking about.
SoonÖ
|
Jak'ai
|
Posted - 2005.09.13 18:30:00 -
[28]
I guess the million ISK question would be whether alliances would be willing and interested in the creation of "frontier" regions between all the claimed areas of 0.0. Places where fleet battles are predictable, and which therefore can be allocated hardware resources that allow handling of large scale engagements.
Frontier systems could be mobile, responding to the winning side (territorial domination) but a frontier system would always be dedicated extra resources.
Of course the trade off is that it restricts the FFA fleet PvP possibility (maybe by making it hard/impossible for battleships and capital ships to infiltrate enemy-claimed space) but it would allow large fleet battles without slideshow effects anyway.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |