| Pages: [1] 2 3 :: one page |
|
|
| Author |
Topic |
Arna Padrona
Amarr
Viziam
    |
Posted - 2008.08.12 21:00:00 -
[1]
OK... We don't have any direct ship control - only orders that can be delayed by seconds without disrupting the game. We have no hit/miss stuff here. Apart from the drones, structures and ships themselves - there's no collission detection whatsoever in eve. Missiles used to avoid objects... but that's gone too now.
My question here is... Without much collision detection going on, and without much data input needed from every client - and a fairly limited amount of data received by our clients ( no realtime updates, just give the enemy ship location and the last orders the ship received, and we can extrapolate the ship movements until the server says something changed )... What the heck is causing all the lag?
I remember playing several FPS games with 60 people on one server, with full manual control, constantly updated, with 100% collission detection on EVERYTHING... and that was still fast.
What the heck is causing to servers to go belly-up every time a 30 man fleet jumps into another 30 man fleet? what does the server DO? Clearly, it's completely overwhelmed, but why? What is all the power used for? It can't be the weapons... simple math there, and nothing that increases load exponentially relative to the number of ships.
Did someone seriously muck up what little collision detection algorithms eve has or something? I simply can't understand what is eating up so much processor power that the servers can't cope with 60 people.
I mean... the problems only seem to appear when there a lot of ships in the immediate *vicinity* of each other - so it must be something in the ship-ship interaction that is completely borked, but what? What's causing the massive load times when jumping - how much data is there really to transfer from the server if it's done properly?
 |
Matalino
Gallente
Ki Tech Industries
|
Posted - 2008.08.12 21:16:00 -
[2]
 Originally by: Arna Padrona
It can't be the weapons... simple math there
I wouldn't call the turret chance to hit math "simple", but I don't know how much it contributes to lag.
It is also diffucult to say how much lag is generated at the database, node, proxy, network, and client levels.
How do you conclude that the problem is on the node?
|
Arna Padrona
Amarr
Viziam
|
Posted - 2008.08.12 21:40:00 -
[3]
Edited by: Arna Padrona on 12/08/2008 21:44:21
Originally by: Matalino
Originally by: Arna Padrona
It can't be the weapons... simple math there
I wouldn't call the turret chance to hit math "simple", but I don't know how much it contributes to lag.
It is also diffucult to say how much lag is generated at the database, node, proxy, network, and client levels.
How do you conclude that the problem is on the node?
Well, weapons: Simple, is relative. Complicated math perhaps, but computers are very quick. Shove the velocity vectors, sig radiuses, tracking speeds, etc into a formula and poof, you got an answer. If 30 vs 30 fleets should lag out because of the weapon calculations - why don't three 10 vs 10 fleets in one system lag the node down? There's no collision detection on weapons, so it shouldn't matter whether the guns are fired near other ships or not (save to send a few bytes of data indicating that ship ID-X fired GUNTYPE-Y at ship ID-Z.
How do I know it's at the node? Well, deduction really. When entire fleets lag out, regardless of their computers, connection speeds and locations - you have to assume the problem is on CCPs end. A player in space isn't that much data to deal with really. Ship type and stats, attached guns, direction and speed... We don't need to receive the player's skills, or even the enemy's exact fittings (unless we see them displayed on the ship model). It shouldn't take many kilobytes to transmit everything a client needs to see another ship, unless something is done very inefficiently.
I've noticed no change in load times when I've upgraded my broadband connection either so... another deduction. I suppose I could monitor my netwrk traffic, but I'm pretty confident I won't see any sudden massive data transfers.
Also, the lag is not predictable. At times you CAN jump a 30 man fleet quickly into another 30 man fleet. Other times, you get 30 people slowly, slowly trickling through the stargates - and it's something everyone experiences as a good or bad jump. With voice coms these things become very clear. It's rare for one person to lag. It's common the everyone or no one lags. It seems to hit everyone evenly during jumps.
So is this all one the node, database or proxy? No idea. Don't know. While clients experience lag, drop in fps, network issues and so on - anything that everyone experiences as something out of the ordinary clearly has to be a problem somewhere in CCPs computer cluster. I don't believe it's CCPs network conenction either. Why would 60 people in a fleet lag out and the remaining 20,000 people feel fine? No - has to be at least connected to that specific node somehow, but I of course can't say where in the chain the problem is.
It does seem to me like ships in close proximity to each other, especially interacting with eachother, is causing the problems. All makes me wonder what on earth is going on behind the scenes in the server. Of course, with more ships nearby each other, all the relevant data of what's going on with all the ships around you has to be sent to more people - giving you an exponential increase in data that must be transferred from the servers. The data that needs to be calculated though should only increase exponentially with the number of nearby ships for area-of-effect weapons -bursts, smartbombs and such- and collision detection.
I dunno... It's all just weird, waiting for minutes on end to activate a plain module, basically locking dozens of players dead in the water. Just hoping someone at ccp knows anything, and hopefully can kick someone up the back side to take care of the stuff.
|
Matalino
Gallente
Ki Tech Industries
|
Posted - 2008.08.12 22:16:00 -
[4]
Edited by: Matalino on 12/08/2008 22:19:14
Originally by: Arna Padrona
Well, weapons: Simple, is relative. Complicated math perhaps, but computers are very quick. Shove the velocity vectors, sig radiuses, tracking speeds, etc into a formula and poof, you got an answer.
Relative, yes. Poof, no. There is a reason that CCP has made efforts to reduce the number of calculations needed. Doubling the damage and halving the rate of fire of drones is just one example of something done specificly because of the complexity of these calculations. Originally by: Arna Padrona
If 30 vs 30 fleets should lag out because of the weapon calculations - why don't three 10 vs 10 fleets in one system lag the node down?
I would cite that as a reason why it is less likely to be the node.
If the node was running out of CPU, one would expect the lag to be the same even if the work load were distributed across several grids.
However, lag is most notable when everything is on the same grid.
This is also true when interacting with NPC's, which has been a driving force in CCP's efforts to reduce the number of NPC's on grid at anyone time. Thus we see more missions with staggered waves of NPC's and fewer swarms. Originally by: Arna Padrona
Lots more stuff
While you seem to draw the conclussion from these observations that the node must be to blame for shared lag, the same observations would incline me to believe that the internet connection, or possibly the proxy is to blame.
Having lots of stuff on the same grid, will force the transmission of alot of data to the client.
The reasoning being that Eve is built on TCP. As key feature of TCP is gaurenteed delivery of the data stream. The problem with that "gaurenteed" delivery is that packets must be processed in their proper order.
Basicly the problem that arises is that as the stream of data goes faster, the significance of lost/delayed packets becomes far greater. This effect can even reach a point of capping the potential bandwidth of a single TCP stream fair below the potential bandwidth available.
While the bandwidth used by Eve does not approach these limits, this effect could become profound in terms of effective latency. The more data that is transmitted the worse the latency would become. Your longest ping times begin to override your average ping times as an accurate measure of performance.
Once the server attempts to send you some information, it cannot reprioritize what it is sending if there are any delays in the confirmation of transmission.
This is only sepeculation, but it might be interesting to annalize the health of the TCP stream when you experience significant lag, as you could very easily have an appearently good internet connection, but if the wrong packets go missing or are delayed, you would experience significant lag.
This cause of lag is interesting in that it fits a common observation that I have seen with Jita: some people lag out completely to the point of crashing, while others are some how able to cope.
While Jita certainly strains the node server, that strain should be equally felt by all those on the node.
With actions such as searchs in People and Places, you can see this strain as the server attempts to fill a request that is demanding on the server, but places no significant strain on the client or network connection. However, these actions seem to have a more universal effect for all players on that node.
With actions such as undocking, or otherwise loading a grid, you more commonly see the variable experiences ranging from moderate load times to complete death of the connection. This variablity is consistant with the above described limitation of TCP connections.
Of course I am only sepeculating, but I might adventually get around to actually testing such a theory.
|
Ix Forres
Caldari
Vanguard Frontiers
Imperial Republic Of the North
|
Posted - 2008.08.12 22:28:00 -
[5]
Surely to some extent this has to do with the locking model CCP employs at the database level or at the app level?
That'd be where I'd be looking in terms of faultfinding for this kind of lag- it's gotta be DB or node level rather than game logic (sol) level.
--
Ix Forres
EVE Application Developer
ISKsense | RLS-EVE | Blog |
Arna Padrona
Amarr
Viziam
|
Posted - 2008.08.13 01:17:00 -
[6]
Quote:
Relative, yes. Poof, no. There is a reason that CCP has made efforts to reduce the number of calculations needed. Doubling the damage and halving the rate of fire of drones is just one example of something done specificly because of the complexity of these calculations.
The only drone adjustment I was aware of was cutting the number of drones to half, and doubling up the damage output - and that's something completely different, as drones are subject to collision detection.
Still, you may be right that the drones have had rate/damage adjusted - and for good reason, as engagements can include more than 5 times the number of drones as there are ships. With high refire rate, it's un un-necessary strain on the overloaded servers, and every bit helps - especially since under less than ideal conditions, the number of shots fire by drones may outnumber the "real" shots fired, and probably by a lot...
Quote:
I would cite that as a reason why it is less likely to be the node.
If the node was running out of CPU, one would expect the lag to be the same even if the work load were distributed across several grids.
However, lag is most notable when everything is on the same grid.
Interesting, and very good point. It does lead the mind to believe it's something to do with the data transfer.
Still, I have seen fleet battles lag down nodes so bad, that you can barely move several systems away. Proceeding to one cap fight, it took my fleet 1 hour to move the last 4 jumps to the system in question.
Quote:
This cause of lag is interesting in that it fits a common observation that I have seen with Jita: some people lag out completely to the point of crashing, while others are some how able to cope.
While Jita certainly strains the node server, that strain should be equally felt by all those on the node.
I see this quite a bit too, individuals lagging out on their own.
What really perks my interest though is that in the fleet engagements I've seen - it's an all or nothing deal. Either we all lag out and die, or (virtually) no one does.
I've jumped into hostile fleets many times, and either we all come through safely and engage, or we all just sit there, staring at the stargate, and the conversation goes:
-"I think I lagged out."
-"Yeah, me too."
-"Uh-huh. Crashed the node or something."
-"Anyone through yet?"
-"Nope."
-"Well, lemme know."
-"We are gonna die when we start trickling through one by one..."
-"Yeah. Make the best of it. Hold your cloaks as long as possible."
-"Anyone though yet?"
It's a mess. I'm hoping CCP are doing something about it, as war is currently not possible to partake in. I'm just curious as to what the problem is.
|
|
CCP Lingorm
C C P
|
Posted - 2008.08.13 09:39:00 -
[7]
I can't go into all the details, because I do not know all of them, but here are some of the calculations that needed to be calculated every time period on a grid in combat.
Travel vectors and collisions. We need to calculate the space ship will occupy while traveling and then see if any other ships intersect/collide with this.
Transversal velocity. We need to know your velocity in respect to other ships on the grid for calculating hit chances and such.
Hit and damage calculation.
Missile and drone travel paths (these are non collision object so collisions do not need to be calculated). Missile terminal maneuvers.
Ship status/effect changes (turning modules on and off, auto reactivation, capacitor, dmg resists, repair, boosting, webbing, scrambling, jamming etc).
So as you can see it is not a trivial set of tasks.
Please remember that this is not a complete list and a basic description of the process but it gives you an idea of what is done.
CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader
Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
Arna Padrona
Amarr
Viziam
|
Posted - 2008.08.13 12:03:00 -
[8]
Originally by: CCP Lingorm
I can't go into all the details, because I do not know all of them, but here are some of the calculations that needed to be calculated every time period on a grid in combat.
Travel vectors and collisions. We need to calculate the space ship will occupy while traveling and then see if any other ships intersect/collide with this.
Transversal velocity. We need to know your velocity in respect to other ships on the grid for calculating hit chances and such.
Hit and damage calculation.
Missile and drone travel paths (these are non collision object so collisions do not need to be calculated). Missile terminal maneuvers.
Ship status/effect changes (turning modules on and off, auto reactivation, capacitor, dmg resists, repair, boosting, webbing, scrambling, jamming etc).
So as you can see it is not a trivial set of tasks.
Please remember that this is not a complete list and a basic description of the process but it gives you an idea of what is done.
Thank you. All of it, things I have anticipated - except the part about drones not being subject to collision detectiona any more.
I do realise there are many calculations to be made, but that alone doesn't feel like enough reason why all this happens, in the way it happens. There has to be something else, something quite special that happens when a large group of ships hang out near one another - that causes more lag than if they were sitting far away from each other.
I can think of two things:
1) Exponential increase in collision detection calculations.
2) Exponential increase in the amount of data that need to be transmitted to the clients.
I'm hoping there's work in progress on this, priority work, as currently everything but small skirmish battles are ... non-functional.
|
Ix Forres
Caldari
Vanguard Frontiers
Imperial Republic Of the North
|
Posted - 2008.08.13 12:59:00 -
[9]
Computationally, given that we're dealing with hitboxes and nothing complex like hitspheres, collision detection shouldn't be a problem.
Computationally, most of those tasks are trivial- but if these sorts of tasks are lagging the nodes, surely then improving those, speeding up the algorithms- hell, maybe even scaling the accuracy based on the load- there's lots of stuff that could be done to reduce the impact of such tasks on the CPU, no?
Arna's original point on FPS servers is a very solid point- obviously other games don't have such a problem, so what makes EVE special in this regard? What's the 'magic factor' that increases computation complexity so much that these tasks become an issue?
--
Ix Forres
EVE Application Developer
ISKsense | RLS-EVE | Blog |
|
CCP Lingorm
C C P
|
Posted - 2008.08.13 13:50:00 -
[10]
One of the things that makes the fps easier on physics calculations is that they can be done on your machine ... your machine has the map data and can control where you are allowed to go, so the server only has to run minimal checks on this. In EVE your machine does not have this data, the servers do so it has to do all the computational work and then send you all the results.
And the transversal calculations are not as simple you make it sound, as it increases exponentially with the number (actually it is the sum of the number of ships and drones) of people on that map ... hit calculations are also per gun so the number of guns (including each gun on a drone). Damage calcualtions (per gun, drone and missile hit) ... so you can see how this grows very rapidly in a fight ...
There is also other stuff that is going on ... will not get into all of it as I do not understand all of it (yet).
CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader
Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
|
Matalino
Gallente
Ki Tech Industries
|
Posted - 2008.08.13 14:35:00 -
[11]
Originally by: CCP Lingorm
And the transversal calculations are not as simple you make it sound, as it increases exponentially with the number (actually it is the sum of the number of ships and drones) of people on that map ... hit calculations are also per gun so the number of guns (including each gun on a drone). Damage calcualtions (per gun, drone and missile hit) ... so you can see how this grows very rapidly in a fight ...
It seems a bit odd that you would calculate the transversal for every ship relative to every other ship, especially since one would expect that the vast majority of those transversal values would go unused in any given cycle. I would have thought that transversal would be calculated when needed by the turrets.
|
|
CCP Lingorm
C C P
|
Posted - 2008.08.13 15:44:00 -
[12]
There could be some filtering on this ... but as there are so many circumstances where this is needed I am not sure what those are ...
CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader
Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
Matalino
Gallente
Ki Tech Industries
|
Posted - 2008.08.13 17:00:00 -
[13]
Originally by: CCP Lingorm
There could be some filtering on this ... but as there are so many circumstances where this is needed I am not sure what those are ...
Other than turret tracking, what circumstances require transversal?
Obviously turret tracking would be calaculated frequently, but I would expect it to be a linear increase with the number of turrets/rate-of-fire not exponential with the number of ships/drones on grid.
Is it used in defining orbital paths?
Even if it is, any one ship/drone can only be orbiting one other target, so a linear not exponential increase in the number of transversal calculations as more ships/drones are added to the grid.
The overview has the option to display transversal, but I would have expected that the server would just send general speed and position information to the client and off-load the need to calculate transversal/radial/angular/absolute velocities to the client, if it needs to be displayed.
What other circumstances need transversal?
Anyways, I suppose that you guys understand your physics engine far better than we could.
|
Thebro Nobrunder
Schrodinger's Renegades
|
Posted - 2008.08.13 17:21:00 -
[14]
Originally by: Matalino
Originally by: CCP Lingorm
Obviously turret tracking would be calaculated frequently, but I would expect it to be a linear increase with the number of turrets/rate-of-fire not exponential with the number of ships/drones on grid.
Tracking increases at the square of the number of objects.
If there are 2x 100 man fleets in combat then each one of them needs to calculate the traversal of every other object. In this case that results in 39,800 traversal calculations. Half that if the calculation in symetric.
This gets even better if everyone has 5 drones out. (1,438,800)
I've been doing this kind of thing for 20 years now, and while there are always things which can be done to increase performance... it is very impressive that CCP does as much as they do.
-------------
oh, and to the previous poster... bounding spheres collisions are actually easier to calculate than bounding box collisions.
|
Buildius Maximus
|
Posted - 2008.08.13 17:23:00 -
[15]
Doesn't the transversal have to be calculated for all other objects on the grid, regardless of the column settings, on every overview refresh interval?
If so, this sucks, and is possibly a source of extreme lag, as every ship determines transversal to every object on the grid...it would be nice to be able to turn this calculation off if it isn't one of the overview settings
|
Thebro Nobrunder
Schrodinger's Renegades
|
Posted - 2008.08.13 17:36:00 -
[16]
What "might" be possible is to only calculate traversals from each object to targeted objects.
Some profiling during fleet ops should readily identify where the slowdowns are.
|
burning raven
omen.
Triumvirate.
|
Posted - 2008.08.17 07:54:00 -
[17]
dont forget that its an option to show it on your overview which requires it to be updated constantly for all ships/drones on grid for it to be meaningful
|
Stevil Knevil
|
Posted - 2008.08.17 11:33:00 -
[18]
I think it's unlikely that it's actual CPU load on the servers that is a problem - rather getting all the network data:
- Overview: Sending ALL the stuff to make your overview work (speeds, distance, positions)
- New data: Corp, Pilot name, ship name, standings of any pilot who warps in. (NB This will be a huge amount of data if you are warping/undocking into a huge blob as you will need this info for every member of the blob).
- Targets: Sending target information (whether it's locked, damage, whether someone is targetting you, whether it's firing at you)
- Modules: Whether the module that you clicked on has become activated yet, whether reloading has finished, whether it's taken any heat damage...
- Damage: Current state of you shields armour and hull (probably only sent when it changes)
- Status: Who's warp scrambing you, who's webbing you (and thus what your max speed is), who has Sensor damps ECMs on you (and how that affects targetting range and time), who is remote repping you...
- Drones: Whether your drones are idle, fighting etc. How much damage they have taken.
- Cargo: what's in the wreck that you just looked in - did it get transferred to your cargo hold. What salvaged materials did you get?
Now all that data has got to be sent from the server to everyone in the grid. Also it has to deal with all the requests coming from the clients (I believe that repeatedly clicking a module on and off can increase lag as that's a load more requests that the server has to handle)
And that's before you start thinking about other people in the system who are requesting market data etc. Now, it may well be that the markets are on a seperate server (I think that was planned at some point) but if not then it will contribute.
I'm basing most of this on speculation and bit and bobs that I've gleaned over the years but it seems to me that this it the main cause of lag.
Now to go back to your original point: How come an FPS with 60 players can be quicker? Well: much more collision detection, done on the server - that's just maths, like you say - relatively straight forward. But now consider the stuff being sent over the network:
- Positions: of every player
- Weapon: current weapon being held by each player
- Damage: health of each player
- Firing: whether any player is firing their weapon (for animation purposes - hit detection will usually be server side)
- Move State: Whether they are jumping, running prone.
Even adding vehicles isn't going to take too much more as you don't need to send anything if the vehicle is static and doesn't take damage.
This is a much smaller set of data (especially when you consider that most of this data can be sent as enums and single bits). I think if you actually looked at the actual number of bytes being communicated from the server to your client per frame in EVE and compared it to the amount in an FPS you would see how much smaller it is.
One final point: It may not be server lag - it may be that the client rendering is slow. The easy way to tell this: If you can still rotate the camera but there's nothing changing then your client is rendering quickly but the server hasn't sent any new data. If you can't rotate the camera then your client is struggling to render a frame. NB If you are stuck on a black screen after a jump or undock then it's probably server lag - potentially due to it having to send you a huge amount of pilot names, corps, standings, security statuses, ship types, ship names, drone positions...
At least, that's what I think :)
|
BigWhale
Gallente
Three WiseMen Association
|
Posted - 2008.08.24 06:56:00 -
[19]
Maybe fleet jumps could me more synchronous? When fleet commanders issues an order Jump Fleet, all incoming clients are put on standby, data is gathered, sent to clients and when clients report that data is there rendering should begin. And at that point all the ships would appear on the grid.
Something similar to this could help a little.
Then, then there is compression. CPU vs bandwidth problems. Is server CPU usage that is causing lag and there is bandwith to spare? Drop the compression. Put less load on CPU and more on the network. If it is the other way around, compress more! :)
How about some load balancing on one single node? Can this be done? One 'calculator-sub-node' would take care of calculating everything and sending it over some local hi speed connection to other 'network-sub-node(s)' that would handle network connections and compression of data.
With this approach you could probably eliminate the CPU lag on the server node.
--
R, U & Y are letters, not words... |
Kagura Nikon
Minmatar
Infinity Enterprises
|
Posted - 2008.08.25 15:44:00 -
[20]
Originally by: Arna Padrona
Originally by: CCP Lingorm
I can't go into all the details, because I do not know all of them, but here are some of the calculations that needed to be calculated every time period on a grid in combat.
Travel vectors and collisions. We need to calculate the space ship will occupy while traveling and then see if any other ships intersect/collide with this.
Transversal velocity. We need to know your velocity in respect to other ships on the grid for calculating hit chances and such.
Hit and damage calculation.
Missile and drone travel paths (these are non collision object so collisions do not need to be calculated). Missile terminal maneuvers.
Ship status/effect changes (turning modules on and off, auto reactivation, capacitor, dmg resists, repair, boosting, webbing, scrambling, jamming etc).
So as you can see it is not a trivial set of tasks.
Please remember that this is not a complete list and a basic description of the process but it gives you an idea of what is done.
Thank you. All of it, things I have anticipated - except the part about drones not being subject to collision detectiona any more.
I do realise there are many calculations to be made, but that alone doesn't feel like enough reason why all this happens, in the way it happens. There has to be something else, something quite special that happens when a large group of ships hang out near one another - that causes more lag than if they were sitting far away from each other.
I can think of two things:
1) Exponential increase in collision detection calculations.
2) Exponential increase in the amount of data that need to be transmitted to the clients.
I'm hoping there's work in progress on this, priority work, as currently everything but small skirmish battles are ... non-functional.
just an addendo. Well implemented collision detection system do not grows exponentially. A simple sweep and prune approach or hierarquical space partitioning is enough to down the complexity to logaritmic or linear logaritmic composition. On other side, things like finding where to spawn each ship after 300 ships jump trough a gate at same time so they don't appear already colliding which each other is a horrible task to be computed (if you really want to optimize that to avoid too many collisions a few seconds later)..
-------------------------------------------------
If brute force doesn't solve your problem... you are not using enough
|
|
NanDe YaNen
The Funkalistic
|
Posted - 2008.08.26 01:53:00 -
[21]
I apologize for preaching to the Vatican, but it's immediately obvious from what's been said thus far that there are vast opportunities for speed increases.
Avoid N-body problems
Anything were x clients require x calculations/updates is n-body. Performance scales exponentially into the toilet. Doubling performance of the server only gains a 50% increase in the amount of load it can handle. Very, very bad. It's a lose-lose situation and Eve is inherently limited by such a mechanic.
Data Subscription and Prioritization
Many pilots, due to what they aim to accomplish in their ship, can care less about 75% of what's taking place on overview, especially in large fights.
Divide the data that needs to be transmitted to clients into several channels that represent relevant sets of data that certain pilots care about more. Speed ships need to know a lot about smaller ships and where concentrations of ships are. They care about location of things that need to be tackled and much less about what they're doing. They need to know most of all what other speed ships are doing.
BS's aren't shooting warrior II's. Don't give them priority updates to targets they don't care about.
Dreadnoughts can't hit most ships and really don't give a damn about who is shooting who. Tell them about their modules and ship status and prioritize their activation.
Ships that are immobile can go in a separate channel. Dreads that are in siege don't move. Don't send their data in updates until they go into another channel.
Create default settings and allow modifications to data prioritization so that a pilot can request only the data they need most be updated frequently. This will drastically cut down on the bandwidth going to each client in what would be laggy fights.
Consider it like shaped desynch. A client gives up information on things they don't care about in order to gain priority for things they do. As each client is overall requiring less information, the amount of bandwidth goes down quite a bit, and the granularity for information updates that pilots do care about goes up.
Overview Data Subscription
As pilots only use so much of the data that is made available in the overview, any server-side calcs should also be made into channels that are sent only to clients with overview tabs requesting the information. This will kill a lot of overview lag when large blobs warp into each other.
Overview pre-Sending
With the twenty or thirty seconds of time in between warp initiation and landing in most cases, it should be relatively easy to initiate the sending of data once the warp is in progress. Yes, pilots could abuse the data stream to see what they're headed into, but mostly this will be lag delayed in real situations, so pre-sending will only bring the initial lag down a bit.
Ships are Finite State Objects
All ships have a finite set of values that can exist with their skills/setup. Each module will create a different state for the affected variables. No reason to go through all the calculation steps when you can create a condensed list of states depending on modules.
Things like leader bonuses would have to be entirely recalculated for each change in leader, requiring a sudden regeneration of all state lists for all ships, so put those into the equations, but take module calculations out where they can be represented in finite states.
Requires a bit more memory, but will be drastically faster when it comes time to calculate, as most of the work exists in a pre-calculated list of states where only relevant values are updated when a module is activated/deactivated.
Can I get on the payroll?
---------------------------------------
 |
NanDe YaNen
The Funkalistic
|
Posted - 2008.08.26 01:58:00 -
[22]
GPGPU Calculation Assistance
In situations where calculations must be performed in an n-body situation or near n-body, generate somewhat fast code that can be performed in a highly parallel nature on a GPU. Even bad code will run so much faster on a 300GFLOP modern GPU (even a chipset embedded GPU has tons of horsepower) that the gains will be modestly huge.
Modern GPU's have some decent branching implementations and all of them can perform vector calcs out the ass. In any situation where a small, somewhat static, data set has many calculations performed on it, streaming it back and forth to a GPU makes excellent sense.
---------------------------------------
|
Sir Buff
|
Posted - 2008.08.26 06:52:00 -
[23]
Lag isn't a server problem. It's a client problem. If there's any server out there that is going to have the bandwidth to accommodate MMO it's CCP.
The problem is the 1 person among our fleet that is trying to play off of a 14.4k modem. So that the other 60 players need to receive their packets and stay synchronized all at the same time otherwise you start seeing bouncing ships...which deserves an immediate disconnect in my opinion because if someone is lagging that bad in today's technology I deserve to salvage their disconnected lagging ship.
Solution to fix lag, boot laggers. But, if CCP booted the laggers for high ping you would start seeing a very large amount of players being booted because they thought they ordered high speed. What 1mbit/sec?? If you don't have at least 5mb/sec high speed connection in my book you are a lagger.
So that accounts for about 85% of Eve... while the other 15% that have a clue are stuck with it.
|
Sir Buff
|
Posted - 2008.08.26 06:57:00 -
[24]
By the way, if you're dying to know what you're at then visit www.speedtest.net
30mb/sec for me :D. And, by the way. mb is mega BITS which is 8 times smaller than mega bytes. So if you think you are getting mega bytes then first divide by 8... so you're not as fast as you think after all XD.
|
Dr Slaughter
Minmatar
Rabies Inc.
|
Posted - 2008.08.26 08:36:00 -
[25]
Originally by: Sir Buff
Lag isn't a server problem. It's a client problem. If there's any server out there that is going to have the bandwidth to accommodate MMO it's CCP.
1. Bandwidth <> latency
2. WTF is module lag caused by then?
3. Why do CCP have our clients connect to a proxy and the proxy to the node doing the majority of calculations? Is it to increase the latency between us and the processing node? Or is it to reduce the amount of communication needed / normalize data / cache unchanged and commonly read data? etc. etc
Not having a go, personally, at you Mr Buff, but it's amazing how many times we have to go through the 'it's the network.. no it isn't it's the server.. no it isn't it's the network' argument. It's been going on, again and again since before 2005.
The major problem is CPU usage on the single CPU running the combat logic. CCP Lingorm has said this already in the infiniband thread, and it's been discussed a lot else where.
Having said that CCP have also stated that they're interested novel solutions to their problem BUT.. frankly.. that requires us to have a better understanding of how the game actually works currently.
Would be nice to have an answer to my 'how goes session changes work' in this same board.
~~~~
There is no parody in this thread. Honest. |
Kagura Nikon
Minmatar
Infinity Enterprises
|
Posted - 2008.08.26 12:39:00 -
[26]
Originally by: Sir Buff
Lag isn't a server problem. It's a client problem. If there's any server out there that is going to have the bandwidth to accommodate MMO it's CCP.
The problem is the 1 person among our fleet that is trying to play off of a 14.4k modem. So that the other 60 players need to receive their packets and stay synchronized all at the same time otherwise you start seeing bouncing ships...which deserves an immediate disconnect in my opinion because if someone is lagging that bad in today's technology I deserve to salvage their disconnected lagging ship.
Solution to fix lag, boot laggers. But, if CCP booted the laggers for high ping you would start seeing a very large amount of players being booted because they thought they ordered high speed. What 1mbit/sec?? If you don't have at least 5mb/sec high speed connection in my book you are a lagger.
So that accounts for about 85% of Eve... while the other 15% that have a clue are stuck with it.
LAg is NO WAY client problem. I monitor my connection all time and keep logs. During last friday I was in a fight with 300-400 in local. During 2 hours of fight I received 11 MB of data only and transmitted a few KB! And I have a 3MB/s connection. System was completely lag-less. A few months earlier ina fight of about same size on PB It took me 40 min to load grid and every module had 7-12 min activation lag. Same connection again very low network traffic. Dropping from 3 clients to 1 didn't changed a single bit.
But on other fights with even lass people things get very laggy. And simply changes nothing if I use premium account, classic account, 2 or even 3 premium accounts. There is minor change If I use nothing showing on overview or all enemies and all friendlies showing on overview.
Lag on huge fights is 99% of time a server sided issue. There is absolutely no doubt about that, at least if you have a computer designed in the last 3 years.
-------------------------------------------------
If brute force doesn't solve your problem... you are not using enough
|
Kagura Nikon
Minmatar
Infinity Enterprises
|
Posted - 2008.08.26 12:41:00 -
[27]
Originally by: Sir Buff
By the way, if you're dying to know what you're at then visit www.speedtest.net
30mb/sec for me :D. And, by the way. mb is mega BITS which is 8 times smaller than mega bytes. So if you think you are getting mega bytes then first divide by 8... so you're not as fast as you think after all XD.
Then run a network logger while in your next fleet battle and discover that you don't need more than 100 Kbps.
-------------------------------------------------
If brute force doesn't solve your problem... you are not using enough
|
Sir Buff
|
Posted - 2008.08.26 13:38:00 -
[28]
Originally by: Kagura Nikon
LAg is NO WAY client problem.
Lag has always been a client problem. If your latency to the CCP server is 15ms and 1 other person in local has a latency of 200ms, the most optimum result your are going to receive is 200ms between both individuals.
Originally by: Kagura Nikon
Lag on huge fights is 99% of time a server sided issue. There is absolutely no doubt about that, at least if you have a computer designed in the last 3 years.
CCP holds 30-40k simultaneous users, however it all of the sudden lags when a measly 60 users get together in the same area?? And in another area of the map there's me making my trade runs at 0 lag problems flying in solar systems with plenty of users.
99% of latency issues are client. It's like that with every game anywhere. I have to disagree with you thinking it's the server. My example above is proof it's not the server. Otherwise, I would see your lag on my end.
Let's see how fast 3mbit/s get's used up. You are flying around the map constantly updated your in game position to CCP and all the other things that you are doing, that could easily take 200kbit/sec. Now you have 60 pilots in your area all doing the same thing, 3000kb/sec is your connection - (60*200kbit/sec) so you can know what the other pilots are doing. That's -9000kbit/sec on your connection. Now factor in all the other player's bottle necked connections... and in all that lack of bandwidth everyone has to stay synchronized with everyone else so no ships start jumping around.
|
Dr Slaughter
Minmatar
Rabies Inc.
|
Posted - 2008.08.26 15:32:00 -
[29]
Edited by: Dr Slaughter on 26/08/2008 15:33:00
Originally by: Sir Buff
stuff
Latency is an issue. Bandwidth really isn't.
out of date bandwidth discussion
If your round trip to the proxy sucks you will lag. I don't think anyone will argue with you on that.
What we will argue with you about is saying that lag in eve is caused by the network. We will point out the majority of fleet battle lag comes from the service which is running the in-space part of the game running out of available CPU and the network has nothing at all to do with that.
~~~~
There is no parody in this thread. Honest. |
Sir Buff
|
Posted - 2008.08.26 15:38:00 -
[30]
Another performance things I should point out is the graphics processing done on your computer. I've noticed that when I'm max out the graphics in the premium edition (I have 9800 gx2, so it's buff) and I fly into lots of Concord ships or lot's of ships in general, my framerate drops, sometimes to 10fps when I'm zoomed all the way in. This however is resolved if I turn off shadows in the graphics options and turn down the HDR bloom effect. Maybe some of the lag you notice has to do with having to render all those other ships.
Running multiple clients will also exponentially decrease performance. I'm playing this game for the overall MMO gaming experience. And multiple eve clients running on the same computer is detrimental to the extreme graphics  .
If anyone get's their hands on a 9800 gx2 it hooks up rather nicely on a HD TV with HDMI support 1900x1080. Since Nvidia released their latest graphics cards the price has dropped significantly on the gx2, I snatched one right up a few weeks ago .
|
|
| Pages: [1] 2 3 :: one page |
| First page | Previous page | Next page | Last page |