EVE Search - New Dev Blog: Well, that was a few people

All Channels

EVE Information Portal

New Dev Blog: Well, that was a few people

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

Monitor this thread via RSS [?]

Pages: 1 2 3 :: [one page]
Author	Thread Statistics \| Show CCP posts - 8 post(s)

CCP Fallout	Posted - 2010.11.09 15:52:00 - [1] CCP Veritas' newest dev blog takes a look at two recent fleet fights, one the record 3,200+ fight, the other the 1,200 fight the next day, and goes into detail about the differences between the two fights. Read all about it here. Fallout Associate Community Manager CCP Hf, EVE Online Contact us

Razin The xDEATHx Squadron Legion of xXDEATHXx	Posted - 2010.11.09 16:01:00 - [2] Edited by: Razin on 09/11/2010 16:02:01 Was stuck loading grid for hours after a titan bridge into LXQ. Either the node should have died or we should be able to cancel out of trying to load the destination system after some time. The way it went the GMs refused to move anyone involved even though they knew around 600 were not going to be able to load the system. ...
Hemmo Paskiainen Gallente Silver Snake Enterprise	Posted - 2010.11.09 16:19:00 - [3] Cool, dont forget other stuff aswell Fix Black Ops: http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1204416
Haniblecter Teg F.R.E.E. Explorer The Initiative.	Posted - 2010.11.09 16:20:00 - [4] Edited by: Haniblecter Teg on 09/11/2010 16:20:28 heh, and the 1200 goofs in azn who forgot to make a fleet fight form crashed theirs. ----------------- Friends Forever
Letrange Minmatar Chaosstorm Corporation	Posted - 2010.11.09 16:23:00 - [5] With this in mind, FC's may want to start planning around no node deaths if they suspect the node will get re-enforced... Since CCP seems to have removed the ability of the player base to crash re-enforced nodes... Just saying... I look forward to further fallout from this battle. Technologically speaking. Couldn't give a damn about the NC/Russian tiff.
Elsebeth Rhiannon Minmatar Gradient Electus Matari	Posted - 2010.11.09 16:27:00 - [6] Quote: I spent an embarrassing portion of my evening excitedly informing my wife about how high the number in system had gone. If it is any consolation, huge numbers of players also spent embarrassing amounts of their time reporting the same number to IRC, Facebook, various forums, and other interwebs. -- Help us defend the Republic; join Gradient today.
Bagehi Association of Commonwealth Enterprises R.A.G.E	Posted - 2010.11.09 16:31:00 - [7] So, what you're saying is drake army fleets don't just kill the other fleet but can kill the servers as well? Awesome. This signature is useless, but it is red.
Illwill Bill Svea Rike Controlled Chaos	Posted - 2010.11.09 16:33:00 - [8] Another high-quality log from Veritas, filled with more juicy tech **. Thumbs up! Originally by:** CCP Navigator Great story but you probably want this in CAOD so feel free to post there with your main.
Garr Anders Minmatar The Red Circle Inc. Red Shift Alliance	Posted - 2010.11.09 16:51:00 - [9] Quote: Team Cobra Kai Strike first, strike hard, no mercy, sir! ----- Garr Anders "The only winning move is not to play" is about the best damn advice anyone can get regarding arguing over the internet. - referring to the Movie WarGames 1983
Kikki Di'je Lay Low	Posted - 2010.11.09 16:58:00 - [10] CCP Veritas, Just a few questions to attempt to get a better understanding of my experiences vs the technical aspects. Does Destiny have deadlines on DB processes? During the massive fleet fight, I was able to move my ship, warp, spin, and roll with about 1-2 second lag periods. Drones and any module activation well...it just never happened. I don't know if you are running a RAC environment or not, but if processes are being held up it would seem that more processing power is needed. Any thoughts on moving to a private cloud using virtualization?
Daedalus II	Posted - 2010.11.09 17:05:00 - [11] Ok so ship killing is expensive. What about trying to prepare that as much as possible before it actually happens? Like when you undock a ship with a new fitting you could calculate and save which modules would drop in the event of a destruction. (You also have to recalculate this each time the fitting changes, in space or in station). And every time you put something into the cargo it's also quickly randomized whether it would be dropped or not if the ship is destroyed. You could also pre-build the killmail as much as possible, just filling in the involved parties and the damage they did afterwards. The insurance payout and mail should also be possible to prepare in advance, or maybe let it wait for 30 minutes or so before being calculated as it isn't time critical. I don't know what else you can do, but I'm sure there are plenty of things you could pre-calculate before it's actually needed to save valuable time when it happens.

CCP Veritas	Posted - 2010.11.09 17:07:00 - [12] Originally by: Kikki Di'je Does Destiny have deadlines on DB processes? During the massive fleet fight, I was able to move my ship, warp, spin, and roll with about 1-2 second lag periods. Drones and any module activation well...it just never happened. This syncs up quite well with what I saw on the tech side. Everything to do with your ship moving around is Destiny, and given that it does everything possible to keep up with real time, you were still able to move around even under insane load. However, non-Destiny load, like drones and modules and, well, pretty much everything else got starved effectively completely. Originally by: Kikki Di'je I don't know if you are running a RAC environment or not, but if processes are being held up it would seem that more processing power is needed. Any thoughts on moving to a private cloud using virtualization? I'm not sure exactly what you're asking here. Could you clarify a bit?

Herschel Yamamoto Agent-Orange Nabaal Syndicate	Posted - 2010.11.09 17:08:00 - [13] My first thought here is that Destiny being a processing priority seems a bit odd. Given the choice, I think most players would gleefully prefer to play with low lag at say 1/4 speed than to play with multi-hour lag(which I observed in LXQ, it literally took over an hour to start cycling my guns at one point) at full speed. I know it'd probably require you to take a chainsaw to half the code base to change that, but it seems like a throttle function on the physics simulation might cure lag nicely. Am I just a hopeless optimist here, or could this actually be done? Anyways, thanks for the info.

CCP Veritas	Posted - 2010.11.09 17:10:00 - [14] Originally by: Daedalus II Ok so ship killing is expensive. What about trying to prepare that as much as possible before it actually happens? I've spent the past couple weeks digging at why exactly ship death is so expensive. I don't want to get into the details of that quite yet, but I'm happy to report that I've made a significant optimization to the process which is due for mass testing on Thursday. Think I can wring more out of it too if what I've done proves safe.

Mashie Saldana Minmatar Veto Corp	Posted - 2010.11.09 17:13:00 - [15] With 3242 players in system, how many destiny balls were tracked at any one time on average?
NeoFusion Caldari Freelancer Union Unaffiliated	Posted - 2010.11.09 17:16:00 - [16] Edited by: NeoFusion on 09/11/2010 17:17:22 Originally by: Daedalus II Ok so ship killing is expensive. What about trying to prepare that as much as possible before it actually happens? Like when you undock a ship with a new fitting you could calculate and save which modules would drop in the event of a destruction. (You also have to recalculate this each time the fitting changes, in space or in station). And every time you put something into the cargo it's also quickly randomized whether it would be dropped or not if the ship is destroyed. You could also pre-build the killmail as much as possible, just filling in the involved parties and the damage they did afterwards. The insurance payout and mail should also be possible to prepare in advance, or maybe let it wait for 30 minutes or so before being calculated as it isn't time critical. I don't know what else you can do, but I'm sure there are plenty of things you could pre-calculate before it's actually needed to save valuable time when it happens. I like it, or alternatively you could calculate the drop when the wreck is actually opened, seems mad I know but I'm sure there must be some way of linking a wreck to the ship it was before it actually got popped. This way the majority of that juicy processing could happen well after the battle, and only if the victor gets the chance to loot the field. Actually, just thought properly about this and realised it wouldn't work due to the killmail being delivered instantly (showing the dropped items, doh)

Chribba Otherworld Enterprises Otherworld Empire	Posted - 2010.11.09 17:25:00 - [17] Progress, is good progress. Secure 3rd party service \| my in-game channel 'Holy Veldspar'

Daedalus II	Posted - 2010.11.09 17:26:00 - [18] Originally by: Herschel Yamamoto My first thought here is that Destiny being a processing priority seems a bit odd. Given the choice, I think most players would gleefully prefer to play with low lag at say 1/4 speed than to play with multi-hour lag(which I observed in LXQ, it literally took over an hour to start cycling my guns at one point) at full speed. I know it'd probably require you to take a chainsaw to half the code base to change that, but it seems like a throttle function on the physics simulation might cure lag nicely. Am I just a hopeless optimist here, or could this actually be done? Anyways, thanks for the info. That may or may not be possible depending on the implementation. In my mind it should be pretty simple to skip every second tick for example, effectively halving the needed CPU time. That however has it's own interesting effects, two that I can think of is bumping and missiles. Imagine a bump that should have been registered in a certain tick, but that tick was skipped so the bump isn't registered until one tick later. This means the ships are closer together than they should have been and the resulting bump will be much more powerful. Or if the ships are sufficiently fast (or ticks sufficiently rare) they might even be able to fly through each other, never registering a bump at all. Same with missiles; a missile is supposed to hit a target a certain tick, but the tick is skipped so the missile overshoot the target entirely. It then has to turn around and chase the ship again, maybe missing a second time, and eventually running out of fuel even though it should have hit.
Daedalus II	Posted - 2010.11.09 17:30:00 - [19] Originally by: NeoFusion Actually, just thought properly about this and realised it wouldn't work due to the killmail being delivered instantly (showing the dropped items, doh) Good idea nevertheless Maybe you could delay the killmail 30 minutes as well, they aren't time critical either... Then you calculate the drop either when someone loots it or after 30 minutes when the killmail is generated.
Bruce Destro	Posted - 2010.11.09 17:34:00 - [20] although im very glad i read this, as i was present during the fight, the only reason i am is because there is an afk cloaky npc corp jerk in my system. we need something we can do about this. EMO R.A.G.E!
Kikki Di'je Lay Low	Posted - 2010.11.09 17:44:00 - [21] Originally by: CCP Veritas Originally by: Kikki Di'je Does Destiny have deadlines on DB processes? During the massive fleet fight, I was able to move my ship, warp, spin, and roll with about 1-2 second lag periods. Drones and any module activation well...it just never happened. This syncs up quite well with what I saw on the tech side. Everything to do with your ship moving around is Destiny, and given that it does everything possible to keep up with real time, you were still able to move around even under insane load. However, non-Destiny load, like drones and modules and, well, pretty much everything else got starved effectively completely. Originally by: Kikki Di'je I don't know if you are running a RAC environment or not, but if processes are being held up it would seem that more processing power is needed. Any thoughts on moving to a private cloud using virtualization? I'm not sure exactly what you're asking here. Could you clarify a bit? I'm used to seeing Oracle RAC systems for high processing as when one box starts to get clogged with requests and threads. With RAC, a load balanced multi box approach spreads the threads and requests evenly, helping the processing power clearing some of the clog although this is a cost based approach since it requires more physical hardware. With the private cloud, you can use unused resources of other physical components to do the processing of clogged requests. So in this example, we had a reinforced node for this particular fight, what about other nodes that might have only been using 15% of their resources? These resources could be used to help speed up the processes of all the requests. With virtualization you could use some resources for session changes for ship explosions and pods, and other resources for what I think Destiny is for - velocities, explosion radius's and the like. The remaining available resources could be used for DB threads to start or simple requests such as activating a module. With the recent buzz around cloud computing, I was just wondering if CCP was going to create a private cloud (I.E. not outsourcing external resources for obvious reasons such as uptime) to pull processing power and provide it where it needs it. I have seen demonstrations of this being an on demand solution which makes me wonder, while fleet notification is nice, in the future, you may not need it as once you reach a certain % of load, your virtualized DB's can kick in, and begin processing the extra load, much like a RAC system.

CCP Veritas	Posted - 2010.11.09 17:51:00 - [22] Originally by: Kikki Di'je <fancy multi-processing cloud foo> As current, the Eve server process isn't even multi-threaded at the OS level. We need to get moving down that path, but this level of setup is well beyond what we currently can leverage. It's doubtful that this level of wide processing would be beneficial to our particular load characteristic either, as the communication overhead of splitting a simulation over multiple machines would likely be a tighter bottleneck than the computation.

Indeterminacy THORN Syndicate Controlled Chaos	Posted - 2010.11.09 17:58:00 - [23] Edited by: Indeterminacy on 09/11/2010 18:02:04 Originally by: CCP Veritas ...you were still able to move around even under insane load... This has not been my experience. I was in LXQ and more recently CYB with about 600 +/- in local on what I would imagine was an unreinforced node. Imagine, a spontaneous battle, I know right? Anyway... In all cases (multiple engagements in LXQ over multiple days) navigation commands were severely delayed. In two cases, once in LXQ and in CYB navigation was impossible. Completely impossible. In LXQ the mwd stuck on and my ship refused to turn, stop, etc resulting in death and destruction. In CYB, after a point, I had no control over anything. Period. Outstanding operations mounted and mounted until I said "I have better things to do on a Sunday" and logged off. Edit: In fact, in CYB, I was even unable to join a fleet (got an empty fleet window and no fleet-chat window).
Pirokobo Merch Industrial Goonswarm Federation	Posted - 2010.11.09 18:07:00 - [24] in the beginning CCP made the capitals and the subcapitals and it was good. Then the did give the capitals the doomsday and the subcapitals dieed in scores. Thus did battleships become the norm for they alone could economically deal with tanking a dd. Then ccp did taketh away the dd and subcaps rejoiced for HACs would no longer quail in fear of instant death. Thus did the plague of HACs come upon the sniper battleship, and they colud not track. And the batleships did flee and reship into drakes, being in measure greater than HACs. But it was not good. For HACs and drakes must move to survive an drakes use missiles that cause the server great harm. And ccp being neither wise nor seeing did plan to smite the drake and not the hacs that ended the golden age of sniper battleships that the servers did love.
Kikki Di'je Lay Low	Posted - 2010.11.09 18:17:00 - [25] Originally by: CCP Veritas Originally by: Kikki Di'je <fancy multi-processing cloud foo> As current, the Eve server process isn't even multi-threaded at the OS level. We need to get moving down that path, but this level of setup is well beyond what we currently can leverage. It's doubtful that this level of wide processing would be beneficial to our particular load characteristic either, as the communication overhead of splitting a simulation over multiple machines would likely be a tighter bottleneck than the computation. I suppose this falls into the realm which we all unfortunately fall into at some point of cost effective vs labor effective vs processing effectiveness? I know there were was some new flash based technology that came out last year that was supposed to be capable of 7m+ transactions per second but can only imagine the cost not to mention training, installation and management time needed as well as possible future replacements. You do bring up a good point with the network being the bottleneck, but perhaps there could be some sort of leverage with fiber, security, and protocol usage to speed things up? Thanks for the responses, interesting to see and hear how bottlenecks are resolved!
Vincent Athena	Posted - 2010.11.09 18:35:00 - [26] I wonder if you could put destiny on one core and everything else on another. Might not be too much of a bottleneck to split the work that way. You would still have to give the core running destiny priority memory and network access, but you might still have a net gain.
ivar R'dhak	Posted - 2010.11.09 19:35:00 - [27] Originally by: CCP Veritas Originally by: Daedalus II Ok so ship killing is expensive. What about trying to prepare that as much as possible before it actually happens? I've spent the past couple weeks digging at why exactly ship death is so expensive. I don't want to get into the details of that quite yet, but I'm happy to report that I've made a significant optimization to the process which is due for mass testing on Thursday. Think I can wring more out of it too if what I've done proves safe. Why are you piling the ship-death calculations on top of all the other battle stuff in the first place? Can¦t you generate that "wreck database point"(your ship death calculations) randomly on undocking and just keep updating it when the cargo state changes. Or just "cheat" and by default make all consumables in cargo non recoverable on ship death. Thus there¦s no need to update that "ship death data subset" in space at all. Oh well, no idea how you do your database stuff but I hope I¦m not talking to much bnllsh!t there. _________________________________________________ Mal-¦Appears we got here just in a nick of time. What does that make us?¦ Zoe-`Big damn heroes sir.` Mal-¦Aint we just.¦
mechtech SRS Industries SRS.	Posted - 2010.11.09 19:36:00 - [28] Originally by: Vincent Athena I wonder if you could put destiny on one core and everything else on another. Might not be too much of a bottleneck to split the work that way. You would still have to give the core running destiny priority memory and network access, but you might still have a net gain. This makes sense to me too. If destiny is the only real time system, why not offload the other non-time sensitive processing to other cores and processors? Maybe not other computers per say, but it seems very possible to do this in a multi-core/multi-processor server, where each processor has access to the same memory.
Elsa Nietzsche	Posted - 2010.11.09 19:36:00 - [29] Is there any way non-critical actions could be queued up? say wrecks, loot, KM creation etc all get written off to a queue that can be processed after the fight. there's really no need for all that to be generated in the heat of battle. personally I'd like to see dynamic system population limits. say if there's 100 people in a system and load is high, noone else can jump in until the load stabilizes, then a new limit is set at say 500, etc. this would allow new fleets to jump in but only when the system can handle them. But i'm sure many will argue against it. i also like the idea of player presence takes precedence over player actions. this way if a server is overloaded, then no one dies as opposed to one team gets to slaughter the other who can't load grid. can't wait to see more blogs on this exciting stuff keep up the good work
Jamus Gorrelius Macabre Votum Morsus Mihi	Posted - 2010.11.09 20:47:00 - [30] So in R10 you have 900 players on a Reinforced Node and it is just as laggy and UNPLAYABLE as if it had 1200 or even 3200. Can we have some nifty excuses for that or isnt there any, Since dominion something snapped and i truly believe your working on it but you havnt got a clue how to fix it. What makes me cry a little inside is that we had a extremly playable game with 1200 before dominion on non reinforced node yet here we nearly a year later and we still have no FIX or any improvments.

CCP Veritas	Posted - 2010.11.09 21:04:00 - [31] Originally by: Jamus Gorrelius So in R10 you have 900 players on a Reinforced Node Just double checked, that system was not on a reinforced node.

Dalvor Coraneu	Posted - 2010.11.09 21:06:00 - [32] I'm grateful for a CCP post discussing the reasons behind the lag. I'll be honest and say I hadn't considered events committing future load. Interesting. But in short, I don't really give a sht about why the lag is occurring. Call me ignorant, but I don't pay to experience unplayable conditions to be met with a brief explanation as to why they occurred. The players of EvE have evolved and it seems the framework in which we operate has not. While I missed the fight in LXQ, I experienced similar conditions in CYB not two days ago. I am currently seeing the same problem reported in intel right now. Screw the expansions into new features for EvE - fix the game in it's current iteration and let us do as we intend. Sandbox? More like a shtbox when it comes to fleet fights.
Celeritas 5k McKendrick Merchantile Cooperative	Posted - 2010.11.09 21:16:00 - [33] ITT: Nerds who have never done anything more complicated than installing linux giving CCP advice on how to program their supercomputer. - NEVER PVP SOBER.
Jamus Gorrelius Macabre Votum Morsus Mihi	Posted - 2010.11.09 21:21:00 - [34] Originally by: CCP Veritas Originally by: Jamus Gorrelius So in R10 you have 900 players on a Reinforced Node Just double checked, that system was not on a reinforced node. Thank you for that i heard it was but why the tremendus lag and have we got some fixes comming soon that will take game back to before dominion? And are they going to be released with this expansion or are we going to have to wait again, because with all the mass testing you have done we have seen absolutly no improvment with any patch.
Hawk TT Caldari Bulgarian Experienced Crackers Circle-Of-Two	Posted - 2010.11.09 21:45:00 - [35] It seems you've been away for a while... Why don't you check the Dev Blog archives for lag-related blogs in the last couple of monhts? There are plenty of juicy bits & pieces coming... Dev Blogs - September 2010 page Originally by: Jamus Gorrelius Originally by: CCP Veritas Originally by: Jamus Gorrelius So in R10 you have 900 players on a Reinforced Node Just double checked, that system was not on a reinforced node. Thank you for that i heard it was but why the tremendus lag and have we got some fixes comming soon that will take game back to before dominion? And are they going to be released with this expansion or are we going to have to wait again, because with all the mass testing you have done we have seen absolutly no improvment with any patch. ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two
Andrea Griffin	Posted - 2010.11.09 21:57:00 - [36] Originally by: Celeritas 5k ITT: Nerds who have never done anything more complicated than installing linux giving CCP advice on how to program their supercomputer. But... But... *The Cloud!* It can do anything! ANYTHING! Just wave your hands a little bit! Seriously, though - whenever I hear someone roll out the all mighty magical cloud as a cure all I start to get violent. Anyway, I'm really glad that progress is being made here. It's very exciting and I hope you're having some fun in the process (I have fun optimizing code, but I'm weird I guess). Definitely looking forward to some detailed dev blogs down the road! Fix Rockets in ~~'08~~ ~~'09~~ ~~2010~~ ~~2011~~ 2012?!
Herschel Yamamoto Agent-Orange Nabaal Syndicate	Posted - 2010.11.09 23:18:00 - [37] Originally by: Celeritas 5k ITT: Nerds who have never done anything more complicated than installing linux giving CCP advice on how to program their supercomputer. Hence why some of us are humble enough to phrase our know-it-all-ness in the form of a question
Aldariandra Gallente MunsterMunch	Posted - 2010.11.09 23:38:00 - [38] Originally by: Andrea Griffin Originally by: Celeritas 5k ITT: Nerds who have never done anything more complicated than installing linux giving CCP advice on how to program their supercomputer. But... But... *The Cloud!* It can do anything! ANYTHING! Just wave your hands a little bit! Seriously, though - whenever I hear someone roll out the all mighty magical cloud as a cure all I start to get violent. Anyway, I'm really glad that progress is being made here. It's very exciting and I hope you're having some fun in the process (I have fun optimizing code, but I'm weird I guess). Definitely looking forward to some detailed dev blogs down the road! This comment gave me pleasure and satisfaction, and a great inner feeling of agreement, and I wanted to support it by quoting it.
Zendoren Aktaeon Industries	Posted - 2010.11.10 01:29:00 - [39] Originally by: CCP Veritas Originally by: Daedalus II Ok so ship killing is expensive. What about trying to prepare that as much as possible before it actually happens? I've spent the past couple weeks digging at why exactly ship death is so expensive. I don't want to get into the details of that quite yet, but I'm happy to report that I've made a significant optimization to the process which is due for mass testing on Thursday. Think I can wring more out of it too if what I've done proves safe. So, was it an "Aha!" moment or was it a "that's not supposed to happen" moment?
Taedrin Gallente The Green Cross Sev3rance	Posted - 2010.11.10 02:57:00 - [40] Originally by: Aldariandra Originally by: Andrea Griffin Originally by: Celeritas 5k ITT: Nerds who have never done anything more complicated than installing linux giving CCP advice on how to program their supercomputer. But... But... *The Cloud!* It can do anything! ANYTHING! Just wave your hands a little bit! Seriously, though - whenever I hear someone roll out the all mighty magical cloud as a cure all I start to get violent. Anyway, I'm really glad that progress is being made here. It's very exciting and I hope you're having some fun in the process (I have fun optimizing code, but I'm weird I guess). Definitely looking forward to some detailed dev blogs down the road! This comment gave me pleasure and satisfaction, and a great inner feeling of agreement, and I wanted to support it by quoting it. To be serious though, if CCP DID manage to make solar systems multi-threaded, it would be a HUGE step towards eliminating the lag monster forever. If they managed to make it embarrassingly parallel (impossible, I know), then CCP could just throw more hardware at the cluster to make things all better. Too bad that this would probably require a complete rewrite of the server code, though. It would probably also require some core changes to gameplay mechanics too. ---------- Originally by: Dr Fighter "how do you know when youve had a repro accident" Theres modules missing and morphite in your mineral pile.
Imhothar Xarodit Minmatar Wolverine Solutions	Posted - 2010.11.10 04:50:00 - [41] Edited by: Imhothar Xarodit on 10/11/2010 04:50:37 Originally by: CCP Veritas Originally by: Kikki Di'je <fancy multi-processing cloud foo> As current, the Eve server process isn't even multi-threaded at the OS level. We need to get moving down that path, but this level of setup is well beyond what we currently can leverage. It's doubtful that this level of wide processing would be beneficial to our particular load characteristic either, as the communication overhead of splitting a simulation over multiple machines would likely be a tighter bottleneck than the computation. If you cannot use multiple OS-threads in your Eve server process, how about running multiple Eve server processes? With different tasks: like process 1 is the client proxy, process 2 does the high-priority simulation stuff, process 3 does kill mail generation and other secondary stuff. I guess you have at least dual-cores with Hyper Threading, giving you a minimum of 4 logical cores to work with. You could either pack each core with its own process, or leave up a core for administrative/logging tasks which would not hamper the remaining processes' performance. That might be an easier solution than making the single process multi-threaded. Pushing messages between processes isn't that expensive with pipes. Ever thought about utilizing GPGPU for stuff like the physics part? To give you a hint: IBM GPGPU racks. A bit of OpenCL can make N-body simulations go weeeeeee by several magnitudes! Does Destiny make use of SSE instructions? This might sound silly, but it can speed things up quite a bit.
Ashemi Darkhold hirr Morsus Mihi	Posted - 2010.11.10 04:59:00 - [42] Edited by: Ashemi Darkhold on 10/11/2010 05:03:16 Originally by: CCP Veritas Originally by: Jamus Gorrelius So in R10 you have 900 players on a Reinforced Node Just double checked, that system was not on a reinforced node. For the record I filed the form for the reinforced node for R10 several hours before downtime. Noteworthy though the notifying character section of the form was bugged and just read "Test 1 Char Test 1 Corporation Test 1 Alliance"

CCP Veritas	Posted - 2010.11.10 10:02:00 - [43] Originally by: Zendoren So, was it an "Aha!" moment or was it a "that's not supposed to happen" moment? Pretty boring really. I set up some new profiling tools then self destructed a ship. Then added a bit more instrumentation to see exactly what all the load was and saw that a fair bit of it didn't actually need to be done. Upon looking at the relevant code, someone long long ago had this optimization described in a comment saying it should be done some day if the need was there. Tried it out, got a significant win, so put it in the deployment pipe. Nothin' special. That's kinda what we do in Gridlock these days.


CCP Veritas	Posted - 2010.11.10 10:12:00 - [44] Originally by: Imhothar Xarodit If you cannot use multiple OS-threads in your Eve server process, how about running multiple Eve server processes? It's not that we can't possibly use multiple OS-threads, it's that we currently don't. Doing so is on the roadmap, but is no small task. Originally by: Imhothar Xarodit Ever thought about utilizing GPGPU for stuff like the physics part? This comes up in every lag thread. I have done GPU programming before, and am familiar with the applications it's good for. Right now, the load that we're seeing is not even close to being applicable to a GPU solution. Originally by: Imhothar Xarodit Does Destiny make use of SSE instructions? This might sound silly, but it can speed things up quite a bit. You're assuming that the bulk of the Destiny load is doing heavy math. I haven't been looking deep at Destiny personally lately (CCP Masterplan has), but I don't think that's a safe assumption.

Venkul Mul Gallente	Posted - 2010.11.10 10:31:00 - [45] Originally by: Elsa Nietzsche Is there any way non-critical actions could be queued up? say wrecks, loot, KM creation etc all get written off to a queue that can be processed after the fight. there's really no need for all that to be generated in the heat of battle. 1) Define "after the fight". It is the moment the last shot is fired in system? Let's make some example of unwanted after effects: - player X suicide gank someone in high sec. CONCORD arrive, he is destroyed. After all that the battle end and the wreck spawn. How many opportunistic looters would be there and how slim would be the chance for the suicide ganker alt/corpmate to loot the wreck? - let's make it a wardec or low sec/0.0 situation, so no CONCORD. it is a "small" fight and your side is loosing or has no time to loot before enemy reinforcements arrive. You want to deny the loot to the enemy but the wrecks haven't spawned. What you will do? Wait for them to spawn or leave? - Mission runners: you delay loot creation till after the fight end. You have just killed the marauder utility and made mission even longer. Possibly you have even nerfed ninja looting/salvaging. 2) the data need to be stored somewhere in the meantime and sent to that somewhere. It is possible it will cost more resources than doing it immediately. Quote: personally I'd like to see dynamic system population limits. say if there's 100 people in a system and load is high, noone else can jump in until the load stabilizes, then a new limit is set at say 500, etc. this would allow new fleets to jump in but only when the system can handle them. But i'm sure many will argue against it. There is a problem there. You are denying reinforcements to one of the groups. Let's say you jump in system with 100 ships and there are 20 defenders. They have 200 ships next system but can't even try to enter because the server require 3 minutes to clear the jump load. You gift the attacking side with a 5:1 advantage for 3 minutes. Same thing if in reverse, the system had 100 defender, you jump in with 200 ships, but only the first 50 pass as the other 150 are delayed for some minute. Slaughter follow. Those are very negative consequences.
Lumy Minmatar Sebiestor tribe	Posted - 2010.11.10 10:40:00 - [46] I wonder, how many ships in space can Destiny realistically handle? Any estimates? Not shooting and blowing up stuff, just flying around, changing speed vector, bumping each other and so. I assume physics simulation will always be a single thread (?), but you could eventually move everything else to other threads/cores. Joomla! in EVE - IGB compatible CMS.
Lucy PewPew	Posted - 2010.11.10 11:17:00 - [47] Originally by: Elsa Nietzsche personally I'd like to see dynamic system population limits. say if there's 100 people in a system and load is high, noone else can jump in until the load stabilizes, then a new limit is set at say 500, etc. this would allow new fleets to jump in but only when the system can handle them. But i'm sure many will argue against it. A cunning FC could manipulate this to ensure that they maintained superiority in a system. We have many cunning FCs in EVE.
Horisontti River Styx. Legion of xXDEATHXx	Posted - 2010.11.10 11:17:00 - [48] You've done pretty good job so far I think. Just some things need to be adjusted. I think the lag thing also leads to some gamebalance issues like remote reps being being very good in lag (no cap, no hurries to lock). But it was very impressive to have 3300 people in one system, keep up the good work!!!
HeliosGal Caldari	Posted - 2010.11.10 11:30:00 - [49] NC russians and others please keep bashing each other over the head the game needs to push the limits and then some more
VE Vengeance	Posted - 2010.11.10 11:47:00 - [50] This Devblog was a fun read thx! So basicly the node was too busy with Destiny to "kill itself" by commiting to heavy-load events? So the conclusion of this is, when you reach a huge amount of players in one system, the system ends in a stalemate situation where it's too busy with destiny to die.
Fleet Reimbursement	Posted - 2010.11.10 12:07:00 - [51] I await the other promised blog of historical graphs and pretty pictures. I just have one question I am sure you can throw this on the back of answering someone else. How suprised were the two GM's that were killed in the battle when they were both popped?
Muul Udonii Minmatar THORN Syndicate Controlled Chaos	Posted - 2010.11.10 12:11:00 - [52] Question regarding the way the requests are handled: I've recently discovered the Ctrl Alt Shift M window; and in the LXQ battle I had 14 outstanding requests when my client eventually disconnected. If I had only sent requests when I had zero outstanding requests would these requests have been processed ahead of the backlog of requests from ther other 3241 pilots in the system? I ask because in another large laggy battle I was making sure my outstanding requests were very low, and yet I seemed to have the one request I sent waiting a very long time before being activated. In other cases I was able to spam three or four requests at once and get them processed after about the same period of time; but very close together.
Blazde 4S Corporation Morsus Mihi	Posted - 2010.11.10 12:42:00 - [53] Originally by: CCP Veritas Originally by: Imhothar Xarodit Does Destiny make use of SSE instructions? This might sound silly, but it can speed things up quite a bit. You're assuming that the bulk of the Destiny load is doing heavy math. I haven't been looking deep at Destiny personally lately (CCP Masterplan has), but I don't think that's a safe assumption. There is a huge amount of math in there and it uses x87, client side at least. I've speculated in the past that it might be using SSE serverside and that difference is one of the remaining causes of desync (especially in 'warping titan into station' type scenarios), OR that even if it's x87 serverside then codepath differences and truncating/not-truncating 80 bit floating point vaules is causing desync. All the desync I've observed in the last year 'comes from' the server. I can't get clients to diverge during their simulation. That could be for plenty of reasons, but it backs up the theory a bit. As long as Masterplan is looking into it could you pass this on to him? I detailed it better in a bugreport around february '09 with data showing desyncs in the least significant digits of FP values, and suggested switching to SSE since there aren't really any downsides, trying it is probably not much more than tweaking compiler options, it might fix a lot of desync and it might even give a bit of a speed increase. Very nice blog anyway, neatly explained a few things I've often wondered about. Originally by: CCP Veritas ... saw that a fair bit of it didn't actually need to be done ... significant win.. Nothin' special. That's kinda what we do in Gridlock these days. Is there a Team Gridlock fanclub we can join yet? _ Northern Coalition - Best friends forever <3
Ishina Fel Caldari Terra Incognita Black Star Alliance	Posted - 2010.11.10 12:43:00 - [54] Sooo... did I understnd that right? In heavy load situations, Destiny is the biggest CPU hog. But by reducing the CPU time consumed by Destiny, you allow the server to choke itself to death by way of processing too many cheap commands that later require heavy follow-up computing. Therefore, giving the server more CPU time for combat simulations will make the lag worse? Good god, I don't want your job buys the Gridlocks a round of Quafe for consolation Signature? What signature?

CCP Veritas	Posted - 2010.11.10 13:04:00 - [55] Originally by: Ishina Fel Therefore, giving the server more CPU time for combat simulations will make the lag worse? You got it. The node really wanted to die, but simply didn't have enough rope to make it happen. But we'll do what needs to be done. Today that means optimizing Destiny and ship death. After those are deployed, we'll have something else to jump on. Each individual step may not benefit the user experience directly, but the sum of them all will add up to a positive.

Ms Freak Amarr Imperial Shipment	Posted - 2010.11.10 13:33:00 - [56] Erm.. Just a suggestion here but... Kill mails, insurance mails etc. Why not just let those get processed at some later date/time? Yes we all love the kill-mails but why not have a seperate server/process dedicated to it that is extremely low priority. The same as spawning wrecks - loose the ship, create the pod, leave the wreck till later. I guess essentially what i'm saying is: Why not give everything a priority? Destiny has a high priority, mails need to be the lowest (because if they arrive after 2 hours it's not the end of the world) and wrecks could be somewhere in the middle? Another thought just crossed my mind reading this: I bet things in system (such as POSes/timers/PI) need some loving too - these could be given lower priorities too?! The idea around pre-calculating the dropped-items is a nice one - that would almost entirely remove the need for that calculation mid-fight. LXQ was unplayable really but it sound like CCP know why and are working towards fixing it, which can only be good i guess.
Una Achura	Posted - 2010.11.10 15:21:00 - [57] Edited by: Una Achura on 10/11/2010 15:22:03 Originally by: CCP Veritas The node really wanted to die, but simply didn't have enough rope to make it happen.
TornSoul BIG Majesta Empire	Posted - 2010.11.10 15:30:00 - [58] Edited by: TornSoul on 10/11/2010 15:33:58 Originally by: Ms Freak LXQ was unplayable FWIW - During LXQ I was pretty much roaming in what we now jokingly call God Mode. Barely any lag (2-6 secs) for the entire duration (until that last SBU did some wonky stuff to everyone there) Every major battle since, it's been the reverse... Just goes to show... BIG Lottery
Ms Freak Amarr Imperial Shipment	Posted - 2010.11.10 15:42:00 - [59] Originally by: TornSoul Edited by: TornSoul on 10/11/2010 15:33:58 Originally by: Ms Freak LXQ was unplayable FWIW - During LXQ I was pretty much roaming in what we now jokingly call God Mode. Barely any lag (2-6 secs) for the entire duration (until that last SBU did some wonky stuff to everyone there) Every major battle since, it's been the reverse... Just goes to show... Don't get me wrong - the client was working fine, cameras, moving, wapring (to some extent anyway) but in terms of actually getting anything done (like pew pew) it was broke. And yes, it's quite amazing how it can let 3000+ players fly around a system as long you don't shoot each other yet the second pew pew happens the server tries to hang it's self but is so stressed by the thought it actually keeps plugging away!!
Shanky McStabber Merch Industrial Goonswarm Federation	Posted - 2010.11.10 16:00:00 - [60] Edited by: Shanky McStabber on 10/11/2010 16:00:14 Originally by: Ms Freak The idea around pre-calculating the dropped-items is a nice one - that would almost entirely remove the need for that calculation mid-fight. The problem with this idea is the server would then have to recalculate dropped items every time you fired a missile/gun, launched a drone, fired a bubble. You would quickly lose all the gains by the sheer number of small "adjustments" that occur during the fight.
Vyktor Abyss The 8th Order	Posted - 2010.11.10 16:32:00 - [61] Top bloggin'! Pity all the blogs tend to get released at the same time though, this deserved more than a few hours as "the latest blog", and because you'd get a lot more suggestions and feedback if it was "latest" for a bit longer. Cheers.
ivar R'dhak	Posted - 2010.11.10 16:33:00 - [62] Edited by: ivar R''dhak on 10/11/2010 16:34:07 Originally by: Shanky McStabber Edited by: Shanky McStabber on 10/11/2010 16:00:14 Originally by: Ms Freak The idea around pre-calculating the dropped-items is a nice one - that would almost entirely remove the need for that calculation mid-fight. The problem with this idea is the server would then have to recalculate dropped items every time you fired a missile/gun, launched a drone, fired a bubble. You would quickly lose all the gains by the sheer number of small "adjustments" that occur during the fight. Thus my suggestion to "cheat" and mark all consumables as destroyed by default. Would even make kinda sense as the small stuff should have a very high chance to go kaput anyway. Only time when the list would get queried on the server would be when you hit the jettison command. _________________________________________________ Mal-¦Appears we got here just in a nick of time. What does that make us?¦ Zoe-`Big damn heroes sir.` Mal-¦Aint we just.¦
Gravemind GER Caldari Swords OF TYR Fatal Ascension	Posted - 2010.11.10 16:42:00 - [63] @ccp are you refering to: http://www.youtube.com/watch?v=taDBLIqPJw0 with the one ring to rule them all! one napfest to rule them all!
TornSoul BIG Majesta Empire	Posted - 2010.11.10 17:25:00 - [64] Originally by: Ms Freak Originally by: TornSoul Edited by: TornSoul on 10/11/2010 15:33:58 Originally by: Ms Freak LXQ was unplayable FWIW - During LXQ I was pretty much roaming in what we now jokingly call God Mode. Barely any lag (2-6 secs) for the entire duration (until that last SBU did some wonky stuff to everyone there) Every major battle since, it's been the reverse... Just goes to show... Don't get me wrong - the client was working fine, cameras, moving, wapring (to some extent anyway) but in terms of actually getting anything done (like pew pew) it was broke. And yes, it's quite amazing how it can let 3000+ players fly around a system as long you don't shoot each other yet the second pew pew happens the server tries to hang it's self but is so stressed by the thought it actually keeps plugging away!! Don't get me wrong either Everything worked just fine (only the slightest hint of lag) Targeting, shooting, activating/deactivating modules - you name it. I've never racked up that many kills in one fight ever (or since...) As said - "God Mode" It was truly remarkable while everyone else (that I know of) ***ed about the lag - I basically had none. (Gave rise to a few conspiracy theories about chars with low charID's being favored and what not ) BIG Lottery**
Abdiel Kavash Caldari Paladin Order Fidelas Constans	Posted - 2010.11.10 21:19:00 - [65] Originally by: TornSoul It was truly remarkable while everyone else (that I know of) *****ed about the lag - I basically had none. (Gave rise to a few conspiracy theories about chars with low charID's being favored and what not ) Now that you mention it, I do get younger players in my corp complaining about severe lag when I am having only slight delays... /me tinfoil hat ___________
Hawk TT Caldari Bulgarian Experienced Crackers Circle-Of-Two	Posted - 2010.11.10 23:34:00 - [66] Hmm, I guess Destiny actually does some heavy math, especially solving gazillion differential equations per second At least according to this GDC 2008 presentation (PPT Donwload)... Using a GPGPU for off-loading math could be a possible future, but a distant one IMHO. The "cost" and complexity of transfering data between the CPU and the GPGPU in a real-time simulation is just too high. Every ns counts... Sooo, until CCP invent a workaround (or a solution) to Stackless Python's inability to schedule micro-threads to multiple OS threads (thus multiple CPU cores), the only viable brute-force hardware solution comprises of a combination of the following: 1. New CPUs with better single-thread performance (higher IPC, frequency, better & bigger caches etc.) 2. New platforms (chipset/CPU combos) with lower memory latency / higher bandwidth 3. May be, only may be, utilizing some of the advanced SIMD CPU instruction sets. The upcoming Intel AVX instruction set is the most promising in terms of speeding up wide FP intesive calculations...(normalizing 3D vectors 2-2.9x speedup, solving ODE 2x speed up, etc.). Last, but not least, there is one big RISK regarding Option 3 or any form of it (using SIMD like AVX or GPGPU code on the server). In order to gain performance, the math libraries used by Destiny should be optimized (manually) for AVX / GPGPU (you choose). This means different branch of code... So, what's the problem? It's only on the EVE server side, right? Nope, Destiny is the physics engine that runs both on the EVE server and the EVE client side. It's just that the client side works with a sub-set of the data (only with the player's causuality bubble), while the server takes care for the whole system. Because computers are deterministic, using the exact same executable code & data on both sides (server & client) should produce (supposedly) the same results. Remember, the EVE server is authorative, the EVE Client should be in-sync and adjusts to the server. OK, so CCP controls what kind of CPUs are used for the SOL Nodes running destiny, but CCP could not control what kind of CPUs with what kind of SSE/AVX instructions available are used by the players. Ok, so what? This basically means, that using manually (and highly) optimized server code for destiny and using "standard" code on the client (for compatibility if AVX / GPGPU is not avaialble) could (and most probably will) produce big issues...I might be wrong, but the current hard-to-find-and-kill bugs would become just nice memories... Right now Originally by: CCP Veritas Originally by: Imhothar Xarodit Does Destiny make use of SSE instructions? This might sound silly, but it can speed things up quite a bit. You're assuming that the bulk of the Destiny load is doing heavy math. I haven't been looking deep at Destiny personally lately (CCP Masterplan has), but I don't think that's a safe assumption. ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two
Tonto Auri Vhero' Multipurpose Corp	Posted - 2010.11.11 00:17:00 - [67] Edited by: Tonto Auri on 11/11/2010 00:19:14 Nice blog, but honestly, why not take the controversal approach? When you see a blob aggregating and started to move, don't move the blob, move systems to it and move systems out of it. Every single system in null is fairly low-populated, it should be safe and quick to move such low-packed system to a next node. This way, you could dynamically achieve the results you are creating by hands per request: Blob will eventually end up on a node that is running single solar system. Just because all the other systems have so far escaped the blobbed node. EDIT: The ideal approach would be to create a separate environment for every grid, reducing "a-handful-of-thousands-of-men-in-the-basket" to bearable amount of people fighting in the actual engagement. -- Thanks CCP for cu
Blazde 4S Corporation Morsus Mihi	Posted - 2010.11.11 00:28:00 - [68] Edited by: Blazde on 11/11/2010 00:29:28 Originally by: Hawk TT Hmm, I guess Destiny actually does some heavy math It uses some pretty heavy math but we're not talking solid blocks of FP instructions in a tight loop, it's more like: - iterate over this - iterate over that - shuffle some memory around - make temporary copies of various vectors - math - check stuff - copy something - log something * do the above >10million times a second with constant cache misses due to the >3200 huge datastructures involved If Destiny is really a bottlekneck they'd be looking at algorithmic and architectural changes before squeezing minor 2x performance increases out of the math. I'm kinda surprised to hear it is because it already seems very smart in what it does, it's one of the few C++ bits of game logic and as you say it operates on all clients and the client never seems stressed by it. Clients only simulate one grid of course, though in LXQ I was on the busiest grid with more than half the players and had no noticeable performance drop. But hey, it's different scales, and not like my client was trying to run a node at the same time shrug There was a 10+ page discussion on SHC a few months back where a load of us err.. 'armchair devs' speculated about the viability of making Destiny run in a seperate thread. One of the arguments being that it would be relatively easy to seperate it because it's not python code and it already has a well-defined interface, but it would still require some important non-transparent changes in the way game-logic worked. Of course no actual devs weighed in so we were as clueless at the end as when we started but it's interesting to see it might have been a more relevant discussion than some of us realised. _ Northern Coalition - Best friends forever <3
HeliosGal Caldari	Posted - 2010.11.11 11:50:00 - [69] the inner dev mind is a mystery to all
Joseph SaintJohn	Posted - 2010.11.12 03:10:00 - [70] I have read all the "CCP dev blog" "we're fighting lag " "blah blah blah" until I'm sick and tired of it. All the graphs and "spin" is increasingly unable to hide the fact that the entire IT staff at CCP has reached it's competency limit. Ultimately , CCP needs to realize it's current IT staff is just not smart enough and does not have the training to make the computing infrastructure of EVE better. "slick" presntations can only mask fundamental incompetance for so long. Either CCP spends the money for "brilliant and inspired" IT staffing or EVE will fail. The superb and outstanding people are out there , Google found the ones it needed. I urge the management at CCP to stop buying into the "spin" you hear from your current IT staff. Get on the phone and call a few people at MIT or Cal Tech , and see if they think your IT staff are "the best and the brightest". I believe it has become "intuitively obvious to the most casual observer" that the problem , going forward , is not good intentions ; but the need for a level of competence not currently present in the CCP IT staff. I also know a post like this will never be seen by CCP management. It will be buried by incompetent staff that want to keep their jobs. Shame on you all. Joe
Hawk TT Caldari Bulgarian Experienced Crackers Circle-Of-Two	Posted - 2010.11.12 12:14:00 - [71] Dear Sir, Your statement shows only your own ignorance and incompetence. This. CCP's staff breaks new grounds in creating the biggest single-shard virtual universe. There is no such thing as "training" in regards to the challanges they face. Calling "MIT boffins" could not be a "silver bullet", because there are known possible solutions in theory, but in practice, CCP has to deal with millions of lines of legacy Python code, before they could start implementing long-term remedies. As many people asked "What CCP's Devs have been doing the last 6 months?", IMHO it would be safe to answer like this - "Refactoring old code & algorithms, going to 64-bit code & data structures, corification of services, implementation of HPC management tools etc.". I am talking about hard, nasty and dirty behind-the-scenes jobs, having no visible effects to the player community, apart from old bugs being discovered and new bugs being created! THIS IS THE NECESSARY EVIL IN ORDER TO LAY GROUND FOR THE STUFF THAT WILL BE VISIBLE! I don't expect that my statements will be comprehended and/or accepted by more than 5% of the EVE Players, just because understanding the complexity of the problem requires more than just "common sense" or "IT background" - it requires real-world experience with HPC / Real-Time Systems challanges, things not quite common in the IT area... KEEP BREAKING GROUNDS CCP! TAKE YOUR TIME, YOU ARE MAKING HISTORY! Originally by: Joseph SaintJohn I have read all the "CCP dev blog" "we're fighting lag " "blah blah blah" until I'm sick and tired of it. All the graphs and "spin" is increasingly unable to hide the fact that the entire IT staff at CCP has reached it's competency limit. Ultimately , CCP needs to realize it's current IT staff is just not smart enough and does not have the training to make the computing infrastructure of EVE better. "slick" presntations can only mask fundamental incompetance for so long. Either CCP spends the money for "brilliant and inspired" IT staffing or EVE will fail. The superb and outstanding people are out there , Google found the ones it needed. I urge the management at CCP to stop buying into the "spin" you hear from your current IT staff. Get on the phone and call a few people at MIT or Cal Tech , and see if they think your IT staff are "the best and the brightest". I believe it has become "intuitively obvious to the most casual observer" that the problem , going forward , is not good intentions ; but the need for a level of competence not currently present in the CCP IT staff. I also know a post like this will never be seen by CCP management. It will be buried by incompetent staff that want to keep their jobs. Shame on you all. Joe ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two
Altor Quon Gallente	Posted - 2010.11.12 12:44:00 - [72] Originally by: Hawk TT I am talking about hard, nasty and dirty behind-the-scenes jobs, having no visible effects to the player community, apart from old bugs being discovered and new bugs being created! THIS IS THE NECESSARY EVIL IN ORDER TO LAY GROUND FOR THE STUFF THAT WILL BE VISIBLE! I don't expect that my statements will be comprehended and/or accepted by more than 5% of the EVE Players, just because understanding the complexity of the problem requires more than just "common sense" or "IT background" - it requires real-world experience with HPC / Real-Time Systems challanges, things not quite common in the IT area... Heh, been there, done that :p "It's working fine, why do you need to change it?" "Btw, can you make it a bit faster, we got performance problems" "Heh, why do you need all that budget to speed things up a bit?" Then try to explain that all the skimping on budgets and quick & dirty solutions they pushed on the IT people the past couple of years are the cause of their problems... Ah well, as you say, most people don't even know how IT departments work (and especially the management and clients involved, who decide about the budgets) I think CCP is on the good way; first pay off the technical debt, prepare for later, and I guess we'll see new exciting stuff soon after :)
Hawk TT Caldari Bulgarian Experienced Crackers Circle-Of-Two	Posted - 2010.11.12 23:50:00 - [73] Edited by: Hawk TT on 12/11/2010 23:51:03 Originally by: Blazde Edited by: Blazde on 11/11/2010 00:29:28 Originally by: Hawk TT Hmm, I guess Destiny actually does some heavy math It uses some pretty heavy math but we're not talking solid blocks of FP instructions in a tight loop, it's more like: - iterate over this - iterate over that - shuffle some memory around - make temporary copies of various vectors - math - check stuff - copy something - log something * do the above >10million times a second with constant cache misses due to the >3200 huge datastructures involved If Destiny is really a bottlekneck they'd be looking at algorithmic and architectural changes before squeezing minor 2x performance increases out of the math. I'm kinda surprised to hear it is because it already seems very smart in what it does, it's one of the few C++ bits of game logic and as you say it operates on all clients and the client never seems stressed by it. Clients only simulate one grid of course, though in LXQ I was on the busiest grid with more than half the players and had no noticeable performance drop. But hey, it's different scales, and not like my client was trying to run a node at the same time shrug There was a 10+ page discussion on SHC a few months back where a load of us err.. 'armchair devs' speculated about the viability of making Destiny run in a seperate thread. One of the arguments being that it would be relatively easy to seperate it because it's not python code and it already has a well-defined interface, but it would still require some important non-transparent changes in the way game-logic worked. Of course no actual devs weighed in so we were as clueless at the end as when we started but it's interesting to see it might have been a more relevant discussion than some of us realised. Hmmm, check those: 1) CCP Veritas (Penrif on Reddit) - 1 2) CCP Veritas (Penrif on Reddit) - 2 3) Intel MKL optimized for AVX If I read CCP Veritas comments + the Intel MKL/AVC Whitepaper, I think that linking and using the Intel MKL in the C++ code of Destiny and the weapons subsystem could bring some tangible effects. 2x performance improvement is a dream, now the Devs are trying to squeeze every possible CPU cylce ___________________________________ Science & Diplomacy Manager @ BECKS Circle-of-Two
Choupette666	Posted - 2010.11.13 19:10:00 - [74] And what about a REAL factional warfare ? What about security status changes, real empire factions wars, real interactivity ? Apocrypha = ok... Dominion = mmmh... ok after all Tyrannis = pfff... ok. Just useless but ok Incursion = ?! Wtf ? Just... why ? Faction ship marketing and... oh ! My toon now got boobs ! I'm a happy player Nobody will listen, my reply will not change nothing, money is law, wow is money, eve will copy wow. Welcome in a new Eden. Fs all.
Debir Achen	Posted - 2010.12.07 02:35:00 - [75] As someone who has never particularly experienced Eve lag due to over-loaded servers, can I ask a little more about how it manifests? There are basically two manifestations of under-performance: (1) Everything runs slower. In this manifestation, all events remain in sync with each other, but trail behind real-time. It's like playing the game in slow-motion. (2) Synchronisation fails. In this manifestation, the user's view of the world and the "canonical" view maintained by the server get out of sync - what the user sees happen is not the same as what the server sees happen. In general, #2 is a lot worse experience than #1. When the lag is client-end (client's machine, network links), #2 is unavoidable. But when the lag is server-end, it's much better to slow everything down than to send the client infrequent snapshots or to react "late" to client events. Example: My worst lag experience to date was in the single player game Wing Commander 3. Occasionally, the graphics processing would have trouble keeping up and the game would freeze a moment. This was tolerable. What was painful is that the underlying engine would keep its clock running while the interface was frozen, and when the interface caught up it would jump ahead in time, often denying me the opportunity to fire or dodge. The "correct" behaviour is to pause or slow everything, thus keeping the interface and the game model in sync. (Yes, I know this isn't as easy in multi-player networked games, but the principle is still sound). Back to Eve - how does server lag manifest - is it just "slow-mo", or do things start jumping around and acting unpredictably as the server processes events out-of-apparent-order? To what extent is it possible to "slow the game down" to provide more time for the server to process and communicate events?
Aineko Macx	Posted - 2011.02.13 10:40:00 - [76] Quote: The EVE server does have one system that keeps up with real time - the physics simulation, Destiny. It will do everything it can to keep the game world moving at the same time as the clock on the wall. Every other system in the game shares the rest of the available time to do their work. Re-reading the blog, I stumbled over this statement. I can see reasons for running Destiny with real-time requirements, but it seems this creates a lot of other problems. I'd be interested in knowing why it wasn't decided to drop the priority down to the same level as the other subsystems, which would make the game run at a slower speed in load situations, but with less problems for the user experience. Ofc the timescale of the slaved simulation on the client would have to be kept in sync with the skewed timescale on the server, but that shouldn't be too hard to implement... ________________________ CCP: Where fixing bugs is a luxury, not an obligation.
Aineko Macx	Posted - 2011.02.13 11:16:00 - [77] Edited by: Aineko Macx on 13/02/2011 11:17:16 Originally by: Debir Achen As someone who has never particularly experienced Eve lag due to over-loaded servers, can I ask a little more about how it manifests? ... (2) Synchronisation fails. That became much rarer, after CPP fixed a bug which could make the physics simulation on the client reach a different state than on the server. In that case you would stop seeing simulation balls on your grid (ships and stuff), just static things like stations and gates. You could still move, warp around and get killed, but not initiate interactions (since you also stopped having anything on your overview). Quote: (1) Everything runs slower. Yes, but the slowdown is not equal among all systems (see my previous post). The main effects are basically that all user input takes longer to result in effects and it also seems your client receives updates less frequently. Ship commands, changing ammo, locking, broadcasts, dieing, jumping, grid updates, even chat posts, they all take longer. Then there are side-effects like modules/guns getting stuck, killmails being generated with wrong info or not generated at all, bombs not exploding after the nominal flight time/distance, lock requests being ignored, player ships not despawning and getting killed 45 minutes after logging off or jumping out, and ofc the dreaded grid load issue, where the pilots jumping/logging into a loaded system would never load the new grid while they would be visible and killable for the pilots already in system. I'm definitely forgetting some other effects... CCP has made progress on most of those issues. ________________________ CCP: Where fixing bugs is a luxury, not an obligation.

Pages: 1 2 3 :: [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.