EVE Search - New Dev Blog by Explorer - StacklessIO and lag reduction

All Channels

EVE Information Portal

New Dev Blog by Explorer - StacklessIO and lag reduction

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

Monitor this thread via RSS [?]

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

CCP Explorer	Posted - 2008.09.28 10:46:00 - [121] Originally by: PC5 Are drones having any significant factor in fleet fights after that change? I think they still are making a lot of lag, am i right? Especialy in fleet fights. After that change it would be nice if you look at aspects connected to fleet fights - like POS lag, drones lag, module cycles lag. Maybe there you can improve much? Any solutions/ideas for those aspects? Currently there is a team of developers in Need for Speed sprints measuring and looking at ways to optimise the code. One of the things they are investigating is drones/fighter vs. turrets/launchers, since it's our impression that drones/fighters contribute less to CPU cycles than turrets/launchers and we want to optimise that code. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games


CCP Explorer	Posted - 2008.09.28 10:51:00 - [122] Originally by: Chainsaw Plankton Quote: Finally there is a pool of dedicated dual-CPU machines that only run a single node per machine. Jita and four other solar systems are assigned to that pool. heh what are the 4 other systems amarr, motsu, rens, orsulate (or whatever that smelly frenchie system is called)? The only market hub on a dedicated machine is Jita, the other systems are missions-running systems such as Motsu and Saila. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games

Thraxon Black-Sun Frontal Impact	Posted - 2008.09.28 13:11:00 - [123] This is very good news. Will be looking forward how this will help in fleet battles.
Herschel Yamamoto Bloodmoney Incorporated	Posted - 2008.09.28 14:37:00 - [124] Originally by: CCP Explorer The only market hub on a dedicated machine is Jita, the other systems are missions-running systems such as Motsu and Saila. Do you keep one held back for fleet battles, or other short-duration, high-lag events of that type? Or do you pull Saila's machine in favour of AB-CDE's battle for the couple of hours it's needed for? ------------------ Fix the forums!
Zex Maxwell Caldari	Posted - 2008.09.28 15:13:00 - [125] Originally by: CCP Explorer Originally by: Reptzo Are you guys switching all coding over to native 64 bit? Is it already switched? We did a lot of work this week on 64 bit code and Tranquility is currently running a few nodes with all native 64 bit code. WOOT! 64BIT FTW! ^^
Callistus Reikoku Band of Brothers	Posted - 2008.09.28 15:16:00 - [126] Edited by: Callistus on 28/09/2008 15:16:20 Originally by: Herschel Yamamoto Originally by: CCP Explorer The only market hub on a dedicated machine is Jita, the other systems are missions-running systems such as Motsu and Saila. Do you keep one held back for fleet battles, or other short-duration, high-lag events of that type? Or do you pull Saila's machine in favour of AB-CDE's battle for the couple of hours it's needed for? As I understand it CCP can't reassign systems to different nodes while they're actually online. Load balancing usually only occurs during downtime based on previous activity in the system, so I imagine its very rare for a 0.0 system to be put on a dedicated machine. Last nights antics in M-O would be the exception; they were able to assign the system to one of the new beefy machines because the node was repeatedly dying anyway. ------------
Zex Maxwell Caldari	Posted - 2008.09.28 15:24:00 - [127] Originally by: CCP Explorer all of the above? The Inventory System is high on the list in Jita as players move a large number of items between hangar and cargo. The Agression Manager and Damage Tracking and Calculation System are low on the list in Jita. PvPs be warned.
Xavier Zyrae Demonic Retribution G00DFELLAS	Posted - 2008.09.28 17:37:00 - [128] Awesome job CCP! I was in doing some shopping in Jita earlier this weekend, before I had seen the blog, and I noticed right away it felt much more 'snappy' with >800ppl in local than it ever did before. I haven't been in any fleet battles lately but if the improvements in Jita are anything to go by I'm really looking forward to, we've been wishing for this for years... _________________________________________________________
london Jericho Fraction The Star Fraction	Posted - 2008.09.28 18:41:00 - [129] You guys are sure horny for bar charts. I dig it too, but it's kind of funny when you think about what gets us excited.
Bartholomeus Crane Gallente The Crane Family	Posted - 2008.09.28 19:42:00 - [130] Originally by: CCP Explorer Originally by: Bartholomeus Crane Nice barking, wrong tree. Clearly, handling IO sequentially is not an option. IO requests were probably handled (semi-)concurrently in random order using standard IO completion port scheduling. They are used in order by the Python part by blocking threads. Problems occur when there are many IO requests at the same time. Then schedulers can get overloaded, and this is probably what happened. Anyway, there's a better scheduler now, and probably more concurrency, and IO request are handled more efficiently, so these things shouldn't happen anymore. Exactly, the game logic was still handled in the correct order but client network request were sometimes handled very out-of-order by the server. Thanks, I wasn't entirely sure I was correct, hence all the 'probably's. To 'faffywaffy', it appeared to me that you were advocating synchronous, or blocking IO. Obviously, this is not an option, as it would slow down EVE to a crawl. Asynchronous IO implies some concurrency, as a thread (or tasklet) gets blocked waiting for the IO to finish, but another thread (or tasklet) would be permitted to continue. It is common in Python (and other languages) to handle this through 'extensions'. The important bit here is that all threads for a single timeslice (or equivalent) would have to finish before a new timeslice is started. As such, the game logic would be handled in sequence. Hence the problem when one of those IO requests would take too long to complete. In short, IO requests not-in-order, game-logic in-order. That was not the problem here though. What I gather from the blog and this thread is that with the old system, in really busy systems like Jita, so many IO requests would hit the network layer that it could not cope (basically thrashing the system). As a result IO requests would be handled way out-of-order and take too long to finish, thereby lagging out the whole system from the network layer up. The new network layer appears to be more scalable and more efficient overall, being able to handle more players in systems, and overall, reducing lag. There's probably an upper limit to this as well, but if it is high enough, who cares! How this was achieved, I don't know, but I can venture some guesses (mostly based on Porkbelly's reply): more scalable and efficient IO extension(s) written for Python (allowing it to be used as regular blocking operations for tasklets (threads) in stackless Python, meaning it's much easier to use by programmers), better scheduler for IO completion port's messaging queue, and more efficient and lightweight WinSock implementation (probably specifically written for the task). The increase in performance is probably a result of the combination of these things. I'm not quite sure how 64bit memory fits into this, but I can see how more available memory would help. If you're into these things, it's actually quite exciting, so I still would love to see a technical blog on the actual changes made to the network layer (substituting my wild guesses), but I guess the guys at the Core Server Team will be busy taking more measurements on how the framework actually performs 'in the wild' before they'll make any hard claims. One thing I would like to point out though: from experience, these types of problems are notoriously hard to pin-point within a complex system, as they are usually transient and usually depend on specific circumstances. In this case, maybe we should be grateful to have a hellhole like Jita. I'll go wash my mouth now ... -- Quis custodiet ipsos custodes?
Faffywaffy	Posted - 2008.09.28 21:30:00 - [131] Originally by: Bartholomeus Crane To 'faffywaffy', it appeared to me that you were advocating synchronous, or blocking IO. Originally by: Faffywaffy Obviously the I/O should be asynchronous for performance reasons Obviously, you did not bother to read my post. Once more - I am not talking about the network I/O layer. I am talking about the request processing (game logic handling) layer. The game logic layer must not, by design, be able to process requests out-of-order. Originally by: Bartholomeus Crane In short, IO requests not-in-order, game-logic in-order. That is the desired effect, but the blurb on the dev blog seems to imply that the game logic handling layer can process requests out of order. If it were only the I/O layer that could read requests out-of-order, it could not possibly "manifest itself in strange client behaviour as requests were delayed and completed by the server much out-of-order."
Lewis Atreides Caldari House Atreides trade	Posted - 2008.09.28 22:19:00 - [132] Easy sulution to population growth problems:diffrent servers. CCP's sulution:a 2years of work to keep everyone on one sever. I do kind of wonder if anyone at CCP HQ made a video of the devs actions during the Jita crisis.I know that asking about such a video is a bit nuts but it would be interesting to see how CCP's teames act during a unexpected development. ----------------------** While blood, carnage, and distruction may be my "happy place" that is nothing like the feeling I get while hauling 2 mill isk in goods thru low sec.
The Jugganaut	Posted - 2008.09.28 22:22:00 - [133] Originally by: CCP Explorer Currently there is a team of developers in Need for Speed sprints measuring and looking at ways to optimise the code. One of the things they are investigating is drones/fighter vs. turrets/launchers, since it's our impression that drones/fighters contribute less to CPU cycles than turrets/launchers and we want to optimise that code. I noticed you saying Sprints there, does that mean you work with the SCRUM development methodology? Also.. Do you use any special programming/coding specific approaches such as XP and test first approaches? Basically any of that shit my teachers have been knocking into my skull over the last couple of years? Must say blogs and forum replies like those from the DEVS here, is why I love the CCP devs!! Goodluck getting blizzard to write stuff like this! :D

CCP Explorer	Posted - 2008.09.28 23:40:00 - [134] Edited by: CCP Explorer on 28/09/2008 23:40:44 Originally by: The Jugganaut I noticed you saying Sprints there, does that mean you work with the SCRUM development methodology? We use Scrum for development of new features (especially where we are venturing into the unknown) and for optimisation tasks where cross-functional teams from different departments are needed. We use Staged Deliveries for more known development tasks and we when have a lot of small features (a category called "General Improvements" in the expansion plan). For defects we allocate time each week and then timebox defect work at regular intervals. The EVE Software Group is also responsible for live software maintenance of Tranquility and all live issues trump any work we are doing. Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games

DaDutchDude Minmatar Sebiestor tribe	Posted - 2008.09.29 01:05:00 - [135] Originally by: DaDutchDude Holy [censored] Batman! Dev Goodness Galore! [..,] 6) Windows Server 2008 HPC: ORLY? I read somewhere about 2008 HPC and it looks like it would fit well with CCP, but can you tell us more about what you are specifically hoping to gain from this upgrade? Looking forward to your responses! To answer my own question (or at least guess for an answer): From http://go.microsoft.com/fwlink/?LinkID=121218 , I found some interesting info: Quote: The Microsoft Message Passing Interface (MS-MPI) standard is a portable, flexible, vendor- and platform-independent standard for messaging within and between HPC nodes. MPI is the specification, and MS-MPI, MPICH2, and others are the implementations of that standard. MPI2 is an extension of the original MPI specification. MS-MPI is a messaging interface based on the Argonne National Laboratory open-source MPI2 implementation and is compatible with the MPICH2 reference implementation and other MPI implementations. Fundamentally, MPI is the application interconnection between nodes on an HPC cluster, tying nodes together. MPI provides a portable and powerful interprocess communication mechanism that simplifies some of the complexities of communication between hundreds or even thousands of processors working in parallel. The MS-MPI in Windows HPC Server 2008 uses a new RDMA-based NetworkDirect interface for best performance and CPU efficiency. As shown in Figure 8, NetworkDirect uses a more direct path to support networking hardware, providing extremely fast and efficient networking. Speeds and latencies are of the same order as custom, hardware-specific, high-speed MPI drivers from hardware providers. This smells like the Infiniband project has been cooking in the testbed-oven on Windows HPC Server 2008 all along, using these features to speed up the infrastructure and eventually be the base for more infrastructure-independent code that allows for more scalability. Of course there's a bunch of other improvements, like a new TCP/IP stack which should help with connections to our clients, a whole host of features that will make the server administrators happy since it'll make server deployment and management easier and also some tools that might help developers debug stuff in the complex infrastructure. So all in all, this looks like quite a big step, even though the immediate differences to us users will most likely be negligible. So devs, how's my guesstimate?
Vyktor Abyss IONSTAR Curatores Veritatis Alliance	Posted - 2008.09.29 02:27:00 - [136] Just want to add, I'm no suck up or fanboi and have been very frustrated by the lack of CCP presence on the forums recently, but I have nothing but praise for you CCP Explorer for your cander in this thread. Top Blogging! Keep it up!
PingKiller Caldari Deep Core Mining Inc.	Posted - 2008.09.29 03:46:00 - [137] Edited by: PingKiller on 29/09/2008 03:47:23 Originally by: CCP Explorer Originally by: Chainsaw Plankton Quote: Finally there is a pool of dedicated dual-CPU machines that only run a single node per machine. Jita and four other solar systems are assigned to that pool. heh what are the 4 other systems amarr, motsu, rens, orsulate (or whatever that smelly frenchie system is called)? The only market hub on a dedicated machine is Jita, the other systems are missions-running systems such as Motsu and Saila. Wouldnt be bad if u check out mission hubs like Dodixie, Aunia + Auvergne from Sinq region as well... In times i tested Motsu, Dodixie (and neighbour systems) had equal "lag" before StacklessIO came in, so dunno about now...
Ashlee Darksky Minmatar Forum Insurgency	Posted - 2008.09.29 09:38:00 - [138] This is freaking epic! Actually, it's far beyond that but I have no other way to describe it. I do have a question though... If a stack falls over, does it become a heap? Combat: You dev team perfectly strikes lag wrecking for epic improvements! Thank you devs --- > I see fail everywhere, and it's like they don't even know they're failing > Bring me the heads of 10 carebears, 5 bottles of BBQ sauce, firewood and a box of matches!
Kaeten Hybrid Syndicate	Posted - 2008.09.29 09:47:00 - [139] nice work guys, might have a chance after all ________________________ I'M POOR
Bartholomeus Crane Gallente The Crane Family	Posted - 2008.09.29 12:59:00 - [140] Edited by: Bartholomeus Crane on 29/09/2008 12:59:24 Originally by: Faffywaffy Originally by: Bartholomeus Crane In short, IO requests not-in-order, game-logic in-order. That is the desired effect, but the blurb on the dev blog seems to imply that the game logic handling layer can process requests out of order. If it were only the I/O layer that could read requests out-of-order, it could not possibly "manifest itself in strange client behaviour as requests were delayed and completed by the server much out-of-order." I read that statement as "manifest itself in strange client behaviour as (IO) requests were delayed and completed by the server (i.e the network layer) much out-of-order." As such, to me, it was nowhere 'implied' that game-logic is handled out-of-order, and that was confirmed here. Feel free to continue whipping, but to me, this horse is well and truly dead. -- Quis custodiet ipsos custodes?
Cefany	Posted - 2008.09.29 16:17:00 - [141] Were there any improvements made to anything layer 5 and below? I'm not sure if this falls in the scope of what the StacklessIO project, but were there TCP optimizations included?
Aselus Amarr Crimson Right	Posted - 2008.09.29 16:47:00 - [142] good job guys, never worked that much w/ netcode, but stackless/parallel paradigms are always awesome! power to the people! errr coders! ~~~~~~~~~~~~~~~~~~ ~Eternal Swordsman Amarr Victor!
Letrange Minmatar 17th Minmatar Tactical Wing	Posted - 2008.09.29 17:21:00 - [143] geekgasm You know, at the end of the day, even with all the problems that are still there to be resolved, it's a willingness to discuss tech issues like this that REALLY puts CCP in a different league than other MMO developers/publisher. As much as we all sometimes complain about either Lag or the harshness of eve, it still offers one of the most unique MMO experiences going. I await with impatience the point in time when all the current round of upgrading finishes and Tranquility gets certified somewhere on the list of supercomputers in the world (any idea where we currently stand?).
SillyWaif Galactic Kingdom	Posted - 2008.09.29 18:25:00 - [144] Great blog, and awesome to see the interaction with the Devs in this thread. Greatly appreciated
Elaron Jericho Fraction The Star Fraction	Posted - 2008.09.29 18:34:00 - [145] It's good to read that Stackless IO is coming to clients as well but would it be possible to elaborate how it benefits the client-side in particular?
Pantheon Lea Farmer Boyz	Posted - 2008.09.29 18:45:00 - [146] Normally Jita reaches a maximum of about 800-900 pilots on Sundays. On the Friday following the deployment of StacklessIO there were close to 1,000 concurrent pilots in Jita and on Saturday the maximum number reached 1,400. This is more than have ever been in Jita at the same time. Why do i always have to read between the lines - There was always arround 500-600 people stuck in Jita at any given time... Anyways, what i love about CCP is that they just say it out loud, imo that deserve only hurrays for using their time improving instead of denying. Stackless IO, Infiniband testing and HPC hardware, things like that gives reading old devblogs and patch notes a whole new dimmention. I don't play much anymore, but i love to be updated about how EVE is growing.
Fink Angel Caldari The Merry Men	Posted - 2008.09.29 22:19:00 - [147] Excellent feedback here. Thank you Dev Team.
Baredil Real Nice And Laidback Corporation	Posted - 2008.09.29 22:45:00 - [148] Great stuff guys! Now, if y'all can just get it all ported over to AIX or Solaris or something ... O/S flame war in 3...2...
Rashmika Clavain Gallente Revelation Space	Posted - 2008.09.30 11:35:00 - [149] So have CCP created a new network protocol here or have I misunderstood how StacklessIO works? Removed. Please keep your EVE signature related to your EVE persona and not that of a real life politician. Navigator
Moranti Patron	Posted - 2008.09.30 12:57:00 - [150] Just a quick comment. Thank you. Every step you take makes our fun that much more. Now sell some of the tech, and make some extra money, and lower our fees... Love ya Devs!

Pages: 1 2 3 4 [5] 6 :: one page
First page \| Previous page \| Next page \| Last 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.