Pages: [1] 2 3 4 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 11 post(s) |
|
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.
Zymurgist Community Representative CCP Hf, EVE Online Contact Us |
|
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
CCP, holding Destiny by the balls while teasing the readers...
|
iP0D
|
Posted - 2010.12.10 16:11:00 -
[3]
Second
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 HYDRA RELOADED
|
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. Initiative Mercenaries
|
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
CCP, holding Destiny by the balls while teasing the readers...
not the balls
and 200 thin drakes, please tell me they were all named pancake!
|
SXYGeeK
Gallente do you -Mostly Harmless-
|
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 ! -We So SeXy |
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?
edit: can't wait for Part 2 _____________________________________________
'If you really want to make someone hate you, explain to them, logically and politely, why they are wrong' - J. Baylock |
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?
|
Kimiya Alhena
Eighty Joule Brewery Goonswarm Federation
|
Posted - 2010.12.10 16:46:00 -
[17]
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.
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) -- Team Gridlock: Herding electronic cats since 2010 |
|
Rakshasa Taisab
Caldari Sane Industries Inc. Initiative Mercenaries
|
Posted - 2010.12.10 16:54:00 -
[19]
Originally by: Cyaxares II ApplyPreStuff, AdditionsAndDeletions, ... are these actual method names from your server code?
OMG, they're using Java naming conventions!!! No wonder their code sucks balls. ;(
|
Obsidian Hawk
RONA Legion
|
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
Point of No Return Waterboard
|
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
Woopatang
|
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. I have nearly 8m SP in missiles.
Perhaps a Sansha or Angel BC please and thank you? ___
Chaotic Dreams |
Firartix
|
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? ------------------------ To make a megathron from scratch, you must first invent the eve universe.
|
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 RED Citizens
|
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. ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two |
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. ________
Originally by: CCP Mitnal If I ever need an alligator at 3am, I now know where to find one!
|
|
|
|
|
Pages: [1] 2 3 4 :: one page |
First page | Previous page | Next page | Last page |