open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fixing Lag: Drakes of Destiny (Part 2)
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 3 4 [5] 6

Author Topic

Jas Dor
Minmatar
Posted - 2010.12.15 04:22:00 - [121]
 

Edited by: Jas Dor on 15/12/2010 04:50:59
Edited by: Jas Dor on 15/12/2010 04:36:34
Originally by: CCP Explorer
Originally by: galphi
You could also replace the physical object missiles with the 'fake' missile effects used by the fighter-bombers. It's not like anyone ever uses defender missiles anyway Very Happy
You have to remember that missiles interact with AoE weapons. We have given this significant thought but it's not trivial to implement.

You will note that even if the fighter bomber graphical effect is missile-like and even if the fighter bomber damage is calculated missile-style then you can't use AoE weapons to defend against their missiles.


Oh for the love of god, just figure a percentage change of the missile getting blown up if an AoE or defender missile system is active (and draw down defender ammo by time). There I just fixed both your problem AND defender missiles.

After thinking about what this would mean for missile hit points, I've decided just give each system a stacking nerfed percentage chance to kill a missile and have larger missiles provide a modifier for that percentile role. This would also allow for AEGIS Cruiser ships that give everyone in a radius an increase to their point defense percentile. This would also allow for a drone/fighter nerf if you made those entities subject to this system.

The firing sequence would look something like this:
1. Missile Fires
2. Verify target still in range
3. Roll d100 against ([Point Def] - [Resistance bonus])
4. If roll < ([point def] - [Resistance bonus]) then
Destroy Missile,
Else
apply damage.

This however still requires multiple rolls for grouped launchers. Hum maybe applying the point defense total as a damage reduction to missiles (missiles getting hit by point defense but still detonating in range to damage the target) would make for a better abstraction. That cuts out the randomization and gets it down to straight math.

The real trick is going to be to compute range without having missile exist as an independent entity.

Dillon Arklight
Aliastra
Posted - 2010.12.15 04:27:00 - [122]
 

I have to admit to not following everything (its 4:30 am) but what i did follow looked good. Thanks for the blog and the insight into Team Gridlock's fight against lag.

Tres Farmer
Gallente Federation Intelligence Service
Posted - 2010.12.15 12:12:00 - [123]
 

Edited by: Tres Farmer on 15/12/2010 12:19:27
Originally by: Vincent Athena
I'm wondering if it would work to have every missile launcher come with a pre-allocated ball for its missile, rather than creating and destroying the ball every time the missile fires. The clients would all know that this ball would jump back to the firing ship once the missile hits or is destroyed. Maybe less cpu would be needed to handle missiles.

What happens when [flight time of missiles to target] is bigger than [launcher cycle time]?

I don't think it's needed or productive that we speculate about ways to get this part of the code faster without knowing how it really works.

Originally by: Vincent Athena
Longer time ticks: Two different methods have been suggested, and CCP has responded to only one (unless I missed something).

Method 1: do 1 second of simulation in 2 seconds, time slows. CCP response is we are considering it, there are issues with having 2 times scales going on at once.

Method 2: do 2 seconds of simulation in 2 seconds. Would this help in any way?

The Space Simulation doesn't seem to be the bottleneck at them moment.
It's still waaaay behind the serialisation of the information to be send to the clients and even that one is now waaaay behind the part of the code that creates/destroys missiles.
Please visit your user settings to re-enable images.

Originally by: Vincent Athena
Also: you can view outstanding calls by hitting shift control alt m. Maybe this number should automatically be displayed somewhere, like above the time, whenever it is greater than zero for more than a few seconds. It would tell the players that things are getting laggy, stop pounding the keyboard and give the server a chance to catch up.

You naively assume that ALL players want the server to stay in a working condition to fight the battle... Laughing

WisdomPanda
Goatriders Horde
The Scapegoats
Posted - 2010.12.15 13:24:00 - [124]
 

Awesome blog, just don't listen to the haters on the low level code thing. If Python (or any other language for that matter) helps you write more efficient code on different levels, run with it. Lets face it, if low level performance was the key to everything, we'd all still be hand writing some form of assembly. We'd also take 8 years to publish an expansion and require and entire dev team to baby sit the graphics department.
(No offense graphic guys, but I doubt assembly is what you think of when you go to work in the morning.)

Although secretly, they're all just wishing they could have your job.
(Personally, I'd never hire anyone who's first answer to a performance issue is "use a lower level language." Clearly, CCP agrees.)

Serious Masta
Posted - 2010.12.15 15:41:00 - [125]
 

i like'd to read the articles and wanna see more of them!

i'm a developer and the shower-moment is a well known situation :)

Espacio Cristo
Posted - 2010.12.15 16:43:00 - [126]
 

Just a quick one of those in the shower ideas. I'm sure I overlooked something important or stupid.

Would it be possible to group the drones of the same type together into one ball as we do with missiles?
So instead of each individual drone having it's own ball, there is one ball representing the actions of the group.

The issues I can imagine:
* This assumes that the group has the same target.
* This would assume that all the drones are at the same location at any point and have the same velocity, orbit, etc...
* Drone hit points and calculating damage from AOE, which drone takes the hit?

Vincent Athena
Posted - 2010.12.15 18:46:00 - [127]
 

Originally by: Tres Farmer
Edited by: Tres Farmer on 15/12/2010 12:19:27
Originally by: Vincent Athena
I'm wondering if it would work to have every missile launcher come with a pre-allocated ball for its missile, rather than creating and destroying the ball every time the missile fires. The clients would all know that this ball would jump back to the firing ship once the missile hits or is destroyed. Maybe less cpu would be needed to handle missiles.

What happens when [flight time of missiles to target] is bigger than [launcher cycle time]?

Have more than one preallocated ball.

I don't think it's needed or productive that we speculate about ways to get this part of the code faster without knowing how it really works.

Originally by: Vincent Athena
Longer time ticks: Two different methods have been suggested, and CCP has responded to only one (unless I missed something).

Method 1: do 1 second of simulation in 2 seconds, time slows. CCP response is we are considering it, there are issues with having 2 times scales going on at once.

Method 2: do 2 seconds of simulation in 2 seconds. Would this help in any way?

The Space Simulation doesn't seem to be the bottleneck at them moment.
It's still waaaay behind the serialisation of the information to be send to the clients and even that one is now waaaay behind the part of the code that creates/destroys missiles.
Please visit your user settings to re-enable images.

I dont mean just the flight stuff, I mean everything that happens in that tick. Somewhere above CCP said that the number of people that can interact in a MMO is proportional to the tick length, so making it longer in high load situations seems like a possibility.


Originally by: Vincent Athena
Also: you can view outstanding calls by hitting shift control alt m. Maybe this number should automatically be displayed somewhere, like above the time, whenever it is greater than zero for more than a few seconds. It would tell the players that things are getting laggy, stop pounding the keyboard and give the server a chance to catch up.

You naively assume that ALL players want the server to stay in a working condition to fight the battle... Laughing


Those who want to cause lag will do so anyway. At least this will give an easy tool for those who do not.

Karbon Dating
Posted - 2010.12.16 06:15:00 - [128]
 

Whats the issue with moving the physics engine and the rest of the stuff that happens in a system to different nodes? The physics engine gets all the CPU power it could ever want and all that entensive work for the rest of the stuff that goes on in a system would have more processing power to work with.

Seripis Chiktor
Amarr
Cypher Industries.
Posted - 2010.12.16 12:33:00 - [129]
 

from a programmer and network sec guy i have always been impressed with the server setup for this game. The structure and seamless bridging between blades is outstanding that alone is a lovely design. Apparently it cant be to easy to do as blizzard still keeps its servers split.

My question is this. Often time i notice lag even in the remote area i reside in in devoid. I know it is high sec but the traffic there is normally less than more low sec and null sec.

Its the simple things that cause lag as well. Warping in on a POS. Or engaging rats in the belts. Often times its just loading my messages in game or skills. some days it takes 1 to 2 mins to load messages or more. Yes i keep them clean.

I know these things seem trivial but are on the list to be addressed?

Also from a client side view I have noticed connection brownouts. from my home I develop code for clients and web dev. so my internet connection is active but in respect to other clients I run often I notice that the connection to eve will fade of sorts.
at first I thought it might be the connection on my end but after doing some watching I have noticed that it is indeed the communication between server and client. the connection its self is not lacking but the load of data being transfered fluctuates by a margin of up to 30%

ok im done now lol just some things i have noticed.

Shadow Watchman
Posted - 2010.12.16 13:49:00 - [130]
 

And what about millions of mission/belt/anomaly NPCs spewing billions of missiles every second ? I think it is introducing persistent anomalies in Dominion caused a terrible load on the server :)

Forest Hill
Posted - 2010.12.16 14:59:00 - [131]
 

Very interesting blog, touches on what I sometimes do at my day job.. HP diagnostics and loadrunner produce about the same graphs. Good stuff, keep 'em coming!

Tiruriku
Posted - 2010.12.16 15:55:00 - [132]
 

excellent blog series, thanks.

CCP Masterplan


C C P Alliance
Posted - 2010.12.16 16:44:00 - [133]
 

Originally by: Vincent Athena
Edited by: Vincent Athena on 14/12/2010 20:03:19
Fun read! Nice work.

I'm wondering if it would work to have every missile launcher come with a pre-allocated ball for its missile, rather than creating and destroying the ball every time the missile fires. The clients would all know that this ball would jump back to the firing ship once the missile hits or is destroyed. Maybe less cpu would be needed to handle missiles.

Longer time ticks: Two different methods have been suggested, and CCP has responded to only one (unless I missed something).

Method 1: do 1 second of simulation in 2 seconds, time slows. CCP response is we are considering it, there are issues with having 2 times scales going on at once.

Method 2: do 2 seconds of simulation in 2 seconds. Would this help in any way?

Also: you can view outstanding calls by hitting shift control alt m. Maybe this number should automatically be displayed somewhere, like above the time, whenever it is greater than zero for more than a few seconds. It would tell the players that things are getting laggy, stop pounding the keyboard and give the server a chance to catch up.

Edit for cut paste oopsie

If we pre-allocated balls for missiles, we'd still have to tell all the clients that a pre-allocated missile has now changed from 'in the launcher' to 'flying in space'. Figuring out which clients to send this update to would probably still need a similar amount of work.

Regarding method 2: This is one of the ideas we've considered. It would help reduce the proportion of time spent in Evolve (see the 'Destiny - Physics' area in blog 2, figure 1) However it wouldn't help the other areas of Destiny, as their cost is mainly per observer/missile. rather than per tick.
There might be other issues with movements of very fast ships, for example when you can cover a large distance, or possibly even entire orbits within a tick duration.

You make a good point about the client providing some automatic display when server conditions are bad. Not everyone runs with the monitor window active.

CCP Masterplan


C C P Alliance
Posted - 2010.12.16 17:01:00 - [134]
 

Originally by: Jim Luc
CCP Masterplan, I'd love to learn more about how the graphics are decided upon, for the lasers & missiles - how much of each relies on the actual math and physics.

Unfortunately I'm not the best one to answer this - client-side graphical effects aren't an area I've done much work with. Server-side, all we care about is Ship A firing at Ship B - we don't track it at any more detail that that.
I agree that it would look great if we could do a lot of what you described. The only thing I can think of is that we don't send your client the hit/miss results of other ships shooting each other. So if you are watching a pair of ships fighting each other, what you see wouldn't be an accurate portrayal of who is landing the most hits. As you might be able to imagine, sending out this info would cripple the server in ways that make me shudder!

CCP Masterplan


C C P Alliance
Posted - 2010.12.16 17:09:00 - [135]
 

Originally by: Espacio Cristo
Just a quick one of those in the shower ideas. I'm sure I overlooked something important or stupid.

Would it be possible to group the drones of the same type together into one ball as we do with missiles?
So instead of each individual drone having it's own ball, there is one ball representing the actions of the group.

The issues I can imagine:
* This assumes that the group has the same target.
* This would assume that all the drones are at the same location at any point and have the same velocity, orbit, etc...
* Drone hit points and calculating damage from AOE, which drone takes the hit?

Drone grouping is a regular topic here. You've picked up on some of the areas we'd need to address. None are impossible to solve - this is on our list somewhere.

BOOYA MOFO
Posted - 2010.12.16 17:14:00 - [136]
 

Translate pls.

what happens to drakes?

Daneel Trevize
Gallente
Posted - 2010.12.16 18:31:00 - [137]
 

Edited by: Daneel Trevize on 16/12/2010 18:33:13
Quote:
If we pre-allocated balls for missiles, we'd still have to tell all the clients that a pre-allocated missile has now changed from 'in the launcher' to 'flying in space'. Figuring out which clients to send this update to would probably still need a similar amount of work.
Sure but wasn't it said that generating and removing the balls was the big hit?
So if you had a steady stream of balls being generated (until a ball pool is full), then you're spreading this work out over time, while updating their state to now being out & about has less of an impact?

Equally, dead balls perhaps don't need to be fully retired & removed asap, but I guess this all comes down to how the interaction calculations & data structures can efficiently cope with such ball states being scattered throughout.

Ebisu Kami
Posted - 2010.12.16 20:35:00 - [138]
 

Edited by: Ebisu Kami on 16/12/2010 20:36:24
Originally by: Daneel Trevize
Sure but wasn't it said that generating and removing the balls was the big hit?
So if you had a steady stream of balls being generated (until a ball pool is full), then you're spreading this work out over time, while updating their state to now being out & about has less of an impact?


You want to create more balls in advance then needed? Strikes me as a bad idea. Really, your system does the same as the old, except for creating balls in advance, which will clog up the system additionally, while during a fight still working like the old system. That's not going to increase performance and will lower it eventually even more because of the extra-balls that need to be tracked.

Daneel Trevize
Gallente
Posted - 2010.12.16 21:08:00 - [139]
 

Edited by: Daneel Trevize on 16/12/2010 21:29:31
Just trying to average out the ball creation. Perhaps there's some relationship between players on grid or launchers fitted and the average number of balls needing to be created & destroyed as a fight progresses, and that pre-creating several balls when breathing room is detected might keep the thing treading water for longer.

Again, unless I'm misremembering, tracking the balls isn't the issue so much as the creating & informing everyone with the related info, and having to do this a lot in too short a time.

Edit: Upon re-reading the blogs, I'm reminded it seems the issue is mainly determining which clients to update with what, but the pseudocode and text seems to find this condition a key part of it:
'if ball was added/deleted to the bubble in the last tick'

It still seems there'd be a big payoff if you only had to track 'max-possible-missiles-in-space-from-a-given-launcher-including-overheat-etc' for the battle lifetime of a launcher/group/ship rather than create and destroy a ball for each unit of ammo he chucks.
Once you're a few seconds into the brawl and you've already created that many balls, now you're just having a conveyor belt of them with some state changes rather than churning out more and more. Could even get some cache benefits of reusing such items but that's very hard to say.
E.g. after 20secs you'd have added 10 balls but that's it, creation/destruction has peaked and you're almost back to where you were before loadwise. Currently you may have only added as many balls but in the next 20s you'll do it all again and then again, load remains higher if create&destruction outcosts state management.

Ebisu Kami
Posted - 2010.12.16 22:15:00 - [140]
 

Edited by: Ebisu Kami on 16/12/2010 22:30:18
Originally by: Daneel Trevize
Just trying to average out the ball creation. Perhaps there's some relationship between players on grid or launchers fitted and the average number of balls needing to be created & destroyed as a fight progresses, and that pre-creating several balls when breathing room is detected might keep the thing treading water for longer.


You can't really average out engagement patterns, because a single fight is made up of a wide array of different paramters. Number of ships in fight, what is primaried, how the ships are fit, how the people decide to move, how far the ships are from each other, ammunition-type and and and and and and and and and and and. It's like trying to predict how each single hair looks after having a wild night. Even if you try to narrow it down somehow, you'll still not cover nearly enough to justify doing the statistics for a number of certain cases and the programming effort ultimately involved.

Originally by: Daneel Trevize
Again, unless I'm misremembering, tracking the balls isn't the issue so much as the creating & informing everyone with the related info, and having to do this a lot in too short a time.


Tracking one ball might not be an issue, but multiply it with 100 ships. On both sides. And you also want to have balls stored in advance, so multiply it with the factor of your liking. Let's say a single missile-ship creates 40 balls in an average fight (although that's not going to work, as stated above), so you'd want to have that many balls per ship in advance, else your system obsoletes itself: 100*2*40=8000 balls that you need to keep track of + the ship-balls. You'll quickly end up at a point, where the overhead of tracking x balls has about the same effect as simple creation-destruction, plus at some point your pre-stored balls will be used up and you'd definitly need to create as many more as balls got destroyed, else people will not be able to fire missiles because they used all their balls or you'd just end up at a point where the balls are again created and used as before that little stunt... That's not going to work well.

Even worse, when do you want to create those balls in advance? You'd have to create and destroy them whenever a ship undocks or jumps through holes or gates, even for a simple grid-switch (each warp, basically) afaik, and that is for each and every ship that has missiles fitted... That's creating a ridiculously massive and completely unneeded overhead for absolutely no purpose.

Originally by: Daneel Trevize
Edit: Upon re-reading the blogs, I'm reminded it seems the issue is mainly determining which clients to update with what, but the pseudocode and text seems to find this condition a key part of it:
'if ball was added/deleted to the bubble in the last tick'

It still seems there'd be a big payoff if you only had to track 'max-possible-missiles-in-space-from-a-given-launcher-including-overheat-etc' for the battle lifetime of a launcher/group/ship rather than create and destroy a ball for each unit of ammo he chucks.
Once you're a few seconds into the brawl and you've already created that many balls, now you're just having a conveyor belt of them with some state changes rather than churning out more and more. Could even get some cache benefits of reusing such items but that's very hard to say.
E.g. after 20secs you'd have added 10 balls but that's it, creation/destruction has peaked and you're almost back to where you were before loadwise. Currently you may have only added as many balls but in the next 20s you'll do it all again and then again, load remains higher if create&destruction outcosts state management.


You're really starting to compare apples and oranges. Your system is not going to bring any performance increase, really, because you basically change a dynamic system with overhead-spikes to a mixed static-dynamic system that still has the same overhead-spikes and on top of that a lot more overhead during normal operation.

Daneel Trevize
Gallente
Posted - 2010.12.17 01:29:00 - [141]
 

Edited by: Daneel Trevize on 17/12/2010 01:53:37
Apply some logic. Only create balls for launchers if the hosting ship actually has launchers, online, loaded, and a target locked (or there's viable targets on the grid for FoF/Defenders). Even have the count grow with time, add 1 per group/launcher per tick until a defined limit.

As for averaging, we're already targetting the worst case. If people are uncoordinated (& very mixed skills) there will be less synchronised firing and reloading, instead I think the load would be slightly reduced if everyone's doing their own thing. But if they're all said blob of drakes, all in range, all reloaded at the same time, we can expect a spike in the need for balls every time their launchers cycle.

Instead if we precreated even half the expected balls that would be inflight once these ships are in full swing, we could perhaps have moved some load a few seconds or more earlier to perhaps a time when less intensive actions are happening, such as locking or reloading, and not at the time when perhaps drones are being reordered about when the primary call goes out. CCP obviously are the ones with the tools and stats to see if there is something like this going on, where several kinda of actions are bunched, with an opportunity to precalculate/prepare for some likely required actions.

You show that there would have to be a large number of balls tracked. However atm there are probably already many more being handled. A HAM drake can pack, what 66 missiles per launcher? Even if grouped that 12200 balls being handed (just) by the current system for our hypothetical fleet fight before a reload. Yes only a fraction of these would be around at any given time with the current system, but that's because it's also constantly dealing with the overhead of replacing all of these as they live their lifecycle.
But if they can only get 10 in the air at a time, that's 100*2*10 = 2000 total, an order of magnitude less by what I'm describing. Even if you buffer 100% more balls hanging around due to precreation and slow cleanup, that's still exponentially less going about. The assumption is that this 2000-4000 figure's handling can be below the current constant load from churning balls.

And the second important benefit is that once those 2000-4000 are created and being managed, the load's back down to just juggling most of them through states, not creating & destroying each in an endless stream. I'd imagine the clients would also require far less updates with this system, as they can locally calculate when a missile hits and then return the state of the ball through exploded and back to ready to fire from the launcher. I believe currently the client has to be told yep that missile died its expected death so clean up the mess with a costly-to-announce removal, whereas with what I'm proposing you'd only need the server to give updates for things like FoF/Defender/AoE interactions with the balls. The server remains authoritative in deciding how these calculations went for damage/removal, and the clients only need to be told about this less/unpredictable removal/change to the balls rather than the predictable result from their usual trajectory.

Probably final edit: I realise I'm not being consistent in whether all or some of the 'maximum' balls would be created and when in a fight lifecycle (e.g. on grid load or per launcher reload). Or whether the recycling/replacement-for-destruction-load per ball is negligable, exponentially less or even comparable to the current demand, but I believe the worst case is the same, and in any case we're removing half the work as we're not repeating all the creating load and having to update all clients about that all the time.

Ebisu Kami
Posted - 2010.12.17 02:17:00 - [142]
 

Edited by: Ebisu Kami on 17/12/2010 02:30:06
Originally by: Daneel Trevize
Apply some logic. Only create balls for launchers if the hosting ship actually has launchers, online, loaded, and a target locked (or there's viable targets on the grid for FoF/Defenders). Even have the count grow with time, add 1 per group/launcher per tick until a defined limit.


You didn't notice that your idea just got even worse, did you? Also, you didn't really notice what's going on in larger fights nowadays, did you? Well, let me show:

Rumor has it, that some larger alliances actually ask their members to specifically train for a Drake nowadays, to use it in fleet engagements. The Drake is one of the most common ships used in fleet-PvP. Also, the Drake is not the only ship on the field that has missile launcher slots and actually uses them.

Now you only want to create your balls-reservoir, when the ship actually engages/locks a target, like when it warps into an already occupied grid... together with it's fleet... a fleet that has a good chance to have a number of ships with mounted, activated and loaded launchers... engaging a hostile fleet, which will alos have a good number of missile-mounted ships... Think about that for a moment...

Daneel Trevize
Gallente
Posted - 2010.12.17 03:01:00 - [143]
 

Edited by: Daneel Trevize on 17/12/2010 03:10:37
No, I've never been in a 0.0 alliance or even a large fight. More than 5 people is a blob to me. Apologies for not joining in this crap sounding broken lagfest where it's metagamed to lag to benefit the ones there first.

That said, the point of the ball pool and recycling is to reduce the churn. The prepopulation idea, assume now including the responsive growth per tick in effect, is an optional extra. If your two fleets clash and let rip straight away, you're just creating and using the balls that currently have to be dealt with in that initial period and this mechanism wouldn't add any more. But if they're waiting for others to load grid, or cynos/bubbles, or see if the hostiles are going to aggress or run, you have time when the servers aren't under the crushing load yet, so why not invest those idle cycles and bandwidth in preparing for the probable, rather than do nothing? Example time: if they wait 10 seconds, you'd rather have the game do just the current basic updates and then get the titalwave 2000 request in 1 tick, or start sharing out protoballs updates to clients before things kick off, at 200 a second and then no major peak on kickoff?

It's been repeatedly stated that some players will always try to bring lag-inducing numbers, because playercount relative to eve performance they always can in at least 1 place at a time, and even if they don't cripple the fight, outnumbering your opponent is advantageous currently anyway. To fix that you must change the game to reward dividing forces, e.g. to adjecent system at the same time, in order to succeed at the current objective. That or relatively punish blobs, e.g. reduced stacking-style damage, or skillpoints training speed, or whatever.

Game theory is vital here. Again it's known that mechanisms like finite local/grid counts would be abused by 1 side getting there first.

What's your suggestion, other than the status quo? Razz

Vincent Athena
Posted - 2010.12.17 23:57:00 - [144]
 

Actually when I suggested pre-allocated missile balls I was thinking there would be just one (or a few for rapid firing, long duration missiles) per launcher, and they would be reused. Part of the equations of motion for a missile ball would be that it snaps back to the launcher upon missile destruction. So that info need not be sent to each client, they got it built in.

Also no need to create and destroy the balls (well, maybe when a launcher is re-loaded, because it could then be a different missile type). The server needs only process and send " missile launched" to each client, not "create ball with this location, speed, missile, etc" because the clients already know that.

Surely creating a ball and moving it around takes more work than just moving it around?

But maybe CCP knows of better, low hanging fruit to go after.

Anyway; CCP keep up the good work!

Kaya Divine
Gallente
Kittens Factory
Posted - 2010.12.18 01:01:00 - [145]
 

I'm not gonna say that while you are doing this you could add/draw some bloody launchers to ships which have fitted launchers.

Berikath
Posted - 2010.12.18 17:48:00 - [146]
 

Fair warning- I R comp sci student, so I apologize if this is one of those "knows just enough to be dangerous/annoying" situations, but just curious about a few different things;
Originally by: CCP Masterplan
Drone grouping is a regular topic here. You've picked up on some of the areas we'd need to address. None are impossible to solve - this is on our list somewhere.


It seems like this would also remove the problem of drones set to "focus fire"... umm... not actually focusing fire when they switch targets. You said it is a regular topic and was on the list; is it just a comparatively small performance gain currently, so it hasn't been implemented yet?

Originally by: CCP Masterplan
Originally by: Salpun
The new fight on lag page places the smooth fleet fight limit at 600. What it does not say is if that is on a reinforced blade or not. Could you tell us? And the limit on the other blade type? Also with these new changes can you push that higher or do you have to have an actual fight on TQ that is with in standerd ie no lag to justify moving the number to the right.

Those numbers are based on a reinforced node. On a regular node, if all the other systems are empty, it will be almost the same as a reinforced node. It is impossible to say what a regular node will support in normal operation, as it all depends on what is happening in the other systems it is currently hosting.
Do you have any data on how usage grows in non-reinforced nodes with fights in multiple areas? From the sound of it, the change that was implemented brings performance down from the realm of about O ( N^2 ) to O ( N ) (yeah, I know you said it was N +/* M, but number of balls would seem to be ON AVERAGE directly related to number of players). Does the server now behave better handling 1 600 player fight than it does handling 60 10-player fights (since it would seem to negate much of the benefit of group updates)?

Originally by: CCP Explorer
Originally by: Daneel Trevize
Originally by: Black Dranzer
WHY WOULD YOU DO THAT?
Because premature optimization is evil, so first you get it to work, and then you have other things to do ugh
Indeed. First you write readable code that works. Then, based on measurements, you optimise the parts that need to be optimised.


o.0 I always found it helped a lot to draw up a rough high-level design doc in order to figure out a good/the best way to implement something, and that it actually saved me time in the long run because it let me break a problem down into smaller, easier problems that each took much less time (I suppose that being the whole point of object-oriented design). Am I missing something?

(Not trying to criticize, just it sounds like a different methodology than I've encountered before. I'm interested to understand the theory to find out if there's anything I could learn from it)

**

My own question: It seems like sending info on position for each missile to each client... well, really puts much more load on the server than need be. Why not send each client a dumbed-down "This person shot a missile at that object", let the client handle rendering missile flight and such, do all the position calculations and such server-side, and only sending the end result to the client? Admittedly, it does seem kind of hack-ish and might not be desirable in low-load situations but it seems like having a stripped-down mode available to switch to in extended high-use situations might not be the worst thing ever.

Are you concerned about unpredictable behavior from having modes that "switch"? Having to maintain two separate sets of code? Do you see sufficient room for improvement in current code that you expect optimizations to allow for fights as large as you would expect to see on-server?

Daneel Trevize
Gallente
Posted - 2010.12.18 18:45:00 - [147]
 

To me, the premature optimization argument is as follows:
E.g. you build a system to produce hash codes for objects (for hash table use), but you decide ahead of time that having the method recalculate the value on every call will be too inefficient so you decide you'll cache the result after the first call, and just ensure it's updated when the values of the object it's based upon change (e.g. in each set() methods).

Now you spend the time adding this slight complexity and you find a speed issue with your app, but if/when you benchmark & profile it, the worst patch isn't anywhere near this piece, or worse, your new data structures or algorithm are less efficient than a simpler method, perhaps due to unexpected physical cache interaction or other external factors.

So yes you could take each thing your code's doing and perhaps plan a more efficient & complex version from the beginning, but you could well be wasting time, overly complicating & limiting the implementation from the required specification, and even making your final code or algorithm cause even just 1 more cache miss per 50000 cycles, which could rival all otherwise speed improvements depending on if you're IO bound, etc.

Highfield
Caldari
I.M.M
Initiative Mercenaries
Posted - 2010.12.19 11:24:00 - [148]
 

Great work on the blogs CCP!

A question that sprang to my mind when I was reading all this: What would happen with the server if we decided to go head to head with the old-fashioned rusty RRBS or SniperBS fleets? All this repairing-to-code seems to apply to missile spam only, does it improve server behaviour with a lot of turretships as well?

BigSako
Posted - 2010.12.20 12:14:00 - [149]
 

very good, very nice to read! Thx for the good work and please continue posting stuff like this ;)

Pilk
Evolution
IT Alliance
Posted - 2010.12.22 16:20:00 - [150]
 

Originally by: Gnulpie
Edited by: Gnulpie on 12/12/2010 12:35:43
Good speedup, this is pretty impressive.


But why does the machoNet::SinglecastByClientID take that long? The Destiny::SendToClients without the SingleCast is only 7.4 ms! So the overhead is not in sorting out the data any more but in sending it. Is it possible to delegate this to a (highly) parallel worker thread which is doing all the work in the background (on other nodes maybe?) or do you get in trouble then with the non-blocking paradigm of Destiny?

Edit: Do you lookup always SessionID's from ClientID's in each SingleCast? That would be a huge waste in this case as they are almost always constant.

I would also propose that a multicast approach would be more appropriate, since a large number of clients are each receiving the same data. Obviously not IP multicast, but passing a piece of serialized data exactly once to the proxy layer, along with a list of clients which must receive it. If the concern is that people might be connected through different proxies, at least three possibilities suggest themselves:
  • Randomly choose a proxy server; this Sol sends a multicast to it:
    multicast("Ship #21 firing an EM smartbomb, ship #33 has stopped moving",[Joe,Billy,Bob,Sam,Reggie],master=true)
    . That proxy then sends to each other proxy:
    multicast("Ship #21 firing an EM smartbomb, ship #33 has stopped moving",[Joe,Billy,Bob,Sam,Reggie],master=false)
    (and parses and runs the multicast for its own connections). Implicitly, it is not an error, and is silently ignored, if a given recipient of a multicast is not connected to the proxy that received it.

  • From the Sol, contact every proxy and perform the same steps as above. Has the advantage that it can (more easily) be blocking to whatever extent is deemed necessary.

  • On the Sol, maintain a list of proxies through which players are connected; the list need not be minimal, just complete. As above, but only contact each proxy which actually has a player connected. This one scales better, and is my favorite of the three.

This closely mirrors a fundamental Google approach to cluster computing—namely, that it is rarely correct to select something. As an example, for certain classes of boolean search problems, it is expensive to evaluate their class so as to know which of several different algorithms to use to solve them. What Google does instead is launch all three of those algorithms simultaneously on three different machines; the first result to return is used, and the other two tasks are killed. So, in our case, if serialization is expensive, and if finding out to which proxy a given player is connected soaks up time, don't bother doing it.

--P


Pages: 1 2 3 4 [5] 6

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only