EVE Search - RE: Infiniband - Do it do it...just do it.

All Channels

EVE General Discussion

RE: Infiniband - Do it do it...just do it.

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

Monitor this thread via RSS [?]

Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 .. 17 :: one page
Author	Thread Statistics \| Show CCP posts - 20 post(s)
DrAtomic Atomic Heroes Phalanx Alliance	Posted - 2008.01.14 22:16:00 - [31] Sweet so CCP will be using this to dynamiclly upscale or downscale nodes (reinforce) as well as make nodetransfers more fluent (buhbye Session change allready in progress?). - - - Originally by: CCP Wrangler If you can understand our goal, disagree with our solution and offer a solution that is equal or better your opinion has a better chance of being heard...
Zeba Minmatar Pator Tech School	Posted - 2008.01.14 22:27:00 - [32] Indeed. So hopefully no more getting caught at the jump in lagged out due to a massive camp. Cov ops are nice to run those but when you don't even load the grid before the 30 second cloak runs out.... Originally by: Richard Phallus Come live with the common idiot, it's more fun down here. I did and got banned.
Frug Zenithal Harvest	Posted - 2008.01.14 23:24:00 - [33] Best Dev post in a while tbqh. - - - - - - - - - Do not use dotted lines - - - - - - - If you think I'm awesome, say BOOO BOOO!! - Ductoris Neat look what I found - Kreul Hey, my marbles
Orb Lati Minmatar Cold-Fury Southern Cross Alliance	Posted - 2008.01.15 00:15:00 - [34] I wonder if somebody can explain the new upgrades in terms of Dump Trucks and a Series of Tubes. http://www.thedailyshow.com/video/index.jhtml?videoId=114648&title=net-neutrality-act "We worship Strength because it is through strength that all other values are made possible"
Frug Zenithal Harvest	Posted - 2008.01.15 00:47:00 - [35] Originally by: Orb Lati I wonder if somebody can explain the new upgrades in terms of Dump Trucks and a Series of Tubes. http://www.thedailyshow.com/video/index.jhtml?videoId=114648&title=net-neutrality-act I guess its like instead of one big dump truck going around in circles, it's lots of little dump trucks driving around with smaller loads or something. That's all I got. - - - - - - - - - Do not use dotted lines - - - - - - - If you think I'm awesome, say BOOO BOOO!! - Ductoris Neat look what I found - Kreul Hey, my marbles
Xaziar Nortocus Knights of the Burger King YTMND.	Posted - 2008.01.15 00:55:00 - [36] Originally by: CCP Lingorm Actually it's a little more than that. Infiniband is more like liking your computers together is the 'PCI' bus rather than via a network connection. You could plug them in and then point all your network coms at the new cards, but it would not do much. The advantage to be gained from Infinband is that it will allow computers to read from other computers, to push work (threads) out to other machines and get the responses back very very quickly. The structure of a Network card is very different in that using it via TCP mean you need to use the TCP stack architecture and this means dealing with the inherent delays with the processing. The project team doing the infniband implementation as part of the HPC implementation are working very hard to get this out to you as soon as Practicable. But this is a Major recode of large parts of our low level code. We are basically ripping apart our own custom built Cluster management software and replacing it with calls to the HPC system. We are then recoding the software services to make use of the new communications framework allowing rapid transfer of data between Sol nodes and the splitting off of any part of the code that can be threaded. This is not something we can "Just do it" too. We are working hard on this and will get it out when it is ready. Thx for the clarification! Given the fact that internal calls to the SOL and SQL databases would be MUCH faster when InfiniBand would be implemented, is there any quantified benefit to the end user? Don't get me wrong, internal comms between all portions of the cluster would do wonders for lag (perhaps on paper), but with 30k-40k active connections to the cluster at peak times, wouldn't a new bottleneck create itself? Originally by: Ursula LeGuinn In other news, water still wet. Film at 11.
Dr Slaughter Rabies Inc.	Posted - 2008.01.15 01:02:00 - [37] I asked a while ago, in a different thread, how CCP would actually be using IB. As some people have been thinking it is quite possible to implement a network type interface and stack on top of IB cards (there are various implementations out there), and, by doing so CCP wouldn't have to modify any of their existing code. The problem with that approach is that it wouldn't really take advantage of using IB in it's native form, which, I think is what they're busy trying to do... That's good news. Implementing a network stack would have speed the solution to deployment but would really have missed the point. Devs... any chance of a write-up before Easter () in more detail? CCP this is not the nerf you are looking for...
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 01:06:00 - [38] Originally by: Orb Lati I wonder if somebody can explain the new upgrades in terms of Dump Trucks and a Series of Tubes. http://www.thedailyshow.com/video/index.jhtml?videoId=114648&title=net-neutrality-act basically, now you can only dedicate at most one worker per pile of dirt. if you needed to get the job done faster and with no complications, you needed to put your shovel down, go to the office and request the boss to get the people that are doing squat to help you. what the devs want to do is basically giving you a megaphone so that you can simply scream for help from the nearby workers that are doing squat, without going to the office. anyways, it seems some major coding is needed because transferring complete processing threads throughout several nodes in a totally fluid and seamless way is very, very, very hard to accomplish. btw CCP Lingorm, you guys going right to the 12x QDR right out of the boot or just going thru the less speedy types to spare on the moneys? --- planetary interaction idea!
Xaziar Nortocus Knights of the Burger King YTMND.	Posted - 2008.01.15 01:14:00 - [39] Originally by: Grimpak btw CCP Lingorm, you guys going right to the 12x QDR right out of the boot or just going thru the less speedy types to spare on the moneys? If CCP was smart in their implementation, they would use the fastest possible speed given the peak amount of traffic with a bit of head room for spikes in use. Originally by: Ursula LeGuinn In other news, water still wet. Film at 11.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 01:18:00 - [40] Originally by: Xaziar Nortocus Originally by: Grimpak btw CCP Lingorm, you guys going right to the 12x QDR right out of the boot or just going thru the less speedy types to spare on the moneys? If CCP was smart in their implementation, they would use the fastest possible speed given the peak amount of traffic with a bit of head room for spikes in use. then 12x QDR that allows 96gbit/sec transfers --- planetary interaction idea!
Xaziar Nortocus Knights of the Burger King YTMND.	Posted - 2008.01.15 01:27:00 - [41] Originally by: Grimpak then 12x QDR that allows 96gbit/sec transfers that would be nice, but would ALL of that bandwidth be justified? If 40k players logged into the cluster would use only a portion of it, it would not justify the cost. Now...if they spend all that money on the upgrades, yet set it to where THEY can adjust the bandwidth on demand, then that would be justified. Originally by: Ursula LeGuinn In other news, water still wet. Film at 11.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 01:37:00 - [42] Originally by: Xaziar Nortocus Edited by: Xaziar Nortocus on 15/01/2008 01:27:36 Originally by: Grimpak then 12x QDR that allows 96gbit/sec transfers that would be nice, but would ALL of that bandwidth be justified? If 40k players logged into the cluster would use only a portion of it, it would not justify the cost. Now...if they spend all that money on the upgrades, yet set it to where THEY can adjust the bandwidth on demand, then that would be justified, but that would be rather risky. I would say 12x QDR just for future's sake --- planetary interaction idea!
Dr Slaughter Rabies Inc.	Posted - 2008.01.15 02:06:00 - [43] Originally by: Grimpak Originally by: Xaziar Nortocus Edited by: Xaziar Nortocus on 15/01/2008 01:27:36 Originally by: Grimpak then 12x QDR that allows 96gbit/sec transfers that would be nice, but would ALL of that bandwidth be justified? If 40k players logged into the cluster would use only a portion of it, it would not justify the cost. Now...if they spend all that money on the upgrades, yet set it to where THEY can adjust the bandwidth on demand, then that would be justified, but that would be rather risky. I would say 12x QDR just for future's sake At 12x I would guess they could run ALL their IO over it (network, storage, and internode and node-to-proxy IO), not just, bouncing player state and threads between CPUs. CCP this is not the nerf you are looking for...
Ishina Fel Caldari Synergy. Imperial Republic Of the North	Posted - 2008.01.15 09:39:00 - [44] You know, I highly doubt bandwidth is an issue here. What InfiniBand promises for the TQ cluster is the vastly reduced latency. Therefore, using 12x QDR would only really make sense if it would further lower the response time of queries by a tangible amount compared to more economically viable solutions.
Rexthor Hammerfists Eternity INC. Mercenary Coalition	Posted - 2008.01.15 09:47:00 - [45] so for the ones like me who have absolutely no idea what this all means - how much will this infiniband help in a laggy fleetfight? also, whats the timeframe, 6 months, 1 year 1.5 years? -
Mangus Thermopyle Caldari Provisions	Posted - 2008.01.15 10:50:00 - [46] Originally by: CCP Lingorm Actually it's a little more than that. Infiniband is more like liking your computers together is the 'PCI' bus rather than via a network connection. You could plug them in and then point all your network coms at the new cards, but it would not do much. The advantage to be gained from Infinband is that it will allow computers to read from other computers, to push work (threads) out to other machines and get the responses back very very quickly. The structure of a Network card is very different in that using it via TCP mean you need to use the TCP stack architecture and this means dealing with the inherent delays with the processing. The project team doing the infniband implementation as part of the HPC implementation are working very hard to get this out to you as soon as Practicable. But this is a Major recode of large parts of our low level code. We are basically ripping apart our own custom built Cluster management software and replacing it with calls to the HPC system. We are then recoding the software services to make use of the new communications framework allowing rapid transfer of data between Sol nodes and the splitting off of any part of the code that can be threaded. This is not something we can "Just do it" too. We are working hard on this and will get it out when it is ready. That sounds awesome. If done properly, you would end up with a hybrid parallell solution. Faster than distributed memory but still without the drawbacks with shared memory.
ApaKaka Lone Starr Corporation	Posted - 2008.01.15 11:29:00 - [47] For those thinking in terms of ping or your network cable connection. No. IB is not like that at all. It's more of a 'hardware network' .. Think of it in terms of bus:es inside your computer exchanging information between your cpu, memory, disk etc. IB just does it over distance. What this means, essentially, as far as I understand is: CCPs cluster solution today is probably built on top of IP, so all this shuffling is done over a similar network structure as the normal internet. This is very slow compared to your cpu communicating with your RAM etc. IB will replace this network layer with a more 'machine friendly' and speedier layer, IB with their HPC APIs. This way you can push data back and forth much faster and in a much more similar way to how the hardware works internally in your computer. So, if done right, it will help immensly with fleet fights etc. Even if CCP initially only do what they said they would do - split market and station services out of the SOL nodes as well as on-the-fly load balancing.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 12:03:00 - [48] Originally by: Ishina Fel You know, I highly doubt bandwidth is an issue here. What InfiniBand promises for the TQ cluster is the vastly reduced latency. Therefore, using 12x QDR would only really make sense if it would further lower the response time of queries by a tangible amount compared to more economically viable solutions. well, 12x QDR can be also used as a sa***uard in case a node starts to fail, and has to make emergency transfer of all the processing to the rest of the cluster. I would still go to 12x QDR if not just for the failsafe abilities it can bring. --- planetary interaction idea!
Steini OFSI Gallente The Collective Against ALL Authorities	Posted - 2008.01.15 12:44:00 - [49] Originally by: Rexthor Hammerfists so for the ones like me who have absolutely no idea what this all means - how much will this infiniband help in a laggy fleetfight? also, whats the timeframe, 6 months, 1 year 1.5 years? I found another earthling here in this thread, that's also what I'd like to know ------- I love myself
HenkieBoy Enrave Knights Of the Southerncross	Posted - 2008.01.15 12:54:00 - [50] People, dont forget that speed gains like this option can be used in 2 ways: * More performance for players * Less server costs, aka same performance for less money In the end its the money that decides if we get less lag
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 13:25:00 - [51] Originally by: Rexthor Hammerfists so for the ones like me who have absolutely no idea what this all means - how much will this infiniband help in a laggy fleetfight? also, whats the timeframe, 6 months, 1 year 1.5 years? dunno about timeframe, but infiniband might bring the ability of reinforcing nodes on the fly and automatically without bringing the server down, meaning less server-side lag, since you'll be bringing more servers each time cpu usage of the node reaches a pre-determined peak. --- planetary interaction idea!
Tzrailasa Destructive Influence Band of Brothers	Posted - 2008.01.15 14:19:00 - [52] Edited by: Tzrailasa on 15/01/2008 14:20:18 Originally by: Rexthor Hammerfists so for the ones like me who have absolutely no idea what this all means - how much will this infiniband help in a laggy fleetfight? also, whats the timeframe, 6 months, 1 year 1.5 years? Unfortunately Rex, I personally don't believe it'll help all that much on fleet fights, but more on systems like Jita or busy mission systems. It MAY reduce jump-lag a bit (this is the one case where one node needs to talk to another), but I think that's about it. The problem (as I understand it) is that the lag we see in huge fleet-fights is mainly that the node where the grid is being processed being maxed out with regard to processing power. The CPU on the node is processing the battle in that grid as fast as it can, but so much is going on it simply can't keep up, meaning that player actions (and all other stuff like player clients being updated with grid information) get put in a queue, all of which we see as module and load lag. Since it can't keep up, the queue gets longer and longer, seen as increasing lag. Unless CCP find a way to let multiple nodes handle the same GRID (not just the same system), it doesn't really matter whether nodes communicate better through IB (except maybe for gate jump-ins). Implementing multi-node grid management with the cross-web of interactions between maybe 500 people on grid would IMHO be a.... non-trivial.... endeavour. The amount of information locking you'd have to do would be a nightmare, and might slow things down even more than the current single-node per grid architecture. It would be nice with some comments from CCP on what they think the specific benefits of IB would be for the different types of players. Whether it would be for large fleet battles or for Jita or mission systems. I hope my fears are unfounded, but I see the technical difficulties as being pretty close to impossible to overcome..... My views are my own. They do not represent the views of my corporation or alliance.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 15:06:00 - [53] Originally by: Tzrailasa Edited by: Tzrailasa on 15/01/2008 14:20:18 Originally by: Rexthor Hammerfists so for the ones like me who have absolutely no idea what this all means - how much will this infiniband help in a laggy fleetfight? also, whats the timeframe, 6 months, 1 year 1.5 years? Unfortunately Rex, I personally don't believe it'll help all that much on fleet fights, but more on systems like Jita or busy mission systems. It MAY reduce jump-lag a bit (this is the one case where one node needs to talk to another), but I think that's about it. The problem (as I understand it) is that the lag we see in huge fleet-fights is mainly that the node where the grid is being processed being maxed out with regard to processing power. The CPU on the node is processing the battle in that grid as fast as it can, but so much is going on it simply can't keep up, meaning that player actions (and all other stuff like player clients being updated with grid information) get put in a queue, all of which we see as module and load lag. Since it can't keep up, the queue gets longer and longer, seen as increasing lag. Unless CCP find a way to let multiple nodes handle the same GRID (not just the same system), it doesn't really matter whether nodes communicate better through IB (except maybe for gate jump-ins). Implementing multi-node grid management with the cross-web of interactions between maybe 500 people on grid would IMHO be a.... non-trivial.... endeavour. The amount of information locking you'd have to do would be a nightmare, and might slow things down even more than the current single-node per grid architecture. It would be nice with some comments from CCP on what they think the specific benefits of IB would be for the different types of players. Whether it would be for large fleet battles or for Jita or mission systems. I hope my fears are unfounded, but I see the technical difficulties as being pretty close to impossible to overcome..... well, if you manage to put several nodes in the same grid, you will need infiniband. the faster, the better, and I think that's what they are trying to do. --- planetary interaction idea!
Nakirash	Posted - 2008.01.15 15:08:00 - [54] Edited by: Nakirash on 15/01/2008 15:09:56 Alt post FTL....
Tzrailasa Destructive Influence Band of Brothers	Posted - 2008.01.15 15:09:00 - [55] Edited by: Tzrailasa on 15/01/2008 15:12:16 Originally by: Grimpak Originally by: Tzrailasa ... well, if you manage to put several nodes in the same grid, you will need infiniband. the faster, the better, and I think that's what they are trying to do. What leads me to believe that multi-node grids are not on the agenda is this quote from another thread: Originally by: "CCP Lingorm" Do you want a threaded combat engine ... I don't. It has to be handled sequentially or it will cause to many errors. If one thread completed processing before another thread that started sooner and this was then applied (say damage from my guns) but then the thread from you damage came back and said ... my ship was destroyed we have a problem. But moving other parts of the 'solar system' to their own cpu (like station services, etc) and then grouping those services will make a vast improvement. My views are my own. They do not represent the views of my corporation or alliance.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 15:19:00 - [56] Originally by: Tzrailasa Edited by: Tzrailasa on 15/01/2008 15:12:16 Originally by: Grimpak Originally by: Tzrailasa ... well, if you manage to put several nodes in the same grid, you will need infiniband. the faster, the better, and I think that's what they are trying to do. What leads me to believe that multi-node grids are not on the agenda is this quote from another thread: Originally by: "CCP Lingorm" Do you want a threaded combat engine ... I don't. It has to be handled sequentially or it will cause to many errors. If one thread completed processing before another thread that started sooner and this was then applied (say damage from my guns) but then the thread from you damage came back and said ... my ship was destroyed we have a problem. But moving other parts of the 'solar system' to their own cpu (like station services, etc) and then grouping those services will make a vast improvement. wich means pretty much multiple cpu's operating from the same "pool", and even so it is bound to make mistakes. yeah I got the drift that Lingorm is going to. guess the cluster is bound to have pretty much like another cpu upgrade soon(tm) --- planetary interaction idea!
Tzrailasa Destructive Influence Band of Brothers	Posted - 2008.01.15 15:29:00 - [57] Edited by: Tzrailasa on 15/01/2008 15:32:01 Originally by: Grimpak Originally by: Tzrailasa ... wich means pretty much multiple cpu's operating from the same "pool", and even so it is bound to make mistakes. If they have to wait for each other to get finished though, there's not going to be any improvement for fleet battles over the current mess (though it might make other parts of EVE run smoother) While I personally like large battles (at least the concept, not the current ones), and of.c. assuming I'm right in this issue and CCP doesn't manage pulling a rabbit out of the hat, what CCP really should do is bite the bullet and accept that there are limits to the size of fleet battles. Then they should implement some features strongly discouraging people from blobbing to more than the server can take. I'm not liking that solution much either, but IMHO its better than the lag-hell we currently have. Originally by: Grimpak yeah I got the drift that Lingorm is going to. guess the cluster is bound to have pretty much like another cpu upgrade soon(tm) The main problem with a CPU upgrade only is that it'll not matter much. Given that the use of processing power used is exponential with number of users, even a doubling of the processing power will only allow a relatively small number of extra players in a battle before it all lags out again. My views are my own. They do not represent the views of my corporation or alliance.
Grimpak Gallente Trinity Nova	Posted - 2008.01.15 15:33:00 - [58] Originally by: Tzrailasa Originally by: Grimpak Originally by: Tzrailasa ... wich means pretty much multiple cpu's operating from the same "pool", and even so it is bound to make mistakes. If they have to wait for each other to get finished though, there's not going to be any improvement for fleet battles over the current mess While I personally like large battles (at least the concept, not the current ones), and of.c. assuming I'm right in this issue and CCP doesn't manage pulling a rabbit out of the hat, what CCP really should do is bite the bullet and accept that there are limits to the size of fleet battles. Then they should implement some features strongly discouraging people from blobbing to more than the server can take. I'm not liking that solution much either, but IMHO its better than the lag-hell we currently have. Originally by: Grimpak yeah I got the drift that Lingorm is going to. guess the cluster is bound to have pretty much like another cpu upgrade soon(tm) The main problem with a CPU upgrade only is that it'll not matter much. Given that the use of processing power used is exponential with number of users, even a doubling of the processing power will only allow a relatively small number of extra players in a battle before it all lags out again. unless however, if we start to see a hard limit of people in the same grid, ejecting the excess to another grid, but I don't see it happening, as it would be way too easy to exploit it. --- planetary interaction idea!
Tzrailasa Destructive Influence Band of Brothers	Posted - 2008.01.15 15:44:00 - [59] Originally by: Grimpak Originally by: Tzrailasa ... unless however, if we start to see a hard limit of people in the same grid, ejecting the excess to another grid, but I don't see it happening, as it would be way too easy to exploit it. Yeah, that's not the way to handle it. As you say, too easy to exploit. The only idea I've ever seen that really did seem feasible as an anti-blobbing measure was a smartbomb like suicide-thingy on a BS that got more powerful and had more range the more ships were on grid (total, not just one 'side'). You can't make anti-blob measures based on which 'side' people are on since that would be too easy to manipulate, so it'll have to be something that makes it too risky to blob..... My views are my own. They do not represent the views of my corporation or alliance.
Tar om Minmatar Octavian Vanguard RAZOR Alliance	Posted - 2008.01.15 15:50:00 - [60] We really need a dev blog on this! I'd be very interested to hear what their goals are. Is this just to make Jita work and help the empire population? Or are CCP biting the bullet to make fleet battles worthwhile and fix the endgame? -- DEVS get multiple CPUs/Cores per system and all will be forgiven. www.octavianvanguard.net

Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 .. 17 :: 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.