EVE Search - New Dev Blog: Fixing Lag: Drakes of Destiny (Part 1)

Check My IP Information

All Channels

EVE Information Portal

New Dev Blog: Fixing Lag: Drakes of Destiny (Part 1)

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

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!

Jason Edwards Internet Tough Guy Spreadsheets Online	Posted - 2010.12.10 17:42:00 - [31] 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. That's what stacked guns did. ------------------------ To make a megathron from scratch, you must first invent the eve universe.
Durnin Stormbrow	Posted - 2010.12.10 17:44:00 - [32] Originally by: Silen Boon 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? I agree that given the current mechanics, fleet size is always going to chase the cap. Today, there is nothing that 500 players can do that 5,000 couldn't do faster if the node could handle it. The advantage of lag is simple: 'We're already here and have the grid loaded. Since the node is lagging, you can't come here and expect to live." Defenders that are expecting to loose a fight in a bad way can try to overload the node to the point that it dies. They may still loose in the chaos that follows, but that chaos is a better opportunity than the coordinated ass beating they were already taking. As for what to do about it, I think the answer there has to be more, smaller, distributed objectives and the concept of overkill. From a game performance perspective, having 2500 invaders and 2500 defenders fighting on 50 separate grids scales MUCH better than 5,000 combatants on 1 grid. By overkill, I mean that if an objective can be taken down with 10 dreads in one siege cycle, another 40 would be better spent on other objectives rather than dropping the 1st objective in 1/5th of the time and sitting idle for the rest of the siege cycle. In terms of game mechanics: If establishing sovereignty involved placing TCUs around the periphery of the system (not at POSes), and improving sovereignty involved many more TCUs, an invading fleet would have each of those TCUs as a separate objective. If dreads return to being king of the hill for killing fixed targets, and the TCUs are small enough that using more than [x] dreds does not get the job done faster, then the invaders at each objective would be limited to [x] dreds + a few more for buffer and whatever support/defense fleet and reactionaries was allocated to them. Defenders could choose to throw 1000 ships at defending a single objective, at the cost of ignoring every other objective being attacked. Invading a well entrenched system could still take hours and involve 1000s of players, but the battles would be broken down into many skirmishes that are easier for the node to handle, rather than 1 massive battle. As a bonus, smaller fleets would actually have objectives and 5-10 man cruisers roams might come to mean something if they can actually soften a system prior to an invasion.
Shasz New Eden Renegades	Posted - 2010.12.10 17:44:00 - [33] Fantastic blog! I love that visual profiling tool too. Thanks for sharing! I'm looking forward to part deux. ___________________________________
gfldex	Posted - 2010.12.10 17:59:00 - [34] Originally by: Hawk TT Destiny is (probably) the only C++ server-side code being used...So, no GIL, no Python. I would bet on C instead of C++. And the block post shows that Destiny ain't the problem. It's the code that is called after the C part is done. As soon as you get a callback from the C part to the Python part (and those are the reason you want to have a nice language instead of typing your fingers bleedy in C), you get hit by the GIL again.
Megan Maynard Minmatar Out of Order	Posted - 2010.12.10 18:10:00 - [35] So you are saying we can blame Drakes for lag. I'm totally ok with that. PERMABAN MISSILE BOATS, THEY ARE RUINING OUR GAME EXPERIENCE!!!!!!! Originally by: F'nog Originally by: Stareatthesun No no no ... Polaris is where CCP keeps the death star that will destroy eve when the servers shut down. Thankfully I've got Interceptors trained to V. S
Vincent Athena	Posted - 2010.12.10 18:32:00 - [36] I do not think placing multiple objectives about a solar system will do much to lag. The entire solar system runs on one node, so 2000 people in system are processed by one node whether they are in the same grid or scattered. Sure there will be a little improvement, some load comes from things that scale an N^2 of the objects in a grid. And player's fps would go up. In addition, many players would like to see the blob broken up. So multiple objectives would be a good move in any case. But you know how sometimes you get a large amount of lag when there is no one around, or even in your solar system? Its a big fleet fight happening in a system that happens to be on the same node as you.
Scharde Alton Aperture Ventures	Posted - 2010.12.10 18:33:00 - [37] Full disclosure: I spent several years working on real-time game communication middleware over fixed and mobile internet. You've probably already thought of this stuff, but I am an optimization nerd. You're spending most of the server cycles doing 2 things: 1. "figuring out which clients need to be informed" I suggest that you don't do this. Send the message to every client in the bubble and let them figure out whether or not it means a display update for them. This scales with the number of clients, and EVE is not a bandwidth hog (it's much more adversely affected by latency). 2. "Further investigation showed that this is mainly expensive due to the time required to serialise each update message." This sounds to me like you're packing the same object over and over again into the packet buffer. If true, this can be significantly improved by serializing once and using scatter/gather I/O to let the NIC driver do that work by DMA instead of loading down the CPU with it. Alternatively, this would be a ton of work but you could replace sending state objects with transactions.
Black Dranzer Caldari	Posted - 2010.12.10 18:40:00 - [38] So wait. You're telling me the physics engine runs at a simulation speed of one FPS? Okay, wow, this explains a lot. For one, it explains why "fly with your joystick" would be an absolutely terrible idea, even with astonishingly good interpolation/dead reckoning. Secondly, it explains why the "input delay" is so bad even given TCP/Server Authorization/Australia. Thirdly, it explains why missiles have a tendency to "double back" on their targets at the last second. Fourthly, it explains why everything seems to have a sort of "delayed but synced" feel to it. Fifthly, it explains why "warping in sync" actually happens in the frequency it does. Finally, it explains why pretty much nothing in Eve happens in a timescale of less than a second. Thought off the top of my head: Do you think it's possible that the size of the timestep is partially responsible for slowing things down? I know it seems counterintuitive; In most situations increasing the step frequency would just bog things down further. But it doesn't seem impossible that a good portion of calculation time is burnt up in compensating for the "fuzzyness" of large timesteps. Alternatively, maybe it's in part the other way around; There might be computations that are done once a second that really don't have to be. Of course, variable sized timesteps for multiple interlocking things would be an enormous pain in the ass. But I'll stop talking out of my ass now. Good blog! I very much look forward to the next one. \|24 Hour Plex\|Mining Makeover\|
Lutz Major Austriae Est Imperare Orbi Universo	Posted - 2010.12.10 18:48:00 - [39] Originally by: Marcel Devereux BeOS:: What's this? Without googleing ... yes kids we have brains to memorize! If it is the original BeOS, then it was introduced, what? 12-15 years ago. As - what else - Windows killer. Back then it had already 64bit ability and was determined to do extreme multitasking. It performed better in Multimedia than any windows or linux back then. I wonder if CCP really uses the OS from back then ...
Marcel Devereux Aideron Robotics	Posted - 2010.12.10 18:54:00 - [40] Originally by: Lutz Major Originally by: Marcel Devereux BeOS:: What's this? Without googleing ... yes kids we have brains to memorize! If it is the original BeOS, then it was introduced, what? 12-15 years ago. As - what else - Windows killer. Back then it had already 64bit ability and was determined to do extreme multitasking. It performed better in Multimedia than any windows or linux back then. I wonder if CCP really uses the OS from back then ... I know what BeOS is (I worked at Be on BeOS and BeIA). I'm just curious to know what CCP named BeOS.

ElfeGER Deep Core Mining Inc.	Posted - 2010.12.10 19:22:00 - [41] congrats on finding a runtime profiler
Nareg Maxence Gallente	Posted - 2010.12.10 19:33:00 - [42] Very good blog. Massive props for the BTTF reference.
Gecko O'Bac Deep Core Mining Inc.	Posted - 2010.12.10 19:38:00 - [43] Originally by: ElfeGER congrats on finding a runtime profiler I guess your application to CCP is well on its way and you're about to become team lead for gridlock? Damn smartasses. That said: Tech **** blog. Me loves. I'm just not sure I understood a thing... You said in the blog that "we can't do any asynchronous operations such as database queries or anything that might cause execution to yield." But... aren't asynchronous calls non blocking by default? I mean, that's how I usually use that term: I make an asynchronous request and go on doing my stuff... I guess you may want to avoid execution of call backs as well if your code is entirely single threaded... Perhaps that's what you meant?
Elsa Nietzsche	Posted - 2010.12.10 19:49:00 - [44] Edited by: Elsa Nietzsche on 10/12/2010 19:49:47 how long do we have to wait for part 2?
gfldex	Posted - 2010.12.10 20:09:00 - [45] Originally by: Elsa Nietzsche Edited by: Elsa Nietzsche on 10/12/2010 19:49:47 how long do we have to wait for part 2? Until it is written and signed of by a superior. What means neither of the two parties involved can provide any meaningful answer, because one depends on the other.
Epitrope The Citadel Manufacturing and Trade Corporation	Posted - 2010.12.10 20:26:00 - [46] Originally by: Black Dranzer Thought off the top of my head: Do you think it's possible that the size of the timestep is partially responsible for slowing things down? I know it seems counterintuitive; In most situations increasing the step frequency would just bog things down further. But it doesn't seem impossible that a good portion of calculation time is burnt up in compensating for the "fuzzyness" of large timesteps. Alternatively, maybe it's in part the other way around; There might be computations that are done once a second that really don't have to be. Of course, variable sized timesteps for multiple interlocking things would be an enormous pain in the ass. I actually came up with a similar idea a while ago, and I've always been curious about why EVE isn't set up this way. A node dies when it starts to consistently miss its heartbeat, right? And it misses its heartbeat when it can't do a tick's worth of computation in 1 second. So: under heavy load, why not up a tick to 2 seconds? Send out an update to all the clients, and make everything that happens on that node take twice as long. This, it seems to me, would scale to any number of players (so long as those players are patient)... if it takes longer than 2 seconds to do a tick, go up to 3 seconds/tick, and so on. I would think that most players would prefer a slower but working solar system than a faster broken one, and it means that a node would never have to die again. Has this idea been considered? If so, why has it been rejected?
Gecko O'Bac Deep Core Mining Inc.	Posted - 2010.12.10 20:36:00 - [47] Originally by: Epitrope Originally by: Black Dranzer Thought off the top of my head: Do you think it's possible that the size of the timestep is partially responsible for slowing things down? I know it seems counterintuitive; In most situations increasing the step frequency would just bog things down further. But it doesn't seem impossible that a good portion of calculation time is burnt up in compensating for the "fuzzyness" of large timesteps. Alternatively, maybe it's in part the other way around; There might be computations that are done once a second that really don't have to be. Of course, variable sized timesteps for multiple interlocking things would be an enormous pain in the ass. I actually came up with a similar idea a while ago, and I've always been curious about why EVE isn't set up this way. A node dies when it starts to consistently miss its heartbeat, right? And it misses its heartbeat when it can't do a tick's worth of computation in 1 second. So: under heavy load, why not up a tick to 2 seconds? Send out an update to all the clients, and make everything that happens on that node take twice as long. This, it seems to me, would scale to any number of players (so long as those players are patient)... if it takes longer than 2 seconds to do a tick, go up to 3 seconds/tick, and so on. I would think that most players would prefer a slower but working solar system than a faster broken one, and it means that a node would never have to die again. Has this idea been considered? If so, why has it been rejected? From what we know, I doubt this would solve the problem (unless there really are computations that are unneeded for a 1 s timestep). See, the problem is not exactly that if you don't complete the tasks in 1 second you miss the beat... It's that we're using 100% of the resources of the node (CPU first... Dunno if memory gets loaded as well... Perhaps jita is more of a high memory lower cpu usage kind), so the computations simply start being queued until the point where they simply timeout due to the amount of backlogged work. Augmenting the size of the timestep would perhaps let the server "live" longer (the hearbeat pulse though is sent 2 times per minute IIRC), but I doubt it'd make the lag any better.
Hoshi The Einherjar Corporation	Posted - 2010.12.10 20:51:00 - [48] Originally by: Scharde Alton 1. "figuring out which clients need to be informed" I suggest that you don't do this. Send the message to every client in the bubble and let them figure out whether or not it means a display update for them. This scales with the number of clients, and EVE is not a bandwidth hog (it's much more adversely affected by latency). Then you place too much trust in the client which will be hacked to display what is happening on the other side of the solarsystem. Who needs the scanner when you tell the client the exact position/heading/speed of every single object in the system. ---------------------------------------- "Memories are meant to fade. They're designed that way for a reason."
Aineko Macx	Posted - 2010.12.10 21:15:00 - [49] OMG they DO have a profiling tool Sarcasm aside, this... Quote: 2) Sending an update to each client identified in the step above. Further investigation showed that this is mainly expensive due to the time required to serialise each update message. (Serialising means converting a data structure in memory into a stream of bytes that can be sent over a network) ... sounds like an excellent candidate for parallel execution to me. The data set is static at this point, so spawn a bunch of worker threads and have them deal with serializing & sending it to clients in parallel. You could go further and cache the serialized data fragments that get sent repeatedly. ________________________ CCP: Where fixing bugs is a luxury, not an obligation.
Scharde Alton Aperture Ventures	Posted - 2010.12.10 21:16:00 - [50] Originally by: Hoshi Originally by: Scharde Alton 1. "figuring out which clients need to be informed" I suggest that you don't do this. Send the message to every client in the bubble and let them figure out whether or not it means a display update for them. This scales with the number of clients, and EVE is not a bandwidth hog (it's much more adversely affected by latency). Then you place too much trust in the client which will be hacked to display what is happening on the other side of the solarsystem. Who needs the scanner when you tell the client the exact position/heading/speed of every single object in the system. You don't actually run this risk, because the clients in the same bubble not solarsystem. In other words, on grid and already available for you to see.

trjcquee	Posted - 2010.12.10 21:34:00 - [51] Fascinating stuff. I should like to point out that once you decide what messages need to be sent to what clients, the task of serializing the data into packets is one that is ripe for parallelization. Another CPU core could take on this job in a separate thread. Unfortunately this is exactly where Python fails: the ability to use multiple CPU cores in parallel. Stackless Python doesn't really help in this case, because the lightweight threads it uses are really only simulations of honest-to-goodness threads of execution. Those "threads" are not capbable of running on separate cores in parallel. In a way, you might say they're not even in the same ballpark. (rimshot thank you, I'll be here all week) Good to see you folks finally waking up and smelling the coffee. Too bad you're kinda stuck with Python.
trjcquee	Posted - 2010.12.10 21:49:00 - [52] 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. Exactly. The limiting factor here is Python, which is pretty much bound to a single CPU core.
Antihrist Pripravnik 4S Corporation Morsus Mihi	Posted - 2010.12.10 21:51:00 - [53] How about replacing missiles with some kind of "mines" that are launched from current missile launchers. 1) Launch a missile (mine) at a target 2) Calculate damage time delay based on positions and speed vectors of the targets 3) When the time is out, check the target's position and speed vector 4) If the target is in "range", detonate (before you mention "range" in a reply, see point "c)" in the next paragraph) 5) Apply damage reduction based on target's properties at the point of the explosion (speed, signature radius,...) Of course some game mechanics have to change: a) Remove or modify defenders. Remove is viable because no one use them anyway (except NPCs in missions). Modification can be done by introducing a new high slot module that can "remove" some of the new mines attached to the ship (keep the skill "Defenders" and apply it to performance of the new module) b) Smartbombs can't hurt missiles any more, but seriously... who relies on the exact time of activation of a smartbomb for fighting against missiles (ecxept forum trolls ofc.) c) Balance the new "mines" (missiles) so that they are doing roughly the same damage (or no damage) to the same type of targets as they are now It's just some of my thoughts about the "ball spam" issue. Something like this might help, because it will remove missile balls from the game. Disclaimer: This is just a few random thoughts, not an actual suggestion, cry, rage or anything like that. If I wanted to suggest this, I would post it in the Features & Ideas section of the forum. And yes, I am mainly a Caldari missile pilot. Nice blog btw. Waiting for the second part
Jas Dor Minmatar	Posted - 2010.12.10 21:57:00 - [54] Edited by: Jas Dor on 10/12/2010 21:57:41 Personally, I think there is only one answer to blobing, have shields "flare" and render the target invulnerable to everything but the highest damage hit in a tick. I suspect though that this would cause to much server overhead.
ArchenTheGreat Caldari Nomads of Zen	Posted - 2010.12.10 22:17:00 - [55] Originally by: Cyaxares II ApplyPreStuff, AdditionsAndDeletions, ... are these actual method names from your server code? Those are names of timers not functions. Also: awesome blog, more techy stuff please.
Palovana Caldari Inner Fire Inc.	Posted - 2010.12.10 22:24:00 - [56] 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. What they will be doing is making all missiles do 2x the damage but have only 1/2 the rate of fire - easiest way of taking out half of the balls in play.
Lord's Prophet Totally Abstract O X I D E	Posted - 2010.12.10 22:46:00 - [57] Originally by: Palovana What they will be doing is making all missiles do 2x the damage but have only 1/2 the rate of fire - easiest way of taking out half of the balls in play. This has all kinds of other balance issues. Defenders will become much more viable if there are only half as many missiles in flight. More defender = more missiles = waste of time using this as a fix. The other thing is cargo space. If you're doubling the damage per missile you effectively double the ammo capacity of all missile-based ships. This is important for long engagements such as POS bashing. If you then reduce their cargoholds, this will affect active-tanking setups which use cap boosters. You would have to change the volume that missiles take in cargo, which will in turn affect people who build missiles. What about the T2 BPO holders, suddenly each missile is twice as effective, so prices will go up? Are you going to change how many missiles they get per run, or how long it takes to make 1 run? Also, as yet another consequence, this will affect overheating, as heat damage is only added at the end of the module's cycle, and if it's being hot between damage additions this is going to cause much more unpredictable heat distribution, which is another bad thing... Basically, the 'make it more marauder-like' is a half-baked answer which causes more problems than it solves. ________ Originally by: CCP Mitnal If I ever need an alligator at 3am, I now know where to find one!
Hoshi The Einherjar Corporation	Posted - 2010.12.10 23:21:00 - [58] Originally by: Scharde Alton Originally by: Hoshi Originally by: Scharde Alton 1. "figuring out which clients need to be informed" I suggest that you don't do this. Send the message to every client in the bubble and let them figure out whether or not it means a display update for them. This scales with the number of clients, and EVE is not a bandwidth hog (it's much more adversely affected by latency). Then you place too much trust in the client which will be hacked to display what is happening on the other side of the solarsystem. Who needs the scanner when you tell the client the exact position/heading/speed of every single object in the system. You don't actually run this risk, because the clients in the same bubble not solarsystem. In other words, on grid and already available for you to see. From the description in this blog it doesn't sound like that. The "figuring out which clients need to be informed" step are most likely finding out which clients are inside the grid, otherwise it would be a pointless step as every client inside will always need to be informed destiny changes. There are no clients inside the grid that doesn't need to know when a missile is fired or when a ship changes direction or explodes. ---------------------------------------- "Memories are meant to fade. They're designed that way for a reason."
Apollo Gabriel Brotherhood Of Fallen Angels Etherium Cartel	Posted - 2010.12.10 23:37:00 - [59] Originally by: Monkey M3n 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 You are making eve worse, Please leave. L2Read its good, you can move out of mom's basement. Apollo ====================================== Do you really care what trolls say? If yes, please take a break and head outside, it helps. ======================================

CCP Explorer	Posted - 2010.12.10 23:49:00 - [60] Originally by: Firartix 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 ? Turrets only incur damage tracking calculation cost. Missiles incur physics simulation and damage tracking calculation cost. The physics simulation is actually relatively cheap but constantly adding new objects into the simulation and removing them again is the part that adds up. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games



CCP Explorer	Posted - 2010.12.10 23:51:00 - [61] Originally by: Black Dranzer So wait. You're telling me the physics engine runs at a simulation speed of one FPS?Yes, EVE ticks at 1 Hz. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games


CCP Explorer	Posted - 2010.12.10 23:53:00 - [62] Originally by: Lutz Major Originally by: Marcel Devereux BeOS:: What's this? Without googleing ... yes kids we have brains to memorize! If it is the original BeOS, then it was introduced, what? 12-15 years ago. As - what else - Windows killer. Back then it had already 64bit ability and was determined to do extreme multitasking. It performed better in Multimedia than any windows or linux back then. I wonder if CCP really uses the OS from back then ... BeOS stands for BlueOS Object. Maybe that answer doesn't help... Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games


CCP Explorer	Posted - 2010.12.10 23:54:00 - [63] Originally by: Elsa Nietzsche how long do we have to wait for part 2? It will be published tomorrow. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games


CCP Explorer	Posted - 2010.12.10 23:56:00 - [64] Originally by: Hoshi Originally by: Scharde Alton 1. "figuring out which clients need to be informed" I suggest that you don't do this. Send the message to every client in the bubble and let them figure out whether or not it means a display update for them. This scales with the number of clients, and EVE is not a bandwidth hog (it's much more adversely affected by latency). Then you place too much trust in the client which will be hacked to display what is happening on the other side of the solarsystem. Who needs the scanner when you tell the client the exact position/heading/speed of every single object in the system. Exactly. We have to assume that we can't trust the client. The server must be authoritative and only send relevant information to each client. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games

Breaker77 Gallente Reclamation Industries	Posted - 2010.12.11 00:04:00 - [65] Edited by: Breaker77 on 11/12/2010 00:04:30 Originally by: CCP Zymurgist lag's arch nemesis, Drakes Wouldn't the easiest solution be to cut the shields in half and remove 4 mid slots? I'm pretty sure that would end all drake use thus solving lag.
Epitrope The Citadel Manufacturing and Trade Corporation	Posted - 2010.12.11 00:44:00 - [66] Originally by: Gecko O'Bac From what we know, I doubt this would solve the problem (unless there really are computations that are unneeded for a 1 s timestep). See, the problem is not exactly that if you don't complete the tasks in 1 second you miss the beat... It's that we're using 100% of the resources of the node (CPU first... Dunno if memory gets loaded as well... Perhaps jita is more of a high memory lower cpu usage kind), so the computations simply start being queued until the point where they simply timeout due to the amount of backlogged work. Augmenting the size of the timestep would perhaps let the server "live" longer (the hearbeat pulse though is sent 2 times per minute IIRC), but I doubt it'd make the lag any better. Perhaps I explained poorly. I'm not suggesting changing only the tick size, but actually changing the simulation speed along with it. Under heavy load, run everything at 50% of normal, which gives twice as long to do the same work. Queued work wouldn't time out, modules would activate in a timely fashion, and in general the game would keep working instead of breaking. If that's still not time enough to do the work that needs to be done, run the simulation at 1/3 speed, or 1/4 speed, and so on. You're right that this wouldn't address memory usage issues. Slowing things down to swap isn't a good solution, but as I understand it memory's not usually the problem, CPU is. I believe that this would be a way to degrade gracefully, which would make larger fleet fights more playable with the kind of lag issues like missiles that Gridlock is optimizing, both now and in the future.
Tonto Auri Vhero' Multipurpose Corp	Posted - 2010.12.11 00:57:00 - [67] Edited by: Tonto Auri on 11/12/2010 01:01:42 Originally by: Epitrope Perhaps I explained poorly. I'm not suggesting changing only the tick size, but actually changing the simulation speed along with it. Under heavy load, run everything at 50% of normal, which gives twice as long to do the same work. Queued work wouldn't time out, modules would activate in a timely fashion, and in general the game would keep working instead of breaking. If that's still not time enough to do the work that needs to be done, run the simulation at 1/3 speed, or 1/4 speed, and so on. You're right that this wouldn't address memory usage issues. Slowing things down to swap isn't a good solution, but as I understand it memory's not usually the problem, CPU is. I believe that this would be a way to degrade gracefully, which would make larger fleet fights more playable with the kind of lag issues like missiles that Gridlock is optimizing, both now and in the future. Actually, you're speaking of increasing simulation speed. Not to leap into the future, but to reduce amount of iterations over bigger period. To clarify, take an example of 10 min battle. Normally, it's 600 ticks of time. If Destiny fails to process all events inside the tick, then switch tick length to 2 seconds AND calculate all events that would happen in these 2 seconds, so do only 300 ticks in the same 10 minutes, but still process all the events that should happen. As everyone saw in the blog, the time spent on actual calculation is minimal, so increasing tick length AND calculated period shouldn't cause major issues. The only problem, client engine must be ready for this speed stepping. All this does not exclude the need to reduce unnecessary notifications sent to clients. P.S. @CCP: Have you considered reworking POS mess on the same modular ground as Outposts work now? Would as well create more pleasing environment handling containers et all - with one POS representing only one container instead of each module having it's own container... -- Thanks CCP for cu
Aurelia Valeron	Posted - 2010.12.11 01:05:00 - [68] Originally by: CCP Explorer Originally by: Firartix 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 ? Turrets only incur damage tracking calculation cost. Missiles incur physics simulation and damage tracking calculation cost. The physics simulation is actually relatively cheap but constantly adding new objects into the simulation and removing them again is the part that adds up. I assume you are using a preexisting pool of physics objects (missile objects, I suppose) which are recycled instead of allocating / destroying physics objects on the fly?
Epitrope The Citadel Manufacturing and Trade Corporation	Posted - 2010.12.11 01:23:00 - [69] Originally by: Tonto Auri Actually, you're speaking of increasing simulation speed. Not to leap into the future, but to reduce amount of iterations over bigger period. To clarify, take an example of 10 min battle. Normally, it's 600 ticks of time. If Destiny fails to process all events inside the tick, then switch tick length to 2 seconds AND calculate all events that would happen in these 2 seconds, so do only 300 ticks in the same 10 minutes, but still process all the events that should happen. As everyone saw in the blog, the time spent on actual calculation is minimal, so increasing tick length AND calculated period shouldn't cause major issues. The only problem, client engine must be ready for this speed stepping. All this does not exclude the need to reduce unnecessary notifications sent to clients. I understand what I'm saying, and I believe I understand what you're saying, and they're not the same. There will always be larger fleet fights than the server can handle. Right now, the pre-tick client updates step(s) are taking up most of the time. You're right that fewer, bigger ticks would allow the server to send out fewer, bigger updates, which would cause the clients to run at full speed but somewhat jerkier as updates are coming in half as quickly but with twice as much data. However, as optimization work continues, perhaps that section won't dominate the tick quite so much and the evolve step will take a larger percentage, in which case fewer bigger ticks won't work as well. Your suggestion is, from the information made available to us, a good one. It lessens the lag problem as it exists right now. My suggestion of slowing down the simulation speed is more of a way to keep the game somewhat playable with any lag, current or future, regardless of cause or nature. It's a way to degrade more gracefully than the way high-load nodes degrade do now.
Daneel Trevize Black Viper Nomads	Posted - 2010.12.11 02:02:00 - [70] Can you not lock something quicker than a second/tick? Can you ever lock something that mwd+cloaks within the same second/tick that you ctrl+click to lock them with a preactivated point/other mods? I guess this also covers why you can cloak then mwd soon enough after and still get the speed boost..?

Infinion Caldari Endless Destruction Imperial 0rder	Posted - 2010.12.11 02:40:00 - [71] Originally by: Daneel Trevize Can you not lock something quicker than a second/tick? Can you ever lock something that mwd+cloaks within the same second/tick that you ctrl+click to lock them with a preactivated point/other mods? I guess this also covers why you can cloak then mwd soon enough after and still get the speed boost..? I think it also has to do with the question of: can you react fast enough to lock the target and have your client send a call to the server while waiting for your scan resolution all before the target simply makes a call to move and cloak? If it wasn't for scan resolutions, this would probably be possible. as for cloaking and mwding, the server purposefully waits around 3-5 seconds before making module activation illegal, so I do not believe it is a limitation in the programming rather than an intended game mechanic to give cloakers an advantage at escaping.
Escoce Gallente Interstellar Tritanium United Trade Syndicate	Posted - 2010.12.11 03:44:00 - [72] I see no one has commented on the most important part of this post. The reference to "Back to the Future"....I had a great laugh when I reached that part of the post. Thanks :) Escoce Low Sec Miner and Trader Interstellar Tritanium United Trade Syndicate
Patyrn Runner	Posted - 2010.12.11 06:12:00 - [73] So cool, and you guys are hiring! Now if only I was twice as smart and had some qualifications...
Rip Minner Gallente ARMITAGE Logistics Salvage and Industries	Posted - 2010.12.11 07:41:00 - [74] The man with the Masterplan left me hanging Other then that very nice blog and keep up the awsome work guys Is it a rock? Point a Lazer at it and profit. Is it a ship? Point a Lazer at it and profit. I dont realy see any differnces here.
Louis deGuerre Gallente Amicus Morte Dead Muppets	Posted - 2010.12.11 10:07:00 - [75] I want some GridLock's Special-Love ! ----- Amicus Morte is recruiting. Dive into the world of 0.0 !
Pol Hald	Posted - 2010.12.11 10:36:00 - [76] Excellent devblog, thanks. Waiting for part two :)
Ab Tallen The Alphabet Soup	Posted - 2010.12.11 10:41:00 - [77] Originally by: CCP Explorer Originally by: Hoshi Originally by: Scharde Alton 1. "figuring out which clients need to be informed" Then you place too much trust in the client which will be hacked to display what is happening on the other side of the solarsystem. Who needs the scanner when you tell the client the exact position/heading/speed of every single object in the system. Exactly. We have to assume that we can't trust the client. The server must be authoritative and only send relevant information to each client. Does anyone besides the actual target need to know any details of the missile's life anyway?
DmitryEKT Point of No Return Waterboard	Posted - 2010.12.11 12:15:00 - [78] Originally by: Ab Tallen Does anyone besides the actual target need to know any details of the missile's life anyway? Missiles can be destroyed by AOE, so it has to tell everyone on grid, because a ship can for example be a warpin for a fleet member with smartbombs, etc, and therefore everyone has a need to be able to see the missiles.
Rufus Asgori	Posted - 2010.12.11 12:55:00 - [79] Edited by: Rufus Asgori on 11/12/2010 12:57:00 well, some programmers talk: As you¦re already talking bout observers i guess the related pattern is in some way involved, as the task pretty much calls for it. If the generation of the outputstream really is an issue you might consider giving all info to all observers, increasing the stream but decreasing the numbers of different streams to one per "grid" an let the observers decide which info is meant for them? There should be enough bandwidht avaiable throughout the eve playing world. Like sending all moving objects and all bubble stuff to all clients and then requesting a small sh/ar/str speed and modules stream for each ship, giving data or the "oups, you are dead" stream back. Might be a cool playground for some freaking visitor stuff also, as your data structure for objects sounds pretty stable, with all your bubble and sphere stuff. damn i¦d like to see that code Rufus
Ariz Black	Posted - 2010.12.11 13:34:00 - [80] If the main reason the node gets laggy, is that it has to figure out who to tell about the added/removed balls, why not just do something like: 1. find another node that's not doing much at the moment 2. send that node a list of all the events, and who's in which grid 3. have the idle node do the figuring out out of which info to send to who, and have it do that this way the node the combat is taking place on can just keep track of the important stuff and the client notification is handled by a less busy node dunno if it would work like that but hey makes sense to me, at least kinda


CCP Masterplan C C P Alliance	Posted - 2010.12.11 14:24:00 - [81] Thanks for all the reponses. To address some topics without mass quoting, I'll try to group things together Quote: On making SendToClients truly miltuthreaded This isn't something we've ruled out. We do have some broadcast mechanisms where this could be slotted in. Quote: On merging all missile launchers to a single item Well this is kind of what happens when you group your turrets. It does indeed provide a nice saving on the CPU cost of missiles (so please use it where possible!) Changing things to be more Marauder-like doesn't seem to be the way to go to me - it would ripple out to touch too many other areas Quote: On turning missiles from physical entities into effects This is what we've done with Fighter Bombers (See CCP Chronotis' blog) So, could we do this for all missiles? Well, yes. But there would be some drawbacks. Firstly it would require a lot of re-balancing: Defenders would become obselete (and there are a lot of NPCs that use them) Secondly we would lose the ability for creative tactics such as the smartbomb firewall. Thirdly I think that having missiles use a distinctly different mechanic from turrets keep things more interesting. I think it is pretty cool that an interceptor can have a string of slow missiles trailing him, knowing as long as he keeps moving quickly , they will simply never catch up. The fact that the outcome is not determined until when (if?) the missile reaches a target is a good thing. [This last paragraph is me-as-a-player. In turn this motivates me-as-a-dev to make missiles performant enough that we don't need to turn them into effects] Quote: On Destiny as C/C++? It is C++. Python and C++ work nicely together, as we have ways of making the same underlying object appear as a native object in both languages at the same time. There are several other systems that are also implemented as C++ (or a Python/C++ mixture) - Trinity (the graphics engine) is probably the most obvious. -- Team Gridlock: Herding electronic cats since 2010


CCP Masterplan C C P Alliance	Posted - 2010.12.11 14:24:00 - [82] Edited by: CCP Masterplan on 11/12/2010 14:24:49 Quote: On skipping the 'figure out which clients need to be informed' step, and just broadcast to everyone in the bubble? This would indeed save some work, but as CCP Explorer pointed out, would also open up exloit potential. Imagine the case where you have a few cloaked and uncloaked ships on a gate, and a few more cloaked and uncloaked ships warp into that bubble. (Remember that if you are flying a cloaked ship, the updates you receive must include your own ship) Now, remembering the client is in the hands of the enemy, you should be able to imagine ways to exploit this if everyone had the same update. Quote: On 1Hz updates? Yup. It has always been that way. This is why a form of direct-flight joystick control simply wouldn't work in EVE. If you look are the tick rate of other games, from FPS up to MMO, there is roughly an inverse relationship between tick-rate and number of players that can gather together. Quote: On the BTTF reference I couldn't miss up an opportunity to do this :) (BTW there are a few other more obscure references to other things scattered in this blog and the second half as well...) Quote: On slowing down time / increasing the tick period This is something we've considered, along with a number of other bigger-scale changes that we've discussed. Some we quickly eliminated beacuse they wouldn't actually fix the issue. Some we've got on the board as potentials. Some we've even protoyped. Looking specifically at the slowing-down-time idea, this has received quite some attention. Some things to think about: What things should be slowed down? (Shield recharge, rate-of-fire, movement, skill-training, market order duration, aggression times, siege cycles...) Suddenly when you have two clocks running at different rates, you have to look at every single mechanic that is in some way related to time. What about other solar systems on the same node - should they slow down too? If we try to let different systems on a node run at different rates, it means we potentially have to keep track of which system a particular function call is dealing with, in case it needs to query a timer. I'm not saying all of this is impossible, simply that there is a lot more to it than you might initially think. (Take this as a sign that this is indeed an idea that has received attention) Quote: On why did I choose 3 launchers - why not 1 or 7? Simply because it was a reasonable midpoint. Seven launchers would have made the before/after difference more significant, but wouldn't change the basic result. One launcher would have meant the missile load was smaller relative to everything else and I wouldn't have been able to so easily see where I needed to be focusing my attention. Quote: On part two - when? First you will need to learn patience. And also where the F5 key is... -- Team Gridlock: Herding electronic cats since 2010

Dunpeal Caldari Caldari Provisions	Posted - 2010.12.11 14:34:00 - [83] Originally by: Rufus Asgori If the generation of the outputstream really is an issue you might consider giving all info to all observers, If you let the client decide if the update is relative to itself, wouldnt that allow for client hacking and purposefully making a client wich cannot die? I mean Client gets shot at, server talks to it and says "Youve been shot and it killed you", client then responds, "dead ship was not me", in wich the server would then get a data stream back from a client that suposedly no longer takes part of the simulation wich continues to input data although the server says it is dead. Even if the client does not directly affect the simulation it will continue to affect the speed of the simulation by constantly taxing the server with input that the server will have to identify as being true or false, if the server code where prepared to handle those bad calls, one hacked client would probably not do much but hundreds probably would, therefore making that solution actually a new problem. Originally by: Ariz Black If the main reason the node gets laggy, is that it has to figure out who to tell about the added/removed balls, why not just do something like: 1. find another node that's not doing much at the moment 2. send that node a list of all the events, and who's in which grid 3. have the idle node do the figuring out out of which info to send to who, and have it do that this way the node the combat is taking place on can just keep track of the important stuff and the client notification is handled by a less busy node dunno if it would work like that but hey makes sense to me, at least kinda If i remenber correctly the reason for CCP to not do this is keeping things within sync. Offloading those calculations would create overhead in order to send the stuff, and making sure the transfer, running of the code and completion would keep in sync with the next tic. After wich the first node would be receiving new input to be resolved, where if the first input was not already resolved sent and received by clients before new input is returned to the first node, the simulation would infact be invalid at that point because clients where sending invalid input. P.S: Please disregard if what i said does not make sense, only basic knowledge of programming here. ------------------------------------------------- My Past, my destiny...
Deep1	Posted - 2010.12.11 14:35:00 - [84] Lovely - so that is what you send the time on - keep it coming :-) With all that time spending on Clientupdates why not move that OUT of Destiny ? Have Destiny create a client cache/node that send updates to clients so that Destiny can take a break ( by just sending ONE update not 300 or 1000+). Since this would be new code make it so it can be done on the fly. make it a bit smart and let that part desite if a client need or can get the update ( eq cloaking ships etc). Tell the Player client what update-node that handles his/her request on enter System or grid/bubble. And to the more complex part: 1) On node load create one node of a small size ( say 30-50 max ) 2) If more than max clients enters system tell Destiny - and get new Updatenode 3) The extra nodes are create of a larger max Size say 100-200. All UpdateNodes must keep track of it current state so count time of one update cycle At startup of the node a value of 10 is set. If the update time is higher than 70 % and value is less than 20 - increment value by 1. If the update time is lower than 70 % and value is more than 0 - decrement value by 1. this would give a track over 10 ticks so we don't overreact on spikes - and it does not take into account any other process running on that node - just tells us what we need if the work is done in a god manner. what it don't take into accounts is that a update cycle may go dead ( take a long time to complete eq 10 mins or more ). 4) any extra update nodes should be created on the CPU with the lowest current use - i believe that you have that info. Next Cleanup - it really don't make any sense that a fleet travel vs 20 system should leave 20 systems with 10 extra nodes when they are all back in station. So i would do some cleanup every 5 mins. If a system only has one node - exit .. If there is One extra Updatenode and it has less than 10 % of max user AND there is room for it in the Start node - move users ( tell new Update node to them ) and Kill the extra node. If there is more than one UpdateNode check nodes and if more than one has less than 30 % users try to merge buy moving users to the newest node. Deep1
Cpt Wisdoom	Posted - 2010.12.11 15:11:00 - [85] Just fix Drake itself, make it balanced already. Balanced Drake = less popular Drake = less Drakes in space = less missiles fired = less lags! No more drake swarms = everybody happy! I think that it is a best solution.
Nevryn Takis	Posted - 2010.12.11 15:23:00 - [86] My first reaction on reading elements of this is that the object model for the ball is wrong. Additionally if you're mixing C++ and python I'm assuimg that the C++ elements are bolted into the python kernal as library elements are are therefore directly callable as python functions. Assuming this is the case why isn't each client that a ball may has an effect on, particuallary the source and destination, stored as a reference in each ball, this way no figuring out is required, a ball is simply processed and the client object tracks whether any further data updates a need, when all it's referenced balls have been updated it fires an asynchronous thread to perform the serialization and update. This also allows the handling of lag since you can skip sending of updates if the current send hasn't succeeded, meaning you don't serialize unnecessarily. I may of course be completely wrong....

CCP Masterplan C C P Alliance	Posted - 2010.12.11 15:26:00 - [87] Part 2 is out now: http://www.eveonline.com/devblog.asp?a=blog&bid=829 Enjoy! -- Team Gridlock: Herding electronic cats since 2010

MotherMoon Huang Yinglong	Posted - 2010.12.11 22:38:00 - [88] Edited by: MotherMoon on 11/12/2010 22:42:29 Originally by: CCP Masterplan Defenders would become obselete Quote: Yup. It has always been that way. This is why a form of direct-flight joystick control simply wouldn't work in EVE. Is there still plans to have asteroid "dungeons" in the future where there can be joystick cobat in shuttles? I've heard devs talk about this for like 5 years, but never anything official. Would that even be possible? Does incarna have to match the 1Hz of the in space part? I'm asking because I know they might end up running on the same nodes maybe? How does that sorta stuff work? can you just split the code? Or will incarna run client side as there isn't much to exploit?

CCP Explorer	Posted - 2010.12.12 09:02:00 - [89] Incarna will tick at a higher frequency. We are refactoring the network code these days for that purpose. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games

EdwardNardella Capital Construction Research	Posted - 2010.12.12 16:29:00 - [90] Originally by: CCP Explorer Incarna will tick at a higher frequency. We are refactoring the network code these days for that purpose. Wait! What? Will the player be able to notice a difference? CCRES is recruiting pilots who want to live in WSpace/Wormholes. Fill out an application here!

MotherMoon Huang Yinglong	Posted - 2010.12.12 21:46:00 - [91] Edited by: MotherMoon on 12/12/2010 21:46:29 Originally by: CCP Explorer Incarna will tick at a higher frequency. We are refactoring the network code these days for that purpose. awesome. In that case consider making an arcade game (in Incarna) where you get to fight people with joystick comabt :P if incarna become a way for whitewolf to release boardgames.. omg... that's brilliant. I know this isn't the place but... With incarna maybe mirco transactions could be profitable? Not for you guys, I mean for the players. Think about it, if whitewolf designs a new board game, you could sell it to bar owners for cash, like 5$ a pop. I'll pay 60$ for a real life board game. You wouldn't have to print the boxes, or take any risk on materials. And people that play eve could visit said bar, and never have to pay a real life cent to access any content in eve. and it would give people a reason to visit your bar! I know if I was working at whitewolf <.< >.> the freedom to design board games so freely would be awesome. :)
Tonto Auri Vhero' Multipurpose Corp	Posted - 2010.12.13 21:55:00 - [92] Originally by: Epitrope Originally by: Tonto Auri Actually, you're speaking of increasing simulation speed. Not to leap into the future, but to reduce amount of iterations over bigger period. To clarify, take an example of 10 min battle. Normally, it's 600 ticks of time. If Destiny fails to process all events inside the tick, then switch tick length to 2 seconds AND calculate all events that would happen in these 2 seconds, so do only 300 ticks in the same 10 minutes, but still process all the events that should happen. As everyone saw in the blog, the time spent on actual calculation is minimal, so increasing tick length AND calculated period shouldn't cause major issues. The only problem, client engine must be ready for this speed stepping. All this does not exclude the need to reduce unnecessary notifications sent to clients. I understand what I'm saying, and I believe I understand what you're saying, and they're not the same. There will always be larger fleet fights than the server can handle. Right now, the pre-tick client updates step(s) are taking up most of the time. You're right that fewer, bigger ticks would allow the server to send out fewer, Yes. Quote: bigger No! Quote: updates, which would cause the clients to run at full speed but somewhat jerkier as updates are coming in half as quickly but with twice as much data. You're making a mistake assuming that data exchanged will be equally bigger - no, that's not the case. The data will be the same "per tick" data, the size will be much lower than your expected double increase, and only come from the unique events that added up - i.e. ship deaths/warps in/out. With stepped ticks the data exchange will go down considerably. Quote: However, as optimization work continues, perhaps that section won't dominate the tick quite so much and the evolve step will take a larger percentage, in which case fewer bigger ticks won't work as well. Indeed. There'll be always a bottleneck somewhere. Right now it's pre-tick notification calculations, later it could be the network throughput, requiring specialized proxy servers to relay the events between all the clients on a multicast principle... And the fight goes on. Quote: Your suggestion is, from the information made available to us, a good one. It lessens the lag problem as it exists right now. My suggestion of slowing down the simulation speed is more of a way to keep the game somewhat playable with any lag, current or future, regardless of cause or nature. It's a way to degrade more gracefully than the way high-load nodes degrade do now. As I see it, 2 mayor problems is the language choice and "solar nodes" architecture. Python don't scale at all in multiprocessor environment, not to mention the multy-node environment. Solar nodes limiting amount of people in a system, as well as preventing whole system mobility. Splitting nodes down to single grid would allow mobility (you can serialize almost empty grid into a short sequence of bytes and send it over ntwork to the other node) as well as lowering the load in every separate case. -- Thanks CCP for cu
Tonto Auri Vhero' Multipurpose Corp	Posted - 2010.12.13 22:04:00 - [93] Originally by: Dunpeal If you let the client decide if the update is relative to itself, wouldnt that allow for client hacking and purposefully making a client wich cannot die? I mean No. And not because, it's just that death is not calculated on client at all. But broadcasting blindly to everyone on grid would (depends on how it is implemented) allow to create a client that see every ship on grid, including cloaked ones. -- Thanks CCP for cu
Debir Achen	Posted - 2010.12.14 05:47:00 - [94] Originally by: CCP Masterplan Quote: On slowing down time / increasing the tick period This is something we've considered, along with a number of other bigger-scale changes that we've discussed. Some we quickly eliminated beacuse they wouldn't actually fix the issue. Some we've got on the board as potentials. Some we've even protoyped. Looking specifically at the slowing-down-time idea, this has received quite some attention. Some things to think about: What things should be slowed down? (Shield recharge, rate-of-fire, movement, skill-training, market order duration, aggression times, siege cycles...) Suddenly when you have two clocks running at different rates, you have to look at every single mechanic that is in some way related to time. What about other solar systems on the same node - should they slow down too? If we try to let different systems on a node run at different rates, it means we potentially have to keep track of which system a particular function call is dealing with, in case it needs to query a timer. I'm not saying all of this is impossible, simply that there is a lot more to it than you might initially think. (Take this as a sign that this is indeed an idea that has received attention) At the highest level, the clock division seems obvious to me: world-sim vs encounter-sim. Anything that is bubble-independent - skill training, market orders, etc - should progress independently of the simulation clock. Otherwise, a laggy node could mess up skill training times, which would be strange. In contrast, anything "on-grid" (so to speak) is tied to the sim clock. If the node gets overloaded, it strikes me that slowing the simulation to some fraction of real-time - and sending the client a note so that it knows to perform activation timer updates and flight extrapolation at appropriate speed - is a far better solution that dropping events (bad) or increasing the sample granularity (jerky). Slow-mo is way better than unpredictable-mo. :) "Game time" would pass at the same rate, but everything within some domain (bubble, system, node) would move more slowly. It's not a great solution, but at least it's explicable to the end user and everything stays in-sync. And you've just given yourself twice (or 3x or 4x or more) as much time to process everything without risking dropping stuff. I'm sure the implementation is not that simple, but I think the basic idea is sound. I deal with similar multi-clock issues at my work, and clear splitting of domains helps no end. BTW - is the 1Hz tick why missiles - especially Defenders - often seem to overshoot their target and then burst back onto it?
Ensei Grad	Posted - 2010.12.14 11:11:00 - [95] Quote: This now scales much better as the number of balls and observers rises - it is more like O(n+m). So cpu load will still be this small when we got like 300 drakes on each side shooting each other?
Winters Freedom Minmatar	Posted - 2010.12.15 16:23:00 - [96] Could you train 'Server Agility' to level 5, 'Server Multiple events' to level 5 and then add 'Server-client Impact' gaining 5% speedup per level? -- Eve aint fair, get over it.
Daneel Trevize Black Viper Nomads	Posted - 2010.12.17 02:00:00 - [97] Edited by: Daneel Trevize on 17/12/2010 02:01:19 Quote: skill training, market orders, etc - should progress independently of the simulation clock. Otherwise, a laggy node could mess up skill training times, which would be strange. Evil(?) way to deter blobs - those involved experience time dialysis and so train slower. Therefore poeple have to decide if they want to keep being in massive gangs or if they'd rather find a smaller encounter lifestyle Of course, the real fix to blobs is change to gameplay to something that rewards dividing numbers, like having to take synchronised and/or simultaneous actions in each system adjecent to the one you're after, splitting the forces 2-5+ ways.
Jehanne D'ark	Posted - 2010.12.18 19:36:00 - [98] With each advance the game makes, the maximum size of forces will grow as more players come to the game. This we all know. I just can't wait till I'm reading player news segment about the 300,000 man battle for some 0.0 system and how their modules were laggy but they did fine. :3
Jehanne D'ark	Posted - 2010.12.18 19:39:00 - [99] Edited by: Jehanne D''ark on 18/12/2010 19:45:05 "CPUs will not support such size fleets!" I call bs! Linkage Enter the graphene processor! More Linkage
immortal son	Posted - 2010.12.18 23:30:00 - [100] i don't know if this is the right place to say my mac client dn't work. I have downloaded it like twice already. It's getting crazy and annoying



Pages: 1 2 3 4 :: [one page]

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.