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


 
Pages: [1] 2 3 4

Author Topic

CCP Zymurgist


Gallente
C C P
Posted - 2010.12.10 16:00:00 - [1]
 

CCP Masterplan is delighted to tell you about Destiny and lag's arch nemesis, Drakes, in his latest dev blog. Read more about our efforts to fix lag here.

Mashie Saldana
Minmatar
Veto Corp
Posted - 2010.12.10 16:02:00 - [2]
 

Edited by: Mashie Saldana on 10/12/2010 16:13:06
First Shocked

CCP, holding Destiny by the balls while teasing the readers...

iP0D
Posted - 2010.12.10 16:11:00 - [3]
 

Second Confused

Oh come on. Tease. Give us the second part of the blog!

Chewbaccious
Posted - 2010.12.10 16:11:00 - [4]
 

Edited by: Chewbaccious on 10/12/2010 16:12:15
EPic blog and thank you CCP for your commitment to reducing lag.


Trebor Whettam
Posted - 2010.12.10 16:16:00 - [5]
 

Evil cliff-hangers are evil.

Rhak Amharr
Minmatar
Genos Occidere
Pandemic Legion
Posted - 2010.12.10 16:22:00 - [6]
 

Edited by: Rhak Amharr on 10/12/2010 16:22:34
Originally by: Devblog
- Move balls according to their current action
- Resolve collisions between balls
n1 m8

Frozen T'amber
Posted - 2010.12.10 16:26:00 - [7]
 

Edited by: Frozen T''amber on 10/12/2010 16:27:07
wrong account dammit!
Nice blog.
Nicer facial hair.
and even greater ability to consume alcohol.

yay team gridlock.
I left one ball with hair on it, in honour of you all.


\o/

Rakshasa Taisab
Caldari
Sane Industries Inc.
Posted - 2010.12.10 16:28:00 - [8]
 

BeOS?...

Someone in CCP has a sick sense of humor.

Marcel Devereux
Aideron Robotics
Posted - 2010.12.10 16:31:00 - [9]
 

BeOS:: What's this?

Silen Boon
Posted - 2010.12.10 16:31:00 - [10]
 

While I applaud any effort to reduce lag.

My perception is that fleets will always increase to the size to the point where lag is used to tactic, where the lag favours one fleet over another.

Is there any evidence of the strategic use of lag and can anything be done about it?

Chainsaw Plankton
IDLE GUNS
IDLE EMPIRE
Posted - 2010.12.10 16:33:00 - [11]
 

Originally by: Mashie Saldana
Edited by: Mashie Saldana on 10/12/2010 16:13:06
First Shocked

CCP, holding Destiny by the balls while teasing the readers...


not the balls Shocked

and 200 thin drakes, please tell me they were all named pancake! Laughing

SXYGeeK
Gallente
do you
Posted - 2010.12.10 16:33:00 - [12]
 

Great Blog, Thx.
I enjoyed your stack :)

quite interesting to see just how much of the 1 second tick is soaked up with updating destiny balls.

second part soon I hope, you mean tease !

Monkey M3n
GK inc.
Pandemic Legion
Posted - 2010.12.10 16:35:00 - [13]
 

Edited by: Monkey M3n on 10/12/2010 16:35:50
most mega drake blobs don't group the missiles, because there goal is to cause more lag. So 3 groups of launchers isn't really replicating the REAL situation of the game. KTHX

Zaboth Garadath
Amarr
Ore Extraction Corporation
Posted - 2010.12.10 16:37:00 - [14]
 

Edited by: Zaboth Garadath on 10/12/2010 16:40:41
Now why am I poasting here before I actually read the devblog? Confused


edit: can't wait for Part 2 Very Happy

Chainsaw Plankton
IDLE GUNS
IDLE EMPIRE
Posted - 2010.12.10 16:40:00 - [15]
 

awwww you grab destiny's balls, and then leave destiny hanging

ccp is a cruel master

Cyaxares II
Posted - 2010.12.10 16:45:00 - [16]
 

ApplyPreStuff, AdditionsAndDeletions, ... are these actual method names from your server code? Laughing

Kimiya Alhena
Eighty Joule Brewery
Goonswarm Federation
Posted - 2010.12.10 16:46:00 - [17]
 

Edited by: Kimiya Alhena on 10/12/2010 16:49:18
Now we finally know why missile flight time varies by +- 1 second :)

I am a little shocked to see that the telemetry profile (and in general, the time spent in Pre-tick) suggests that almost all of the destiny update process is done serially. I would expect that at the very least, SendToClients could be sending updates to multiple clients at a time in parallel, and that you could begin the Evolve and Post-tick stages before SendToClients is complete (though I suppose that is not much of an advantage since those stages are so cheap). SendToClients seems like the sort of operation that would be spending most of its time waiting on cache misses and bus traffic, both of which should not prevent other threads from running, especially in a multicore environment.

Also, I'm surprised that missiles cause so much of an increase in observer cost. It seems like you could skip sending physics updates for missiles to clients outside of the initial 'missile launched' and final 'missile destroyed' events, since a player's only interaction(s) with a missile are to blow it up with a smartbomb or be hit by it. Clients could easily compute the current position of a missile based on its initial position+velocity and the current time, so at that point you are only left with the server-side cost of the missile's physics (apparently small?) and the cost of the initial launch event. Oh, and I suppose the cost of processing checks when smartbombs trigger to see if they've killed any missiles...

Kudos for the detailed update!

CCP Masterplan


C C P Alliance
Posted - 2010.12.10 16:50:00 - [18]
 

Edited by: CCP Masterplan on 10/12/2010 16:54:16
Originally by: SXYGeeK
Great Blog, Thx.
I enjoyed your stack :)

quite interesting to see just how much of the 1 second tick is soaked up with updating destiny balls.

second part soon I hope, you mean tease !

Glad you liked it. I was quite surprised too when I first saw a tick laid out like that. It is impressive how much a good visualisation tool can tell you.

Originally by: Chainsaw Plankton
awwww you grab destiny's balls, and then leave destiny hanging

ccp is a cruel master

I'm cruel because I love you
Originally by: Kimiya Alhena
Also, I'm surprised that missiles cause so much of an increase in observer cost. It seems like you could skip sending physics updates for missiles to clients outside of the initial 'missile launched' and final 'missile destroyed' events, since a player's only interaction(s) with a missile are to blow it up with a smartbomb or be hit by it. Clients could easily compute the current position of a missile based on its initial position+velocity and the current time, so at that point you are only left with the server-side cost of the missile's physics (apparently small?) and the cost of the initial launch event. Oh, and I suppose the cost of processing checks when smartbombs trigger to see if they've killed any missiles...

That is pretty much what happens - we tell the clients a missile has been launched, and what its target is. From there, the client can simulate the missile tracking towards the victim without any server-side interaction. We only need to send another update when the missile explodes (either by hitting the target, exceeding its flight-time, running into a smartbomb, or being taken out by defenders)

Rakshasa Taisab
Caldari
Sane Industries Inc.
Posted - 2010.12.10 16:54:00 - [19]
 

Originally by: Cyaxares II
ApplyPreStuff, AdditionsAndDeletions, ... are these actual method names from your server code? Laughing

OMG, they're using Java naming conventions!!! No wonder their code sucks balls. ;(

Obsidian Hawk
RONA Corporation
RONA Directorate
Posted - 2010.12.10 17:03:00 - [20]
 

Ok I hope i read this blog correctly


TL;DR version of blog - Caldari ships + missiles = more lag.


DmitryEKT
Clandestine.
Posted - 2010.12.10 17:06:00 - [21]
 

Remove missiles from the game. Have everyone use turrets. Problem solved.

gfldex
Posted - 2010.12.10 17:11:00 - [22]
 

Originally by: Kimiya Alhena
SendToClients seems like the sort of operation that would be spending most of its time waiting on cache misses and bus traffic, both of which should not prevent other threads from running, especially in a multicore environment.


That would indeed be reasonable if there wouldn't be the GIL. There is a reason why nobody beside CCP insists on using Python on a performance critical application.

Xaarous
Caldari
Woopatang
Primary.
Posted - 2010.12.10 17:14:00 - [23]
 

I'm interested to see how you sped up serialization ('thinner' format? Convert serialization to async? Build a FPGA? :)).

Usagi Tsukino
Stimulus
Rote Kapelle
Posted - 2010.12.10 17:14:00 - [24]
 

Edited by: Usagi Tsukino on 10/12/2010 17:15:35
Originally by: DmitryEKT
Remove missiles from the game. Have everyone use turrets. Problem solved.

I am not opposed to that if it means more SP reimbursement. Cool I have nearly 8m SP in missiles. Razz

Perhaps a Sansha or Angel BC please and thank you? Laughing

Firartix
Sense of Serendipity
Echoes of Nowhere
Posted - 2010.12.10 17:18:00 - [25]
 

I might be wrong, but according to what you said here and in the blog, the missiles only generate 2 events, client-server communication wise : the launch event, and the outofrange/destroyed/hit event
The turrets only have the hit part afaik

This makes the missiles only making 2x turret's lag ! Why is there such a diff between both ?

About the whole physics simulation deal, i'm probably wrong, but simulating hundred of missiles at a time seems quite heavy to me - compared to "just" communicating it to the clients.
Why don't you simply remove that whole mass/inertia for the missile and make it fly straight ? It doesn't seem to be making much difference, seeing how agile they are already..

Anyway, i'm waiting for part 2 ! :P

Jason Edwards
Internet Tough Guy
Spreadsheets Online
Posted - 2010.12.10 17:20:00 - [26]
 

More nerfing of lag. How about buff performance?

Kimiya Alhena
Eighty Joule Brewery
Goonswarm Federation
Posted - 2010.12.10 17:23:00 - [27]
 

Edited by: Kimiya Alhena on 10/12/2010 17:24:10
Originally by: gfldex
Originally by: Kimiya Alhena
SendToClients seems like the sort of operation that would be spending most of its time waiting on cache misses and bus traffic, both of which should not prevent other threads from running, especially in a multicore environment.


That would indeed be reasonable if there wouldn't be the GIL. There is a reason why nobody beside CCP insists on using Python on a performance critical application.
Not to derail, but as a member of the 'shipped commercial software using Python in performance critical code' club: the GIL only applies when python code is at the top of the stack. If you're blocked on a socket operation or kernel call there's no reason for the GIL to be held. Handling concurrent I/O is actually one of the things that Python does relatively well (at least compared to its inability to handle concurrent computation).

Of course, if the time spent in those functions is being spent doing serialization in Python or something, then yes, the GIL would explain it. In that case, ouch. :-(

Aika Achura
Posted - 2010.12.10 17:34:00 - [28]
 

Quick Fix Solution?

1. Reduce N launcher mount points on ships to 1.
2. Add missile damage multiplier of N to affected ship hulls.
3. Reduce turret mount points and high slots as needed for balance.

It would probably be a bit boring for the pilot though.

Hawk TT
Caldari
Bulgarian Experienced Crackers
Posted - 2010.12.10 17:37:00 - [29]
 

Originally by: Aika Achura
Quick Fix Solution?

1. Reduce N launcher mount points on ships to 1.
2. Add missile damage multiplier of N to affected ship hulls.
3. Reduce turret mount points and high slots as needed for balance.

It would probably be a bit boring for the pilot though.


Destiny is (probably) the only C++ server-side code being used...So, no GIL, no Python.

Lord's Prophet
Totally Abstract
O X I D E
Posted - 2010.12.10 17:39:00 - [30]
 

Originally by: Aika Achura
1. Reduce N launcher mount points on ships to 1.
2. Add missile damage multiplier of N to affected ship hulls.
3. Reduce turret mount points and high slots as needed for balance.
This doesn't take into account the smartbomb or defender mechanics, or ammo volume consideration (especially important for pos shoots etc), or fitting cpu/pg balance, overheating functionality, and a whole heap of other things which are based on there being multiple launchers. Also, having ungrouped launchers to shoot multiple targets simultaneously, while generally a bad idea, can be important in places. Your suggestion does not work.


Pages: [1] 2 3 4

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