Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Iasius
|
Posted - 2006.08.06 20:47:00 -
[1]
Edited by: Iasius on 06/08/2006 20:49:42 I am part of Lokta Volterra alliance. We are fighting against Red Alliance in C-J6MT. When there are more than 200+ people in system the whole game for all of us lags to death. Which is not good for us the pan alliance force trying to take the system.
CCP have put decent hardware in place but i really think the software writtin in PYTHON!! that is the problem. And it seems after several years and we still have to have a hour of downtime at least every day that the Server software is -fundamentally- not good enough.
So go for a platform that has low TCO and is proven. And that is IBM PSeries servers running AIX 5.x. Its the best platform period. And program it in C that is great at handling flexible memory structures and stacks.
Can CCP claim that we are on a road where in the near future we can play EVE to its fullest without lag? To the fullest means we can have 400+ ships in a system being active.
|
Dark Shikari
Caldari Imperium Technologies Firmus Ixion
|
Posted - 2006.08.07 10:51:00 -
[2]
Edited by: Dark Shikari on 07/08/2006 10:51:58
Python is written in C
P.S. Stackless python is vastly superior to C in terms of usability and speed when dealing with millions of threads. Coding C the same way to deal with the EVE servers would be a complete nightmare.
--Proud member of the [23]--
-WTS Heavy Electron II, 100mn AB II |
Iasius
|
Posted - 2006.08.07 11:48:00 -
[3]
Ah right didnt know that heh. But still why is the EVE cluster so flakey?
|
Sevarus James
Minmatar Meridian Dynamics
|
Posted - 2006.08.07 12:59:00 -
[4]
Edited by: Sevarus James on 07/08/2006 13:03:00 If you mean why are you experiencing fleet lag, then the answer has more to do with the client than it does with the cluster. The client is forced to "draw" everything in system iirc whether you actually see or interact with the objects or not.
This is what causes massive lag in the battles, the client struggling to do more than it should. CCP's re-write for kali should by their accounts (at the fanfest last year) get rid of a lot of this.
The actual data that transfers between the eve cluster and the client is at best a tiny amount of information compared to a lot of client server systems.
If you are referring to the actual cluster instability that has been seen recently, the most frequent item that has come up that I've read is "transaction logs".
As I work in an environment at IBM supporting among other things, "middleware", about 90% of the problems we see with database interactivity and performance are associated with transaction logs filling available disk space. When this happens things start thrashing...badly. And that has happened on tranquility at least a few times recently.
The fix is very simple...shrink, delete or move the logs to clear disk space. viola things get smooth again.
As EVE is VERY database centric, this is an ongoing problem as things get "bigger".
p.s. As I work at IBM, I have to agree with you on the AIX bit, simply from loyalty. Actually if I were going to go to a 'nix based platform, I'd actually go linux for the cost savings.
CCP is a chestnut in microsoft's cap though. The fact that they are using MS SQL and doing it in a game of this size is impressive...considering my distaste for most of MS's products.
The funny thing is that they are doing it with IBM GEAR. Now if only my compatriots in sales could swing CCP the REST of the way away from the dark side...I'd be happy. ----- ------------
Updated Linux Desktop+EVE+EVE-TV |
Azuriel Talloth
M. Corp Lotka Volterra
|
Posted - 2006.08.07 15:24:00 -
[5]
Originally by: Sevarus James Edited by: Sevarus James on 07/08/2006 13:03:00 If you mean why are you experiencing fleet lag, then the answer has more to do with the client than it does with the cluster. The client is forced to "draw" everything in system iirc whether you actually see or interact with the objects or not.
The loading time when warping into a heavily populated grid is client lag, but things like module activation delay, jump-in delay are surely a serverside issue?
CCP Please rename "Warp Disrupt Probes" to "Interdiction Spheres", thanks! |
Sevarus James
Minmatar Meridian Dynamics
|
Posted - 2006.08.07 22:11:00 -
[6]
Originally by: Azuriel Talloth
Originally by: Sevarus James Edited by: Sevarus James on 07/08/2006 13:03:00 If you mean why are you experiencing fleet lag, then the answer has more to do with the client than it does with the cluster. The client is forced to "draw" everything in system iirc whether you actually see or interact with the objects or not.
The loading time when warping into a heavily populated grid is client lag, but things like module activation delay, jump-in delay are surely a serverside issue?
this has been gone over in general forums many times, and again, iirc, the REASONS for module activiation and jumpin delay are mostly due to the client trying to DRAW 50 zillion things in the system in question at the same time as the client is being manipulated by the user. --in the case of a fleet battle.
I've had absolutely no issues (personally) jumping into 150-250 populated systems such as rens/jita/oursalaert/gelfiven on many occasions. While not 400 populated, this isn't "nothin". If the module delay jumpin problems happen frequently, this 'could' be isp related rather than server side. I'm not saying that things are perfect on server side, just from 3 years experience with a good ISP I'm not seeing normal activity problems as some folks are.
This of course is when tranquility is not having issues such as the transaction log problems recently documented.
----- ------------
Updated Linux Desktop+EVE+EVE-TV |
Dark Shikari
Caldari Imperium Technologies Firmus Ixion
|
Posted - 2006.08.08 01:54:00 -
[7]
Edited by: Dark Shikari on 08/08/2006 01:54:34
Originally by: Sevarus James
Originally by: Azuriel Talloth
Originally by: Sevarus James
If you mean why are you experiencing fleet lag, then the answer has more to do with the client than it does with the cluster. The client is forced to "draw" everything in system iirc whether you actually see or interact with the objects or not.
The loading time when warping into a heavily populated grid is client lag, but things like module activation delay, jump-in delay are surely a serverside issue?
this has been gone over in general forums many times, and again, iirc, the REASONS for module activiation and jumpin delay are mostly due to the client trying to DRAW 50 zillion things in the system in question at the same time as the client is being manipulated by the user. --in the case of a fleet battle.
No, that has absolutely nothing to do with it at all.
When the client says "attempting to activate module" or whatever and it takes 1 minute, you could very well be going at 100+ FPS. Its because the server's CPU usage is at max, and all the commands get backed up.
You can play fine in Jita because Jita is mostly full of people who are either alone in missions or sitting in stations, using very little server CPU power. When you have a fleet battle of 100 vs 100, the CPU usage is so massive on the server that anyone in the system, even at a safespot, will get horrible lag.
--Proud member of the [23]--
-WTS Heavy Electron II, 100mn AB II |
Sevarus James
Minmatar Meridian Dynamics
|
Posted - 2006.08.08 04:06:00 -
[8]
thus the "iirc" before saying anything. However, cpu usage thru the roof with 100 vs 100 was 'raposedly' fixed with the new blades. Of course we all know that issues with client AND server are still not where they should be.
ty for the info on that DS. ----- ------------
Updated Linux Desktop+EVE+EVE-TV |
Wilfan Ret'nub
Singularity.
|
Posted - 2006.08.10 12:13:00 -
[9]
CPU usage for 100 vs 100 might well have been "fixed", but we then moved on 200 vs 200 ...
|
Blue Wraith
|
Posted - 2006.08.10 19:55:00 -
[10]
Originally by: Sevarus James
this has been gone over in general forums many times, and again, iirc, the REASONS for module activiation and jumpin delay are mostly due to the client trying to DRAW 50 zillion things in the system in question at the same time as the client is being manipulated by the user. --in the case of a fleet battle.
I've had absolutely no issues (personally) jumping into 150-250 populated systems such as rens/jita/oursalaert/gelfiven on many occasions. While not 400 populated, this isn't "nothin". If the module delay jumpin problems happen frequently, this 'could' be isp related rather than server side. I'm not saying that things are perfect on server side, just from 3 years experience with a good ISP I'm not seeing normal activity problems as some folks are.
This of course is when tranquility is not having issues such as the transaction log problems recently documented.
In a system with only 30 people, I experience some pretty extreme module delay when the server is at high load. I'm pretty sure this has everything to do with the server being bogged down and nothing to do with the client, since this system is normally not laggy with up to 60 people in it. The only difference was the nearly 27k people that were on at the extremely lagged time (module activation, undocking, etc.), versus the 15-18k people that are on at non-lagged times.
Blue Wraith
|
|
Dark Shikari
Caldari Imperium Technologies Firmus Ixion
|
Posted - 2006.08.11 23:30:00 -
[11]
Originally by: Sevarus James thus the "iirc" before saying anything. However, cpu usage thru the roof with 100 vs 100 was 'raposedly' fixed with the new blades. Of course we all know that issues with client AND server are still not where they should be.
ty for the info on that DS.
The big issue is that the 0.0 systems are still on nodes with empire systems.
Thus Jita no longer lags, but big fleet battles still do.
--[23] Member--
Originally by: DB Preacher The only time BoB's backs are to the wall is when Backdoor Bandit is in local.
|
Sevarus James
Minmatar Meridian Dynamics
|
Posted - 2006.08.12 04:41:00 -
[12]
I hear ya DS. Went back wit' da handy dandy search function and caught up on some of the issues.
Here's to hoping that even this new unicode dragon branch will help out some. (optimizations to both client AND server).
Of course I may have to wait to see that, as currently that branch kills cedega. Oh well, we shall see. ----- ------------
Updated Linux Desktop+EVE+EVE-TV |
Kaylana Syi
Minmatar The Nest
|
Posted - 2006.08.18 06:42:00 -
[13]
AIX... what database on gods green earth would you want EVE to run on? DB2 or Oracle? EVE would have never been able to go live with TCO and paying the database guys to keep them happy.
Team Minmatar Carriers need Clone Vats
|
swoj
The New Order.
|
Posted - 2006.08.23 17:22:00 -
[14]
IMO, the idea that changing to a different OS would suddenly fix server load and lag issues is a falacy.
Different server platforms do offer some advantages and disadvantages over others but I would not expect one to offer any great difference on equivalent hardware. As 99% of the processor load will be from the actual Eve server software developed by CCP (ignoring the DB server just now), implementing it on a different OS would not be likely to contribute much to performance.
As it is, the game is probably better for running on the Window OS, primarily because the developers can develop on the client and server sides with a common OS interface - making it much easier for staff to be reallocated to client or server sections of code (if that was required).
As far as I am aware, the allocation of systems to server nodes is a relatively static setup, this is the main cause of the lag that is experienced in 0.0. Jita is fine with the hundreds of players in it at once because it has a node to itself, and much of empire space will be allocated based on standard patterns of usage of each system. However in 0.0 the usage of some systems is fairly unpredictable, so a 0.0 system that has had little traffic for months will be on a node where it is not expected to take up too much processing time, so when 400 ships arrive all at once, things go pear shaped if the other systems on the node are also needing processing time (big empire alliance Ice op in progress?).
The real solution to the lag problem will be the dynamic allocation of systems to nodes based on load but I wouldn't expect that to happen any time soon, I imagine that this would be very difficult to implement reliably and without cause massive lag to a system being moved to another node.
As for the downtime, database maintenance is essential as Eve, particularly with its market structure, is very data intensive. Things like transaction logs are just an inevitability when a robust database platform is required, the alternative is not to have transaction logs and end up losing hours worth of data if there is a server crash.
Anyway, that's my contribution :)
|
Kweel Nakashyn
Minmatar Aeden
|
Posted - 2006.08.25 16:46:00 -
[15]
Edited by: Kweel Nakashyn on 25/08/2006 16:48:19
Originally by: Sevarus James (...) The fact that they are using MS SQL and doing it in a game of this size is impressive...(...)
IBM + DB2 v8 should be my choice too... MS SQL is slow as hell on big db :) /me works just between a middleware and a db (guess on which mf ? an IBM :p)
|
Weps
Azule Wolves
|
Posted - 2006.08.26 23:22:00 -
[16]
Originally by: Dark Shikari
Python is written in C
P.S. Stackless python is vastly superior to C in terms of usability and speed when dealing with millions of threads. Coding C the same way to deal with the EVE servers would be a complete nightmare.
This one had me thinking for like 5 minutes... I doubt the speed thing tho (as in performance).
|
Xianthar
Sha Kharn Corp Ascendant Frontier
|
Posted - 2006.08.30 05:44:00 -
[17]
better load balencing and removing exploit lag (bookmarks) are the biggest issues. fleet engagements are fine when CCP knows about them ahead and gives a dedicated node (look at EC-). the biggest improvements that could be made to the cluster right now(IMO) are to redo BM's in a more reasonable manor and to recode the load balencer so that is can divert cpu power when needed more efficiently. the former is much easier than the later i'm sure. simply removing BM's around gates really won't help, it would greatly decrease the number of BM's in the game but would have no effect on the exploiters. 5000 copys of a SS bm lag as much as 5000 copies of a g2g bm.
if the server could dynamically give a system an entire CPU when local hits 200 from its normal 10 and there were no longer lag exploits all would be fine.
of course you can just throw more blades at too, theres what 5000 systems in eve, get 5000cpu's in the cluster and you remove the need for a load balencer :P
i highly doubt the language used has much of any impact on the game...
-xian
|
Weps
Caldari Provisions
|
Posted - 2006.08.31 15:39:00 -
[18]
Well, i'm not sure, but it seems to me that if u copy N bookmarks (or move N items into another container, or reprocess N items) that for each item one single c-s transaction occurs. They could definitly do that better (1 transaction per command).
Of course the downside would be that if implemented, everyone starts to copy bm's by the thousands.....
|
Karador
Legionari
|
Posted - 2006.09.01 08:28:00 -
[19]
You seem to forget one thing. EVE is an almost 4 years old game by now. And I'm talking about relase: the core itself is WAY older than that. CCP started business in 1997, with a capital of around $2.6 million. At that time, a MS SQL license for multiple CPU was MUCH lower than what Oracle or IBM where offering. And now, after 7 years, migrating from one platform to another would be too much of a risk. Why do you think that most of your online banking still runs on AS400?...
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |