Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 1 post(s) |
Jim McGregor
Caldari
|
Posted - 2006.08.21 09:53:00 -
[1]
Edited by: Jim McGregor on 21/08/2006 09:56:58
There are many forms of lag in this game. Activation delay on modules, ships not being displayed until the client loads them all etc. What is the main bottleneck preventing things from running smoothly?
Is it the database? The bandwidth? The cluster CPU's? The game engine being old/slow? The load balancing algorithm not being real-time?
Im just curious. Dev response would be nice. :)
--- Eve Wiki | Eve Tribune | Eve Pirate |
Jenny Spitfire
Caldari LoneStar Industries Veritas Immortalis
|
Posted - 2006.08.21 10:04:00 -
[2]
My guesses.
Client not properly optimised. May be inappropriate data structures? Communication protocol between database, servers, clients? Too much logging at server-side? Used to be CPU/Memory issues on nodes before 64-bit upgrades.
I also would like to know. --------- In the blindness, a streak fiery thread violently cuts the horizon. Bleeding golden mists, engulfing the blindness from within. Burning the darkness. The touch of dawn. |
Jaro Koresh
|
Posted - 2006.08.21 10:45:00 -
[3]
cally transfering the isk around....
Begin Coded Transmission . . . I'd say too many people and theyre running closer and closer to thier cap and working to provide more asap but its causing problems like more downtime and thier trying to keep it secret.. OMG.. conspiracy... the coffee... the coffee.. stop the voices ....
End Transmission . . .
heh jk.. dunno..
|
|
Ivan Kirilenkov
Forum Moderator Interstellar Services Department
|
Posted - 2006.08.21 10:55:00 -
[4]
Rumour has it that the Server-Hampsters are suffering from malnutrition because they've constantly been fed "bree" instead of T2 Server-Hampster Food(TM), and are thus acting up.
On a more serious note, hopefully tomorrow's Dragon-code will help improve things a lot. And *DO* remember to set long skills :)
eve-crc.net | forum rules |[email protected] |
|
Jim McGregor
Caldari
|
Posted - 2006.08.21 10:58:00 -
[5]
Originally by: Ivan Kirilenkov Rumour has it that the Server-Hampsters are suffering from malnutrition because they've constantly been fed "bree" instead of T2 Server-Hampster Food(TM), and are thus acting up.
On a more serious note, hopefully tomorrow's Dragon-code will help improve things a lot. And *DO* remember to set long skills :)
I should have mentioned hamster jokes are forbidden in this thread.
And yes, rumour is that Dragon will improve things. But it all depends on what is causing the lag. If its the software, then I guess it can be sorted by new code. However, it seems alot of the problems are related to the database. I wish someone at ccp could talk a little about this so I dont have to do my usual assumptions.
--- Eve Wiki | Eve Tribune | Eve Pirate |
Turiya Flesharrower
Beagle Corp
|
Posted - 2006.08.21 11:04:00 -
[6]
I seriously doubt that it's a problem with bandwidth; more likely it's a problem with distribution code. When you have 400 people in the same grid on the same node, the node simply cannot handle all of the calculations needed to keep everything running smoothly. You've got positional data from hundreds of ships modified with pilot skills and then tracking and probability calculations from weapons fire. ECMs probability calculations, gang mods effect on all gang members also have to be factored in. Even if these calculations are simplified to the nth degree, you're still looking at a ridiculous number of calculations that need to be done. 64-bit server hardware isn't enough for this; 64-bit just means higher memory bandwidth and possibly more efficient calculations in terms of multiplication and division instruction execution.
What's needed is a better way for the load to be distributed across multiple nodes rather than having multiple systems handled on a single node. Right now the load balancing software seems to take in statistics on what nodes are experiencing in week-long or longer timeframes and use that to calculate what systems are on which nodes, thus balancing out the processing needs. What's needed is coding to allow a single system's load to be distributed across multiple nodes; a system like D7-ZAC, C-J or Jita can suddenly spike to 600+ people in local; a way of quickly spreading the load across multiple nodes without disruption is direly needed. Perhaps CCP could purchase a couple of heavy duty blade servers which would sit idle normally but then have high-load systems transferred to them when needed?
Of course, it's all just educated guessing in the end; mostly going by what devs have said in the past and guesses on how the code works based on how the game itself acts. Most of the above it probably impossible to accomplish with existing code for one reason or another. -----
|
Jim McGregor
Caldari
|
Posted - 2006.08.21 11:12:00 -
[7]
I read in a previous thread a while ago that the load balancing takes into account only the day before. So if you have a fleet battle in system XYZ with 300 people, it will lag during the fleet battle, but tomorrow at the same time, the system will have lots of resources it doesnt need (unless there is another fleet battle). I think thats what was said.. im sorry if I didnt understand it correctly, but I think I did. So load balancing is pretty poor right now and not at all dynamic. However, if this was true, then mission systems shouldnt be laggy since they have about the same number of people in them every night. So I guess there is more to it than that.
As for cpu being the limiting factor, well, that should be able to be fixed by buying new hardware. But its really strange, because sometimes the game seems fine to me even when 28k people are logged on. Other times its lagging heavily with only 20k people online.
Maybe the lag is really all about the load balancing.
--- Eve Wiki | Eve Tribune | Eve Pirate |
Blowvelt
|
Posted - 2006.08.21 11:13:00 -
[8]
seroiusly ! I don't know what some people are typing these days ? , I have no lag at-all, it is probably you're crap connection
|
Chewan Mesa
Beagle Corp
|
Posted - 2006.08.21 11:22:00 -
[9]
I think you got that load-balancing-problem right, I also read it takes quite some time before the Systems get their attention, mostly when it fleet-battle is already over.
However isnt the Dragon-Code supposed to improve exactly that, the load-balancing?
|
Archangel Raphael
|
Posted - 2006.08.21 11:24:00 -
[10]
this "lag" issue is certainly a strange issue,, for it appears to affect some ppl and not others within the same system..... for example only 2 days ago in the not so overly populated kaunokka system(roughly 150 ppl),, several ppl were complaining of terrible lag that was preventing them from jumping, reloading, pening cans and so one.. yet myself in obviously the same system, was doin a intensive msn. and if ppl wernt going on about it wouldnt of known. and others also said they wernt suffering either,,, very odd
i got involved with the lag discussion and asked some pretty obvious questions regarding their computers,, there connection speeds there reliability ect ect.. and they all said that they had up to date machines and good isp's ect and low m/s and so on.
|
|
Jenny Spitfire
Caldari LoneStar Industries Veritas Immortalis
|
Posted - 2006.08.21 11:25:00 -
[11]
Originally by: Jim McGregor
As for cpu being the limiting factor, well, that should be able to be fixed by buying new hardware. But its really strange, because sometimes the game seems fine to me even when 28k people are logged on. Other times its lagging heavily with only 20k people online.
Maybe the lag is really all about the load balancing.
Think what Turiya is trying to say is, there are 5000+ systems spread over 70 servers on EvE cluster. You could be in a server that is sharing with 70-100 systems. When you see 20k online, you might feel lag in a system with 5 locals killing each other because there is another system on the same server with a fleet of capital ships killing a POS. The CPU on that server is the limiting factor. Hub systems like Jita wont experience much lag with 400 people because Jita has a server by itself. When Jita hits 700 people then it may hit the limiting factor. This is my guess by the way.
HTH. --------- In the blindness, a streak fiery thread violently cuts the horizon. Bleeding golden mists, engulfing the blindness from within. Burning the darkness. The touch of dawn. |
Jim McGregor
Caldari
|
Posted - 2006.08.21 11:26:00 -
[12]
Originally by: Chewan Mesa I think you got that load-balancing-problem right, I also read it takes quite some time before the Systems get their attention, mostly when it fleet-battle is already over.
However isnt the Dragon-Code supposed to improve exactly that, the load-balancing?
They say they have made optimizations, but no details as to what they are optimizing as far as I know. Patch notes doesnt say anything about load balancing either. --- Eve Wiki | Eve Tribune | Eve Pirate |
Matthew
Caldari BloodStar Technologies
|
Posted - 2006.08.21 11:26:00 -
[13]
Originally by: Jim McGregor And yes, rumour is that Dragon will improve things. But it all depends on what is causing the lag. If its the software, then I guess it can be sorted by new code. However, it seems alot of the problems are related to the database.
Code improvements can ease the load on the database too - strip out rendundant calls, re-order the process to reduce the number of calls needed or change them to less intensive requests etc.
Originally by: Turiya Flesharrower a way of quickly spreading the load across multiple nodes without disruption is direly needed. Perhaps CCP could purchase a couple of heavy duty blade servers which would sit idle normally but then have high-load systems transferred to them when needed?
The problem is that dynamically transferring a system to a new node would need mountains of new code. It would also greatly increase load on both the source and destination node during the transfer - which isn't going to work too well if your source node is already overloading! Spreading a system over multiple nodes can be similarly problematic. While it may be relatively simple to break down a system into grids, and distribute the grids across multiple nodes, that's still not going to help a fleet battle much, because everyone will be in one grid. Spreading that grid across two nodes I'd expect to produce ridiculous amounts of cross-node traffic, with potential for very weird effects if things go wrong or the nodes get out of sync.
Probably falls into the category of theoretically possible, not not practical.
Originally by: Jim McGregor However, if this was true, then mission systems shouldnt be laggy since they have about the same number of people in them every night. So I guess there is more to it than that.
Depends, the main load in mission-running systems probably comes from the combat missions and entities. In the old Lageken, there used to be an average of one NPC destroyed every 2 seconds (based on the map's figures). The sheer churn of mission areas being spawned, cleared etc is going to generate a lot of load. Which is why these agent hubs start lagging with a relatively low number of people in local. IIRC, the loadbalancer ended up putting Lageken on it's own node, and the sheer number of missions being run there still caused it to lag out.
I would imagine a lot of the current agent hubs are in a similar situation, hitting the whole-node capacity limit. Hopefully the clearing out of the horrible old mission code in Dragon will help a bit. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
Jim McGregor
Caldari
|
Posted - 2006.08.21 11:30:00 -
[14]
Originally by: Jenny Spitfire
Think what Turiya is trying to say is, there are 5000+ systems spread over 70 servers on EvE cluster. You could be in a server that is sharing with 70-100 systems. When you see 20k online, you might feel lag in a system with 5 locals killing each other because there is another system on the same server with a fleet of capital ships killing a POS. The CPU on that server is the limiting factor. Hub systems like Jita wont experience much lag with 400 people because Jita has a server by itself. When Jita hits 700 people then it may hit the limiting factor. This is my guess by the way.
HTH.
Yep. I wish the load balancing algorithm was much more dynamic and could assign priorities to systems when needed. Resources would be taken from otherwise free resources, like extra servers, at times when the cpu load is approaching high levels for a node. Basicly it would get some help when it needs it.
Maybe thats what they are aiming for, but it requires alot of heavy work and redesigns to make it happen?
--- Eve Wiki | Eve Tribune | Eve Pirate |
Turiya Flesharrower
Beagle Corp
|
Posted - 2006.08.21 11:31:00 -
[15]
Originally by: Jim McGregor
I read in a previous thread a while ago that the load balancing takes into account only the day before. So if you have a fleet battle in system XYZ with 300 people, it will lag during the fleet battle, but tomorrow at the same time, the system will have lots of resources it doesnt need (unless there is another fleet battle). I think thats what was said.. im sorry if I didnt understand it correctly, but I think I did. So load balancing is pretty poor right now and not at all dynamic. However, if this was true, then mission systems shouldnt be laggy since they have about the same number of people in them every night. So I guess there is more to it than that.
As for cpu being the limiting factor, well, that should be able to be fixed by buying new hardware. But its really strange, because sometimes the game seems fine to me even when 28k people are logged on. Other times its lagging heavily with only 20k people online.
Maybe the lag is really all about the load balancing.
Apparently they can change the load priorites on a node instantly but it causes one or two peripheral problems. Since the load is spread fairly evenly across nodes, the number of people online concurrently won't affect overall performance unless it reaches a very high level; perhaps 35-40k. Even if a huge number of people are online, it may not necessarily affect the node that you're on to any real extent.
As to CPU being the limiting factor, I still think that it's the primary issue for fleet battles. When you're flying through Jita on autopilot, there's relatively little going on in terms of calculations. When you're opening fire on someone while aligned or maneuvering then that's causing a lot more of a load. You'll also notice a huge slowdown during session changes (jump-ins and ship/pod destruction) which contributes in no small part to the overall lag. The database transactions triggered by a ship's destruction cause slowdown; when people are exploding every 5 seconds it causes a lot of slowdown. Then you have other transaction triggers such as ammunition use, drone loss due to warp-outs, can drops, ammunition degradation (Tech II/faction crystals), loot pickups, can destruction, pod destruction, the list goes on and on. Even with the RAMSAN in place, that's atill a lot to handle. -----
|
Bulletproof Cupid
Euphoria Released Euphoria Unleashed
|
Posted - 2006.08.21 11:32:00 -
[16]
Edited by: Bulletproof Cupid on 21/08/2006 11:33:45 double post
|
Bulletproof Cupid
Euphoria Released Euphoria Unleashed
|
Posted - 2006.08.21 11:32:00 -
[17]
Originally by: Ivan Kirilenkov And *DO* remember to set long skills :)
Why? are you not confident the server will be up when stated?
bp x
|
Turiya Flesharrower
Beagle Corp
|
Posted - 2006.08.21 11:38:00 -
[18]
Edited by: Turiya Flesharrower on 21/08/2006 11:39:16
Originally by: Matthew
The problem is that dynamically transferring a system to a new node would need mountains of new code. It would also greatly increase load on both the source and destination node during the transfer - which isn't going to work too well if your source node is already overloading! Spreading a system over multiple nodes can be similarly problematic. While it may be relatively simple to break down a system into grids, and distribute the grids across multiple nodes, that's still not going to help a fleet battle much, because everyone will be in one grid. Spreading that grid across two nodes I'd expect to produce ridiculous amounts of cross-node traffic, with potential for very weird effects if things go wrong or the nodes get out of sync.
Probably falls into the category of theoretically possible, not not practical.
I'd say it depends on the underlying code and hardware; blade server clusters are particularly well-suited to this kind of task. Distributed systems are a complete and utter bastard to code but the speed benefits are very much apparent. In this case we have a partially distributed system in that the entire galaxy is distributed across multiple nodees. However the smallest unit in this equation is a single grid or system and it's often a unit of just that size that needs to be distributed even further. The problem is that game dynamics make it very difficult to even code in appropriate distribution triggers without human intervention.
For example, we might think that distribution should be triggered by session changes (jump-ins and clone jumps etc) so that every 10 additional people entering a system should further push the load out across mutliple nodes. At furst glance this seems like a reasonably good idea. Once you look into a typical scenario though, it all turns to crap; entire fleets jumping into opposing gate camps in order to engage. Suddenly you're triggering multiple load distribution functions and the whole system ****s itself over and over again. I seriously pity the programmers who have to work on these problems. -----
|
Matthew
Caldari BloodStar Technologies
|
Posted - 2006.08.21 11:38:00 -
[19]
Originally by: Jenny Spitfire Hub systems like Jita wont experience much lag with 400 people because Jita has a server by itself. When Jita hits 700 people then it may hit the limiting factor. This is my guess by the way.
While Jita being on it's own node does help, there's also a dependancy on what's being done. Generally you don't find POS-killing blobs or 200 Level 4 missions being run simultaneously in Jita.
People in Jita seem to generally be there for the trade, so they're flying quietly, or docked up. Even at the popular gates/stations you don't usually get blobs of over 50 at a time. It's this quieter activity that allows Jita to cope with large numbers of players. If you got the whole population of jita to warp to the same grid, you'd soon find out that the jita node isn't any better than any of the others.
Originally by: Jim McGregor They say they have made optimizations, but no details as to what they are optimizing as far as I know. Patch notes doesnt say anything about load balancing either.
While it's not in the patch notes, several dev posts have touched on changes to the load balancing. From what they've said, I suspect that the loadbalancer is getting a tweak so it can take into account the stability of load, not just the raw load value. If it can do that, then it can redistribute the "spare" capacity in favour of the systems that are most likely to need it. Right now, the "spare" capacity is shared across all nodes (and thus all systems) evenly.
However, if you can identify that system X has shown within 5% of the same load for the last 3 weeks, but system Y sees 500% fluctuations, it's fairly safe to reduce the "spare" margin given to X, and give a bit more to Y. Which should help it cope better with the dynamic loads like fleet battles. Though it still won't help the battles big enough to bring an entire node to it's knees on it's own. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
Jenny Spitfire
Caldari LoneStar Industries Veritas Immortalis
|
Posted - 2006.08.21 11:38:00 -
[20]
Originally by: Turiya Flesharrower
Originally by: Jim McGregor ...
...
When I think about this, EvE cluster codes will make any programmer eyes' bleed. x.X --------- In the blindness, a streak fiery thread violently cuts the horizon. Bleeding golden mists, engulfing the blindness from within. Burning the darkness. The touch of dawn. |
|
Turiya Flesharrower
Beagle Corp
|
Posted - 2006.08.21 11:40:00 -
[21]
Originally by: Jenny Spitfire
Originally by: Turiya Flesharrower
Originally by: Jim McGregor ...
...
When I think about this, EvE cluster codes will make any programmer eyes' bleed. x.X
Damn straight. -----
|
Amarria Lightwielder
N.A.G.A Corporation
|
Posted - 2006.08.21 11:42:00 -
[22]
something i really hate is the "lag" for the right click menu :( and bookmarks :s
NAGA ShopÖ
|
Jenny Spitfire
Caldari LoneStar Industries Veritas Immortalis
|
Posted - 2006.08.21 11:43:00 -
[23]
Originally by: Matthew
Originally by: Jenny Spitfire Hub systems like Jita wont experience much lag with 400 people because Jita has a server by itself. When Jita hits 700 people then it may hit the limiting factor. This is my guess by the way.
Even at the popular gates/stations you don't usually get blobs of over 50 at a time. It's this quieter activity that allows Jita to cope with large numbers of players.
I dunno but I have a feeling blob lag is also caused by client side and not server side alone i.e. overview codes, unresponsive client, etc. People and places falls under this category. Many things get loaded on overview but filters only show what you want to see. Overview contributes a large percentage to client lag, IMHO. --------- In the blindness, a streak fiery thread violently cuts the horizon. Bleeding golden mists, engulfing the blindness from within. Burning the darkness. The touch of dawn. |
Jenny Spitfire
Caldari LoneStar Industries Veritas Immortalis
|
Posted - 2006.08.21 11:44:00 -
[24]
Originally by: Turiya Flesharrower
Originally by: Jenny Spitfire
Originally by: Turiya Flesharrower
Originally by: Jim McGregor ...
...
When I think about this, EvE cluster codes will make any programmer eyes' bleed. x.X
Damn straight.
I get turned on though. Hehe. --------- In the blindness, a streak fiery thread violently cuts the horizon. Bleeding golden mists, engulfing the blindness from within. Burning the darkness. The touch of dawn. |
Matthew
Caldari BloodStar Technologies
|
Posted - 2006.08.21 11:44:00 -
[25]
Originally by: Turiya Flesharrower Apparently they can change the load priorites on a node instantly but it causes one or two peripheral problems.
The least of those "peripheral problems" being that everyone in that system gets kicked from the server while the system moves nodes. From the way the dev's were talking, I get the feeling the manual override is a fairly brutal procedure (wouldn't surprise me if it's just forcing the node to "crash" so that the systems get re-mapped). That sort of thing is going to have a knock-on effect for the load of the entire cluster, so I can see why they refuse to do it. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
Tarn Star
Gallente Eve University
|
Posted - 2006.08.21 13:31:00 -
[26]
Originally by: Blowvelt seroiusly ! I don't know what some people are typing these days ? , I have no lag at-all, it is probably you're crap connection
Well, I live in London, and am like 8 jumps to the cluster. I get anything between 12 to 30 ms ping times consistently, but also get lag, consistently.
After giving it some thought, I believe the breakdown would be, in Lag creating ability, in descending order
1. Software Client - got more than 500 Bookmarks? Passing the data to the screen seems to lock up the client. Ever been in a fleet battle? That lag spike when you warp in, pay attention to your hard drive light. Working hard isn't it? LetĘs see how the new Dragon code performs...
2. Resources available to system you are in. - Jita hold 500 regularly, and does not lag as hard as systems with 30. Why? Cluster Resources available to the system you are in. CCP have stated that the priorities on load balancing are down each DT, but a lot of good that does us when we need it eh?
4. Database Issues - Everything from Design, configuration, hardware, and connections. Can be difficult to get right, but with the upgrade to RamSan-400 solid state drives, that provide 3 GB/s random sustained bandwidth, this issue was reduced. But we still do see issues that relate to database problems, and we have seen a lot of unscheduled DT lately due to database problems.
5. Client PC - Bit of a given that if you have a crappy PC, you are going to lag. But, even if you upgrade your PC, you will still lag due to the first 2 points.
6. Cluster Internet Bandwidth - Unlikely, as this can be easily fixed. I'm sure that this is monitored very closely.
6. Cluster Internal Configuration - As we have very limited information about this, and I'm sure that with the significant investment in infrastructure that has recently occurred, that this is not a game breaking issue. As it does relate to Point 2, the only thing that could be improved is the addition of servers that manage systems, so that the load is then spread out over a greater amount of processing hardware. But don't forget, it already has a Supercomputer ranking, and is already running 150 IBM eServer xSeries and BladeCenter servers. Also includes as previously mentioned for the database RamSan-400 solid state drives, which provide 3 GB/s random sustained bandwidth.
So, as you can see, I believe that CCP are addressing the worst lag creating components in this game in the correct order.
Tarn
No Sig Here, move along....
How did that get there!?!?
|
PeeWee Pee
|
Posted - 2006.08.21 13:36:00 -
[27]
simple, too many carebears taking up da cluster mission whoring macro mining farming the brains out of regions. |
HippoKing
Caldari Beagle Corp
|
Posted - 2006.08.21 13:39:00 -
[28]
The new CCP space program
|
Twilight Moon
Minmatar eXceed Inc. Ascendant Frontier
|
Posted - 2006.08.21 13:39:00 -
[29]
Originally by: PeeWee Pee simple, too many carebears taking up da cluster mission whoring macro mining farming the brains out of regions.
Those "carebears" pay their subscription to do what they like in game, same as everyone else.
...on the other hand using a banana might be a viable alternative.
|
Jim McGregor
Caldari
|
Posted - 2006.08.21 13:40:00 -
[30]
Originally by: HippoKing The new CCP space program
/me thinks hamster jokes needs replacement for aging reasons. :)
--- Eve Wiki | Eve Tribune | Eve Pirate |
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |