EVE Search - What causes node lag anyway?

Search EVE-Online forums for:

All Channels

EVE Technology Lab

What causes node lag anyway?

Monitor this thread via RSS [?]

Pages: 1 [2] 3 :: one page

Author	Topic
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.26 15:52:00 - [31] Originally by: Sir Buff Maybe some of the lag you notice has to do with having to render all those other ships. Nah I use the classic client, zoomed out, with brackets, all effects and sound off, and a nice low resolution. ~~~~ There is no parody in this thread. Honest.
NanDe YaNen The Funkalistic	Posted - 2008.08.26 18:33:00 - [32] Bandwidth is n-body. 1000 ships on a grid means 1000 clients getting updates on where 1000 ships are at and what they're doing. For every byte that has to be transmitted to those clients per ship, a megabyte of total outgoing bandwidth is generated. Scales exponentially downward. 2000 ships will generate four megabytes of outgoing data per byte required for each ship. Bandwidth is fundamentally bound to become an issue. --------------------------------------- Originally by: Red Raider A happy gamer isnt on the forums, they are playing the game unless they have an idea that they honestly think is helping out.
Sir Buff	Posted - 2008.08.26 18:53:00 - [33] One thing I have noticed is that you only receive packets from other pilots within the same solar system. This might be why you notice the node lag...but I goes back to the download issue. When you make a jump through the node, your eve client needs all the pilot data for that new solar system and it must be downloaded. I really do see minimal node lag with my connection speed at 30mbps. I notice maybe 250ms of lag. Which is 1/4 of a sec, basically looks like a little glitch. But, I have to be jumping into a system with more than 400 pilots for it to be noticeable.
Ami Nia	Posted - 2008.08.26 20:12:00 - [34] Originally by: NanDe YaNen Bandwidth is n-body. 1000 ships on a grid means 1000 clients getting updates on where 1000 ships are at and what they're doing. For every byte that has to be transmitted to those clients per ship, a megabyte of total outgoing bandwidth is generated. Scales exponentially downward. 2000 ships will generate four megabytes of outgoing data per byte required for each ship. Bandwidth is fundamentally bound to become an issue. The bandwidth problem you are seeing just does not exist. If the cluster had problems handling the bandwidth, then ALL connections would lag, in all systems. With only 30 to 40 k users connected at a time, I hardly believe CCP's providers cannot handle the bandwidth. It's much more probable that the client side bandwidth will become insufficient much before the server side one does. Anyone ever looked at the actual per-client bandwidth used in a very complex scenario?
NanDe YaNen The Funkalistic	Posted - 2008.08.26 23:45:00 - [35] Originally by: Ami Nia Originally by: NanDe YaNen Bandwidth is n-body. 1000 ships on a grid means 1000 clients getting updates on where 1000 ships are at and what they're doing. For every byte that has to be transmitted to those clients per ship, a megabyte of total outgoing bandwidth is generated. Scales exponentially downward. 2000 ships will generate four megabytes of outgoing data per byte required for each ship. Bandwidth is fundamentally bound to become an issue. The bandwidth problem you are seeing just does not exist. If the cluster had problems handling the bandwidth, then ALL connections would lag, in all systems. With only 30 to 40 k users connected at a time, I hardly believe CCP's providers cannot handle the bandwidth. It's much more probable that the client side bandwidth will become insufficient much before the server side one does. Anyone ever looked at the actual per-client bandwidth used in a very complex scenario? 1000 ships receiving 1 updates on their own personal locations is not a bandwidth problem. The limitations of bandwidth thus only present themselves when a lot of users are having to receive information about each other. Users on separate grids scale linearly. Users on the same grid scale exponentially. When you take a server that is holding a linear problem just fine and turn it into an exponential problem, the server is dealing with many, many times more bandwidth. I'm so smart --------------------------------------- Originally by: Red Raider A happy gamer isnt on the forums, they are playing the game unless they have an idea that they honestly think is helping out.
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 02:35:00 - [36] Originally by: Sir Buff Originally by: Kagura Nikon LAg is NO WAY client problem. Lag has always been a client problem. If your latency to the CCP server is 15ms and 1 other person in local has a latency of 200ms, the most optimum result your are going to receive is 200ms between both individuals. Originally by: Kagura Nikon Lag on huge fights is 99% of time a server sided issue. There is absolutely no doubt about that, at least if you have a computer designed in the last 3 years. CCP holds 30-40k simultaneous users, however it all of the sudden lags when a measly 60 users get together in the same area?? And in another area of the map there's me making my trade runs at 0 lag problems flying in solar systems with plenty of users. 99% of latency issues are client. It's like that with every game anywhere. I have to disagree with you thinking it's the server. My example above is proof it's not the server. Otherwise, I would see your lag on my end. Let's see how fast 3mbit/s get's used up. You are flying around the map constantly updated your in game position to CCP and all the other things that you are doing, that could easily take 200kbit/sec. Now you have 60 pilots in your area all doing the same thing, 3000kb/sec is your connection - (60*200kbit/sec) so you can know what the other pilots are doing. That's -9000kbit/sec on your connection. Now factor in all the other player's bottle necked connections... and in all that lack of bandwidth everyone has to stay synchronized with everyone else so no ships start jumping around. Just a point. I have implemenetd MMO servers. By your post you have not. Stop SUPPOSING stuff and start measuring. Lag is not about network at all (not the network between your client and the server) neither on the client, at least on most cases. Its on the Server processing or internode communication. And no there is nothing in universe that forces you to have the same lag that I have when on same node. I don't know exactly how CCP implements their server, but similar systems can be implemented in a very varied set of way including from multi threading to "fake" threadign trough a client level task scheduler on single thread (user threads). Also you may bet a lot of isk that the I/O, be it network or disk, is for sure not in the same thread or proccess as the main data processing. Also is quite likely that each client is connected to a proxy server and not the main system node (that is usually a very smart choice on such huge systems with so many connections), and each proxy may be overloaded or not independently of each other. But you may be sure not a single well implemented system of such kind would bound the processign or transmittion of the data destinated to clients to the reception/processing/transmission data related to another client. That would be stupid and cause lots of deadlocks. Use simple factual evidence. Measure! During a fleet fight even very lagged I don't use more than 100 kbps and my CPU hardly goes above 40% (if i am using vsync). I can use 1, 2 or even 3 clients at same time and changes NOTHING on the lag. At 4 clients I start to lack RAM in my system to handle it. Proving that its NOT a client bottlenecking issue on any semi modern computer with semi decent network. People need to stop dissiminating fake information without even measurign things! You do not need huge MBit per second bandwidth to play eve even on the heaviest fights. ITs a fact. Download a network monitor and check yourself. You will hardly ever be usign more than 100 Kbps and I really doubt you will ever be usign more than 200kbps based on data I collected. Simple and true. No company in world woudl be so incompetent to make a game that uses 1 mbs for a single client! No one is that incompetent! CCp for sure its not! ------------------------------------------------- If brute force doesn't solve your problem... you are not using enough
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 02:40:00 - [37] Originally by: NanDe YaNen Originally by: Ami Nia Originally by: NanDe YaNen Bandwidth is n-body. 1000 ships on a grid means 1000 clients getting updates on where 1000 ships are at and what they're doing. For every byte that has to be transmitted to those clients per ship, a megabyte of total outgoing bandwidth is generated. Scales exponentially downward. 2000 ships will generate four megabytes of outgoing data per byte required for each ship. Bandwidth is fundamentally bound to become an issue. The bandwidth problem you are seeing just does not exist. If the cluster had problems handling the bandwidth, then ALL connections would lag, in all systems. With only 30 to 40 k users connected at a time, I hardly believe CCP's providers cannot handle the bandwidth. It's much more probable that the client side bandwidth will become insufficient much before the server side one does. Anyone ever looked at the actual per-client bandwidth used in a very complex scenario? 1000 ships receiving 1 updates on their own personal locations is not a bandwidth problem. The limitations of bandwidth thus only present themselves when a lot of users are having to receive information about each other. Users on separate grids scale linearly. Users on the same grid scale exponentially. When you take a server that is holding a linear problem just fine and turn it into an exponential problem, the server is dealing with many, many times more bandwidth. I'm so smart An exponentially very simple problem is still a very simple problem for a very very long time. The only network bottleneck remotely possible woudl be on CCP side (since on the other ends it NOT and exponential load but a linear load ALWAYS !!) And if that was the only problem you may be sure CCP would already have solved it (bandwidth is not that expensive when compared to processing power of a cluster). ------------------------------------------------- If brute force doesn't solve your problem... you are not using enough
NanDe YaNen The Funkalistic	Posted - 2008.08.27 02:56:00 - [38] Originally by: Kagura Nikon No actual points of contention. We're describing the same problem. It does get worse exponentially, but doesn't reach a particular node's cap for some time. I'm going to have to argue with you on that one --------------------------------------- Originally by: Red Raider A happy gamer isnt on the forums, they are playing the game unless they have an idea that they honestly think is helping out.
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.27 09:36:00 - [39] Edited by: Dr Slaughter on 27/08/2008 09:41:21 -editQuick overview x clients <---> y Proxies <----> z blades On each blade you have z number of cpu cores and on each core you have one single sol service. that sol service handles the in-space simulation (including combat) for all the solar systems assigned to it. This is your node. The bandwidth between the x clients and the y proxies is very large and the latency on CCPs part of the network is managed using some top end Cisco kit. The bandwidth between the proxies and the blades is also large and latency is low. The proxies cache information to improve performance as well. A long time before bandwidth becomes a problem the sol service responsible for the systems where these mythical 1000 vs 1000 fleet fights occur (I was in JV1V-O for a in your face example of this while trying to save a LV titan) runs out of both CPU and memory... and you get a node crash. A long while before the crash you get massive module lag. That's caused, not by bandwidth problems, but by the node running out of CPU. So, please, don't talk about bandwidth causing lag, in this game at the moment, you're just simply wrong. ~~~~ There is no parody in this thread. Honest.

CCP Lingorm C C P	Posted - 2008.08.27 09:49:00 - [40] Dr Slaughter is pretty much correct in his diagram. The network bandwidth is only a limitation IF you want to multi thread or dynamically move tasks to other processors on other machines (which is something that we would like to do as it would allow us to dynamically assign cpu power). It is also possible for you to have connections to MULTIPLE Sol node (Solar System, Chat, market, Gang etc) keeping these in sysnc will be faster with more network bandwidth (this will result in a reduction in the session change time hopefully). So yes we are working on Infiniband (as has been discussed), this in and of itself will have a small impact on performance (for the better) but it will ENABLE us to do other things that will have a much greater impact on performance. Such as dynamic node shifting under load. further break down of the solar system services into grid and station based services from different nodes, reduced Session update times. CCP Lingorm CCP Quality Assurance QA Engineering Team Leader Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.


Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.27 10:46:00 - [41] Originally by: CCP Lingorm Such as dynamic node shifting under load. further break down of the solar system services into grid and station based services from different nodes, reduced Session update times. sounds like a fantastic time to be working at CCP TBH ~~~~ There is no parody in this thread. Honest.
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 11:35:00 - [42] Originally by: NanDe YaNen Originally by: Kagura Nikon No actual points of contention. We're describing the same problem. It does get worse exponentially, but doesn't reach a particular node's cap for some time. I'm going to have to argue with you on that one you are quoting as mine a sentence that was not me that wrote. ------------------------------------------------- If brute force doesn't solve your problem... you are not using enough
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 11:45:00 - [43] Originally by: CCP Lingorm Dr Slaughter is pretty much correct in his diagram. The network bandwidth is only a limitation IF you want to multi thread or dynamically move tasks to other processors on other machines (which is something that we would like to do as it would allow us to dynamically assign cpu power). It is also possible for you to have connections to MULTIPLE Sol node (Solar System, Chat, market, Gang etc) keeping these in sysnc will be faster with more network bandwidth (this will result in a reduction in the session change time hopefully). So yes we are working on Infiniband (as has been discussed), this in and of itself will have a small impact on performance (for the better) but it will ENABLE us to do other things that will have a much greater impact on performance. Such as dynamic node shifting under load. further break down of the solar system services into grid and station based services from different nodes, reduced Session update times. A question. I've seen around quite lot of (controversial so please correct me if I am wrong) statements about eve server being also implemented in python. And based on my experience working with Myrinet networks at University quite few years ago, I remember that most usage of system area networks (SAN) were on the implementation of direct process -> process on another node communication, usually by passing completely the operating system and manually writing data in buffer on the other processes. Since Python usually is not a language designed to implement almost "operating system level" tasks this seems to become complicated. If the server is in python, would not that mean you guys need to re write a lot of things to be able to use SAN/Infiniband effectively? If yes, may the force, god and any other mistical entities be with you because it must be a really nightmare of a task. ------------------------------------------------- If brute force doesn't solve your problem... you are not using enough
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.27 12:02:00 - [44] Originally by: Kagura Nikon it must be a really nightmare of a task. Welcome to the world of CCP's HPC software cell. I'm interested in how they pass data from one node to another as when a node crash occurs, or a session change fails for some other reason, you tend to arrive back at a previous location. That implies that when a session change occurs your original state is stored somewhere until it's no longer needed (in the db? or on the proxy?). I wondered if CCP used Pythons pickling ability to pass the data and tasks between python processes (on different CPUs or hosts) but I'm thinking perhaps they don't. I'm guessing they have their own RPC type mechanism implemented as an extension (via boost perhaps??). My interest in pickling was because in theory they could pickle something up and unpickle it on a different type of host (Power6 CPU as an example) which might be faster and could be used for running larger fleet battles, or at least, reduced module lag. ~~~~ There is no parody in this thread. Honest.
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 16:03:00 - [45] Originally by: Dr Slaughter Edited by: Dr Slaughter on 27/08/2008 15:05:17 Originally by: Kagura Nikon it must be a really nightmare of a task. Welcome to the world of CCP's HPC software cell. I'm interested in how they pass data from one node to another as when a node crash occurs, or a session change fails for some other reason, you tend to arrive back at a previous location. That implies that when a session change occurs your original state is stored somewhere until it's no longer needed (in the db? or on the proxy?). I wondered if CCP used Pythons pickling ability to pass the data and tasks between python processes (on different CPUs or hosts) but I'm thinking perhaps they don't. I'm guessing they have their own RPC type mechanism implemented as an extension (via boost perhaps??). My interest in pickling was because in theory they could pickle something up and unpickle it on a different type of host (Power6 CPU as an example) which might be faster and could be used for running larger fleet battles, or at least, reduced module lag. -edit: after some reading I found the following written by a CCP dev and Stackless's maintainer: Quote: Eve does not use the pickling. -snip- There isn't much need for IPC. Server communication can happen over sockets with the asynchronous IO wrapped with a channel to appear synchronous to the calling logic. They might not need much IPC today. But one of the greatest benefits of a SAN is exactly allowing RPC to work almost as if you were in multi core single memory computer and not a distributed processing machine. I really see this as much easier to implement in a system implemented in C,C++ since you can treat it naturally without much complexity, just as if you had another thread writing at a piece of memory you also have access to. In fact when we did that at university we wrote the mirynet drivers for the operating system we were developing so we could easily give each process capability of adressing memory segment that were in fact just magical pipes to the other side of the SAN and writes would be handled directly by the communication device driver, no OS interference :) Its was fantastic for a cluster with dedicated operating system and processing DNA reconstruction code. THink would be3 great for an MMO server too, but might be a bit overkill :) I don't know much about Python pickling mechanism to be fair, as far as I know its some sort of serialization mechanism built in. Or is there anything else? ------------------------------------------------- If brute force doesn't solve your problem... you are not using enough
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.27 17:59:00 - [46] Originally by: Kagura Nikon we could easily give each process capability of adressing memory segment that were in fact just magical pipes to the other side of the SAN In the infiniband thread there are questions about how they're going to take advantage of it, especially, memory access using RDMA. Originally by: CCP Lingorm (Below is an example not a real project plan, it is there to give you an idea) Getting the current code base running in an HPC environment. Recode parts of our code base to use HPC functionality rather than our own code. Enable RDMA and start breaking up the current 'Sol' code to work across 'nodes' Enable dynamic moving of nodes. etc etc Originally by: Kagura Nikon I don't know much about Python pickling mechanism to be fair, as far as I know its some sort of serialization mechanism built in. Or is there anything else? No that's pretty much it but you can serialize running tasks, and, I think (I'm not a python programmer) even channels. To be honest, CCP are stuck with Stackless Python, but, it doesn't really matter because they know more about it than pretty much anyone else on the planet, so they can extend/monkeypatch and hack to get round things. Still.. lots of work. ~~~~ There is no parody in this thread. Honest.
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.08.27 18:12:00 - [47] Well that has its bad side too, since you don't have much options else to ask for help when you fail to solve something :P
el caido	Posted - 2008.08.27 19:47:00 - [48] Cheers for the serious question and a direct dev response. Too few of both nowadays. Now we know, and knowing is half the blob ... err ... battle. ;)
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.27 21:17:00 - [49] Originally by: Kagura Nikon Well that has its bad side too, since you don't have much options else to ask for help when you fail to solve something :P Nah that's what Stackless Python Sprints are for.. ~~~~ There is no parody in this thread. Honest.
NanDe YaNen The Funkalistic	Posted - 2008.08.28 01:42:00 - [50] Originally by: Dr Slaughter Edited by: Dr Slaughter on 27/08/2008 09:41:21 -editQuick overview x clients <---> y Proxies <----> z blades On each blade you have z number of cpu cores and on each core you have one single sol service. that sol service handles the in-space simulation (including combat) for all the solar systems assigned to it. This is your node. The bandwidth between the x clients and the y proxies is very large and the latency on CCPs part of the network is managed using some top end Cisco kit. The bandwidth between the proxies and the blades is also large and latency is low. The proxies cache information to improve performance as well. A long time before bandwidth becomes a problem the sol service responsible for the systems where these mythical 1000 vs 1000 fleet fights occur (I was in JV1V-O for a in your face example of this while trying to save a LV titan) runs out of both CPU and memory... and you get a node crash. A long while before the crash you get massive module lag. That's caused, not by bandwidth problems, but by the node running out of CPU. So, please, don't talk about bandwidth causing lag, in this game at the moment, you're just simply wrong. Gotcha. Hadn't worked on a system using proxies. Just a lowly HPC man We don't transfer large amounts of data in hierarchical distribution systems beyond what exists node-to-node or on a larger interconnect. Also never worked on a system that didn't distribute load across several nodes. CCP, how'd you manage to pull that off? Can see how the distribution model faces some stiff challenges. On all of the HPC problems I've worked with, the data can be broken up into domains that don't interact except at the data boundary. Clearly not the case in Eve. It's kinda arbitrary which ships are interacting with which since 500 pilots can start shooting any one pilot who's in an adjacent data set at any point. Not nearly as simple as five thousand molecules that don't care what 4950 of them are doing. I'm really kinda surprised though that you're running out of CPU and memory. Save me from going off on thousands of tangents. What are all the steps involved in running sol? My truly golden question: What part of code is the CPU spending most of its time on? --------------------------------------- Originally by: Red Raider A happy gamer isnt on the forums, they are playing the game unless they have an idea that they honestly think is helping out.


CCP Lingorm C C P	Posted - 2008.08.28 09:25:00 - [51] The server side (and client side) code is a mix of Stackless Python and C/C++ (C++ is client side in the graphics engine). Server side the C code is in the Physic's, Network and other low level sections. The 'Business' logic (to use the common term) is all Python. CCP Lingorm CCP Quality Assurance QA Engineering Team Leader Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.29 11:13:00 - [52] Originally by: NanDe YaNen -snip- Save me from going off on thousands of tangents. What are all the steps involved in running sol? My truly golden question: What part of code is the CPU spending most of its time on? I would love to know the answer to these questions in some detail myself. From the various dev posts that skirt around this topic I've been assuming when module lag hits and loading grid is taking ages it's the combat loop that's burning CPU and loading player state that burns the memory. Obviously in market hubs that's a different problem but probably exactly the same outcome. Perhaps we will be lucky and get a response which explains which parts of the code get stressed the most (combat processing, grid loading, collision management/POS, etc. etc.) ~~~~ There is no parody in this thread. Honest.

CCP Lingorm C C P	Posted - 2008.08.29 11:43:00 - [53] We have recently added new tools that let us profile this information in a more graphical way (using the KCacheGrind Tool) and are drilling down into this. I can not go into the details of 'what exactly' is the heaviest part of the code, because people would then make unfair use of that. Sorry but it's true. We know where the load is and we are actively working on those parts one at a time to optimize and harmonize the performance of them. Some of them have already been mentioned (like better analysis tools, looking into multithreading in certain code paths (where allowable), refactoring old code and in some cases completely replacing old systems with new. One of the systems due for replacement is the networking layer. It is being standardised, and better separated to improve stability, performance and also to make it easier to work the HPC/MPI interface stuff into it. This has been mentioned in other threads by various Dev's and at Last years Fanfest. CCP Lingorm CCP Quality Assurance QA Engineering Team Leader Originally by: Lord Fitz Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.29 22:06:00 - [54] Thanks anyway. Still interesting information. ~~~~ There is no parody in this thread. Honest.
Nareg Maxence Gallente Federal Defence Union	Posted - 2008.08.30 06:05:00 - [55] Yeah, interesting. Hopefully more info will be forthcoming on the progress of all this at next fanfest?
Gnulpie Minmatar Miner Tech	Posted - 2008.08.31 09:10:00 - [56] A very interesting reading, though I do not understand all of the terms. Still got the broad picture I think. The biggest lag doesn't come from bandwith problems but from cpu limitations. Using algorithms of at least quadratic runtime, it will become quickly ugly once a certain number is reaced. What I still fail to realize is how all these improvements will help fleet battles on the same grid. As far as I understood it will be still one cpu per grid? Only that this cpu can be dynamically assigned to the grid and reassigned after (or during) the peak of the battle is over. But maybe I missed something? With the above understanding I think long term solutions to really lag-free (tm) large fleet battles would be either a grouping mechanism so that you don't have to do all the calculations for the hundreds/thousands of objects but instead only for few groups dividing up the grid into subgrids in a clever way, that you can assign cpu's individually to the subgrids and use potential of the supercomputing approach and thus doing all the necessary calculations in a very fast way Has CCP any long term goals about the above?
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.08.31 16:08:00 - [57] Originally by: Gnulpie As far as I understood it will be still one cpu per grid? Actually worse than that. After Infiniband is rolled out is sounds, from reading the posts, that it will be likely that it will still be one cpu core per all grids in the solar systems the 'node' has been assigned. The code refactoring will improve how much they can get out of that core, and passing information between cores on other physical machines will be improved (session changes should be quicker) Originally by: Gnulpie Only that this cpu can be dynamically assigned to the grid and reassigned after (or during) the peak of the battle is over. But maybe I missed something? assigning idle cores to busy grids seems like a not-soon(tm) project as initially it sounds like they're working on breaking up the solar system services so that they can move them around. Breaking up the 'in-space' service so it can be distributed onto different cores and eventually assign cores to something as fine as a grid will take time but the framework for doing it starts with the HPC/Infiniband effort. Originally by: Gnulpie With the above understanding I think long term solutions to really lag-free (tm) large fleet battles would be either Originally by: Gnulpie -snip- {interesting ideas} -snip- Has CCP any long term goals about the above? I imagine they have but those sorts of ideas sound like the type of thing they can try implementing once they've got the foundations for quickly and easily shunting huge amounts of data between systems. Will be interesting what's happened by this time next year. ~~~~ There is no parody in this thread. Honest.
Kagura Nikon Minmatar Infinity Enterprises	Posted - 2008.09.01 10:44:00 - [58] Originally by: Dr Slaughter Originally by: Gnulpie As far as I understood it will be still one cpu per grid? Actually worse than that. After Infiniband is rolled out is sounds, from reading the posts, that it will be likely that it will still be one cpu core per all grids in the solar systems the 'node' has been assigned. The code refactoring will improve how much they can get out of that core, and passing information between cores on other physical machines will be improved (session changes should be quicker) Originally by: Gnulpie Only that this cpu can be dynamically assigned to the grid and reassigned after (or during) the peak of the battle is over. But maybe I missed something? assigning idle cores to busy grids seems like a not-soon(tm) project as initially it sounds like they're working on breaking up the solar system services so that they can move them around. Breaking up the 'in-space' service so it can be distributed onto different cores and eventually assign cores to something as fine as a grid will take time but the framework for doing it starts with the HPC/Infiniband effort. Originally by: Gnulpie With the above understanding I think long term solutions to really lag-free (tm) large fleet battles would be either Originally by: Gnulpie -snip- {interesting ideas} -snip- Has CCP any long term goals about the above? I imagine they have but those sorts of ideas sound like the type of thing they can try implementing once they've got the foundations for quickly and easily shunting huge amounts of data between systems. Will be interesting what's happened by this time next year. but with an infiniband cluster you can very fast move all data from a procces to other possibly allowign to move sol system from a heavier loaded node to a lighter loaded one.
Dr Slaughter Minmatar Rabies Inc.	Posted - 2008.09.01 13:43:00 - [59] Originally by: Kagura Nikon but with an infiniband cluster you can very fast move all data from a process to other possibly allowing to move sol system from a heavier loaded node to a lighter loaded one. Yes that's exactly why I'm excited about what eve might be line this time next year. I think we will see incremental improvements as CCP work on re-factoring their code, moving away from a are monolithic architecture for the sol management, and implement infiniband. The big improvements should come once they've got the basics in place and had 6-8+ months to play with it.
Frederik Andersen Caldari	Posted - 2008.09.02 18:15:00 - [60] Heres my 2 cents on making clients/eveserver run faster. 1. Move more calculations to the client. 2. remake the calculations (ask clientfirst, then calculate if needed) 3. raise the requirements for client CPU, GPU, MEM. 4. simplify the data transfored from client to server and visa versa. 5. chop up calculations done on each server. As i understand theres one for market, one for mail and such. lets pick marketserver: A. Requestments server. B. Buy server C. Sell server 6. If theres a way of calculating "Lag" then set up a designated server to monitor client lag. If client hits ping of 50, then stop the calculations done by all the other servers. And wait till client hits under 50 ping. 7. Upgrade server. Yes this means more money spent on server and might not be cheap done. CCP can raise the gaming fee of 114 euro's to 200 i dont care. All i want is my game experiance to be the best. And i'm willing to pay for it. If CCP has any questions please contact that medical centre that uses clients to calculate data on external user CPU's around the world. Can't remember the name of the corp.

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