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) |
Kirgan
|
Posted - 2008.04.02 22:01:00 -
[211]
Possibly, The Cell Broadband Engine Processor may help with CPU overload issues, though it is likely cost prohibitive to implement in the current market. The Cell (BE) is a relatively new technology created by a cooperative effort from IBM, Sony and Toshiba. In Theory it is possible for them to be 25X +, faster than the current high-end CPUÆs from Intel and AMD. The Cell (BE) opens up a wide range of High Performance Computing (HPC) applications/solutions as well as many Entertainment Electronic Device uses.
SonyÆs PS3Æs utilize the Cell (BE) Processors and IBM has the QS20 Cell Blade server which uses the Cell (BE) Processors.
As my knowledge is only mid level on this technology, explaining the basic architecture would take way too much typing. Merely posting it here since CCP seems active in this thread and maybe it could be explored as a possible part of the upgrade process.
For those looking for more info; The first Cell (BE) whitepaper (I am aware of) from IBM was back in 06 and a popular thesis written by Mohammad Jowkar at The University of Copenhagen, Department of Computer Science (not sure exactly when it was available on the web) in June, 2007.
I do not have the Google Search gene so more info is probably out there.
|
Chelone
Stone Shadow Syndicate deadspace society
|
Posted - 2008.04.02 22:55:00 -
[212]
Originally by: Siigari Kitawa Bandwidth speeds in layman's terms:
Cable: o
InfiniBand: ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Got it. So both are zero, but one looks a lot more impressive on paper?
|
Zeba
|
Posted - 2008.04.02 23:07:00 -
[213]
Edited by: Zeba on 02/04/2008 23:08:11
Originally by: Chelone
Originally by: Siigari Kitawa Bandwidth speeds in layman's terms:
Cable: omg!
InfiniBand: ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo****!
Got it. So both are zero, but one looks a lot more impressive on paper?
I think this is what Siigari really meant. And those are lowercase letter o's not zeros you git.
Originally by: Malcanis Too many people confuse "Waah, I didn't get my own way" with 'poor customer service'.
|
Tzrailasa
|
Posted - 2008.04.02 23:48:00 -
[214]
Edited by: Tzrailasa on 02/04/2008 23:54:29
Originally by: Zeba
Originally by: Tzrailasa
Originally by: Zeba I already know what CCP plans to do with Infiniband and its potential for mostly killing lag even for fleet battles if its coupled with enough new servers getting added to the 0.0 regions.
According to what CCP has said as to how they're going to use this, it'll NOT mean any significant decrease for lag in fleet-battles in itself. Fleet-battles on the same grid will still be processed by only one CPU, and since the problem causing lag in battles appear to be the CPU having reached its limits, there'll be little to no effect on fleet battles.
Originally by: CCP Lingorm This is a really good discussion and I am enjoying it, I hope everyone else is getting something out of it too.
While initially it may not appear that we are doing anything for large fleet combat with this kind of upgrade that is not true. By splitting the Solar system services apart to allow them to run separate from each other means that a node that is handling a grid on which combat is happen is doing nothing but the combat. This means that it will not have cycles running other processes.
Theoretically we could also split out the 'reporting' of results so that one cpu is processing all the combat actions, it them pushes these results to another node that actually handles publishing all the results to the pilots. Thus meaning that we can further split the load handled by each cpu.
The Dev obviously disagree with you and tbqfh I'll believe the Devs anyday over some 0.0 resident with a grudge.
The solar system services are seemingly not significant compared to the processing required by combat. The reporting might be slightly more significant, but compared to trajectory analysis, collision detection, weapon calculations, drone calculations, processing of player commands etc. etc., it's probably still pretty close to nothing. The main problem is that combat CPU usage is exponential with number of players, while the others are linear, and that's what makes all the difference.
As proof of this, compare a solar system with 300 players in it in two situations. One of which is with everyone in combat, one with everyone not in combat. In the case of not-combat, everything works smoothly with only a touch of lag if any at all. This is also the case with 600 people, though slightly more laggy. In the case of combat in system, it'll lag up completely with minutes of module and weapon lag. In the first case, the system is doing nothing but solar system service and still run fine. In the second, once you add combat, lag hits heavily. This case (which everyone in 0.0 can confirm) strongly indicates no real benefits will come to large scale battle unless they can be multi-cored, something CCP has said they can't do.
Oh, and since you don't know me, you should probably not bring CAOD style argumentations into this discussion. You're not displaying any great knowledge of the issues involved (especially not about how fleet battles actually work, but Pator Tech School is most likely not involved in any of those), so you should probably keep a lower profile.
Everyone else in this thread has kept civil until now, and I advise you to do the same.
My views are my own. They do not represent the views of my corporation or alliance. |
Jovian Damnation
|
Posted - 2008.04.22 03:04:00 -
[215]
Originally by: CCP Lingorm Theoretically we could also split out the 'reporting' of results so that one cpu is processing all the combat actions, it them pushes these results to another node that actually handles publishing all the results to the pilots. Thus meaning that we can further split the load handled by each cpu.
I hope I'm just quoting out of context but if this is your plan for scaling you guys have already failed and (insert bitter threat to terminate account here).
Fleet combat isnt slow because there's 20 scouts in solar and a dozen logistics, its slow because theres 500 people on grid. You absolutely positively without a doubt MUST SCALE THE GRID ACROSS SYSTEMS. Use serialized group communications and independent nodes dequeueing computational tasks and serializing the results. Infiniband has a lot of grunge for this exact kind of concurrency, its all really based around a atomic increment operation. Eliminate redundant data generation tasks and make listen-only slaves that can be brought online to publish the results if hte main system gets bogged down.
I'd be happy to discuss contracting rates with you guys. You're scaring the **** out of me, I'd much rather see Eve stop sucking some day.
|
Jovian Damnation
|
Posted - 2008.04.22 03:14:00 -
[216]
Originally by: Tzrailasa
The solar system services are seemingly not significant compared to the processing required by combat. The reporting might be slightly more significant, but compared to trajectory analysis, collision detection, weapon calculations, drone calculations, processing of player commands etc. etc., it's probably still pretty close to nothing. The main problem is that combat CPU usage is exponential with number of players, while the others are linear, and that's what makes all the difference.
Last I heard we were giving BoB access to unreleased content and T2 BPO's, now we're giving BoB access to server code too? :ccp:! :ccp:! :ccp:!
The amount of information that must be distributed goes up exponentially, but the amount of calculations had better friggin remain linear. I'm only shooting at two guys at most.
Yes you can save some bandwidth and CPU by offloading the distribution of these calculation results to all N players, but theres no way in hell even linear scaling will let you run 500 players on a grid.
|
SiJira
|
Posted - 2008.05.02 19:11:00 -
[217]
brb assembling twenty thousand man fleet battle with |
Dr Slaughter
Rabies Inc.
|
Posted - 2008.05.02 23:57:00 -
[218]
Originally by: SiJira brb assembling twenty thousand man fleet battle with
with? with what?
- PS/3 Cell Processors
- NVidia GPUs
- Infiniband over TCP connections to the proxy,
- better underpants?
Seriously though, will we get an update on the Infiniband project this quarter? |
Zeba
Minmatar Pator Tech School
|
Posted - 2008.05.03 05:16:00 -
[219]
Yeah an information update would be nice CCP. |
Sunbird Huy
Ardent Industrial Hydra Alliance
|
Posted - 2008.05.04 19:55:00 -
[220]
I just hope they do something. As much as I like having more people online, it just hurts my game time. I started playing in october 2006. there was up to 10k(or around) people online at the same time. The lagg was bad in Jita and few mission systems. Me and old corpies moved to Poinen... it worked for a while. then people found about poinen too, and soon, we moved away from poinen too.now, 1.5 years later I see upto 45k people online at the same time. And do I have to mention, running from lagg DID NOT HELP ME...now I get slideshows in some systems with 65 people in them...and the POS gunners of the POS we are taking out, like this situations... just fix it, please...ASAP |
|
Joakim Wasyl
Caldari Universal Securities
|
Posted - 2008.05.04 21:59:00 -
[221]
I'm not sure anyones managed to convert a design written for a single execution to a massively parallel implementation successfully.
It's easier by far to start again from scratch, leaving the old system in place until you 'turn the switch' to make the new system active.
If you are starting from scratch, then you can reap the benefits of HPC implementations of course. Though the problem is, HPC costs money - mostly in software.
It may be cheaper simply to keep upgrading the hardware (if its commodity hardware) or split off time consuming calculations to something quicker than a CPU, most likely an FPGA which you can simply hang of the PCI bus on each of the existing nodes. |
LetsDoThis
|
Posted - 2008.05.05 04:06:00 -
[222]
|
Zeba
Minmatar Pator Tech School
|
Posted - 2008.05.05 04:32:00 -
[223]
Originally by: LetsDoThis
Ur poast is faaar too logical and will no doubt cause much wailing and nashing of teeth over in the Eve haters cubical.
inappropriate signature. ~WeatherMan |
Seth Ruin
Minmatar Galactic Exploration and Mining Corporation
|
Posted - 2008.05.05 04:57:00 -
[224]
Originally by: LetsDoThis (leaked design papers)
You actually know what you're talking about... What the devil are you doing posting on the EVE-O forums?!
|
Pan Crastus
Amarr
|
Posted - 2008.05.05 05:27:00 -
[225]
Originally by: Jovian Damnation
Originally by: CCP Lingorm Theoretically we could also split out the 'reporting' of results so that one cpu is processing all the combat actions, it them pushes these results to another node that actually handles publishing all the results to the pilots. Thus meaning that we can further split the load handled by each cpu.
I hope I'm just quoting out of context but if this is your plan for scaling you guys have already failed and (insert bitter threat to terminate account here).
Fleet combat isnt slow because there's 20 scouts in solar and a dozen logistics, its slow because theres 500 people on grid. You absolutely positively without a doubt MUST SCALE THE GRID ACROSS SYSTEMS. Use serialized group communications and independent nodes dequeueing computational tasks and serializing the results. Infiniband has a lot of grunge for this exact kind of concurrency, its all really based around a atomic increment operation. Eliminate redundant data generation tasks and make listen-only slaves that can be brought online to publish the results if hte main system gets bogged down.
I'd be happy to discuss contracting rates with you guys. You're scaring the **** out of me, I'd much rather see Eve stop sucking some day.
You're just guessing and based on recent experience, you're wrong.
EVE in its current incarnation has terrible lag issues that go beyond the single grid where fights are happening. You can sit in a POS in the same system with ~20 people on the grid (doing nothing) and you will lag out completely when a fight is happening somewhere.
So, it's not the frickin' grid, it's solar systems that are problematic. It's also not (like so many people are guessing wrong) the allegedly exponential with the number of players computation needed (that's only the case when every player interacts with everyone else and should only matter on the grid).
CCP has a lot of terrible code in their client and probably in the server as well. Someone please explain to me why "show info" should hang for minutes when a fight is happening in a solar system, or why my buddy list does not open, or why the chat hangs. Those are things that have nothing to do with the fight or the solar system where it happens and should be handled independently, but obviously aren't.
EVE Online: a cold, cruel world where (RL-)rich people replace their losses with GTCs sold to poor students who need to farm ISK to afford their play time ...
|
Zeba
Minmatar Pator Tech School
|
Posted - 2008.05.05 05:40:00 -
[226]
Originally by: Pan Crastus Someone please explain to me why "show info" should hang for minutes when a fight is happening in a solar system, or why my buddy list does not open, or why the chat hangs. Those are things that have nothing to do with the fight or the solar system where it happens and should be handled independently, but obviously aren't.
Because currently you share a single cpu node in 0.0 with scores of other systems full of ratters, small roving gangs, active pos and gatecamps. All these players use up the nodes resorces so when a fleet fight happens 20 jumps away you feel the impact on your client. Unless CCP adds a bunch of new servers in 0.0 along with the new supercomputer and infiniband the current lag situation in 0.0 will continue. Tbh if they doubled or tripled the number of servers that service the 0.0 regions you would no doubt see a huge improvement to lag in general. I can only assume they have not done this to save money for the big infiniband/supercomputer upgrade thats in the works. Alas only time will tell.
New dev blog maybe CCP?
inappropriate signature. ~WeatherMan |
Annanda
Gallente
|
Posted - 2008.05.05 05:56:00 -
[227]
Originally by: Sazumaan Johnza
- 70% Clueless people who springle buzzwords around for credibility.
What the hell is a 'springle'?
The above is your group?
|
Billy Merc
Amarr Pilots Of Honour Axiom Empire
|
Posted - 2008.05.05 08:16:00 -
[228]
lol @ this 5 month old thread still being alive... *rolls eyes*
|
Billy Merc
Amarr Pilots Of Honour Axiom Empire
|
Posted - 2008.05.05 08:17:00 -
[229]
Originally by: Carmaline matters little, still gonna break :)
Actually..... *this*
|
Ishina Fel
Caldari Synergy. Imperial Republic Of the North
|
Posted - 2008.05.05 09:03:00 -
[230]
Ahahahahaha that image is made of win
|
|
Galan Undris
|
Posted - 2008.05.05 12:20:00 -
[231]
Originally by: Chelone
Originally by: Siigari Kitawa Bandwidth speeds in layman's terms:
Cable: o
InfiniBand: ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Got it. So both are zero, but one looks a lot more impressive on paper?
You have now unlocked the secret of "How to write Executive Summaries"
|
Nicho Void
Hyper-Nova Tenth Legion
|
Posted - 2008.05.05 14:43:00 -
[232]
I foresee a cartoon like drain on the "power grid": 2K goons pile into Jita and bring the entire region to a crawl when the system distributes the load.
Originally by: CCP Wrangler We won't laugh at you... to your face...
|
William Alex
Viscosity space weaponry and trade
|
Posted - 2008.05.05 16:38:00 -
[233]
You guys sure got us all happy with the whole concept but now it's 05-05 and we still haven't gotten any kind of timeline. When can we expect some sort of announcement as to the timeline for this?
|
Zeba
Minmatar Pator Tech School
|
Posted - 2008.05.05 16:59:00 -
[234]
Originally by: Billy Merc lol @ this 5 month old thread still being alive... *rolls eyes*
You do realize that a project of this nature can take well over a year to pull together? Its not like ordering some parts from Newegg and getting the overnight deivery option and then throwing on your OS of choice after you take 20 mins to put it all together. Whole new supercomputer and whole new way for it to communicate means a whole lot of code will have to be rewritten from the ground up. Its not like CCP can just set up the hardware and dump the current server code on it. Give it another 4 to 6 months and if there still is no updates from CCP then maybe you can repoast your comment.
Would still be nice to at least get a quick quote about the whole thing from CCP though..
inappropriate signature. ~WeatherMan |
Gone'Postal
Minmatar Vengeance 8 Interceptors
|
Posted - 2008.05.05 17:06:00 -
[235]
so what we have no, if the node dies big deal eve carrys on
what were expected to get sometime on the tuesday of never is a server where the workload is distribited over all nodes, so erm.. if one crashes does that mean the others do to ?
I'd rather have the node pew pew and KM junkies crash then every node, of did i get the wrong end of the stick again ?
Questions, Comments, Problems, Please address them to the CSM.. Now CCP Never have to visit the forum. -V8I-
|
LetsDoThis
|
Posted - 2008.05.05 17:38:00 -
[236]
No distributed CPU system is the same so theres no 1 answer to that, but this could mean that there would be NO nodes go down if something failed somewhere. CCP would have to write code to handle such a case. But in some existing distributed systems, they handle this by redistributing the workload of the failing "node(or whatever)" to the rest of the systems. However depending on the implementation of the distributed system, it is very possible to cause a failure cascade.
|
Sunbird Huy
Ardent Industrial Hydra Alliance
|
Posted - 2008.05.06 15:57:00 -
[237]
Are they gonna introduce the improvements by october/november 2008? PLEASE.... |
Tiirae
The New Era HUZZAH FEDERATION
|
Posted - 2008.05.06 16:38:00 -
[238]
oh dear...
To consider yourself somehow qualified to voice an opinion on the problem, and then say something like 'I'm sure if they just hired 100 indian or chinese programmers the problem would just go away'...
Well, to paraphrase Charles Babbage, I am not able to imagine the kind of confusion of ideas that could provoke such a statement.
Good luck CCP; it's a shame all this work has such a short effective lifespan :)
|
Zeba
Pator Tech School
|
Posted - 2008.05.26 16:12:00 -
[239]
Originally by: CCP Lingorm Having EVE work on multiple cores is a goal we have, but other things are currently scheduled higher on the list (the New Server with MPI and Infiniband etc).
Well its not a conctete date (like we ever get those anyways:p) but at least we know its still in the works and hopefully on schedule.
inappropriate signature. ~WeatherMan |
Dr Slaughter
Rabies Inc.
|
Posted - 2008.05.26 16:44:00 -
[240]
Originally by: Pan Crastus So, it's not the frickin' grid, it's solar systems that are problematic.
It's not just the frickin' grid.
But if they don't write the grid code to scale across CPU cores and ideally hosts, there will always come a point when everyone in that grid will lag out.
Originally by: Pan Crastus
Someone please explain to me why "show info" should hang for minutes when a fight is happening in a solar system, or why my buddy list does not open, or why the chat hangs. Those are things that have nothing to do with the fight or the solar system where it happens and should be handled independently, but obviously aren't.
SOL services are currently sharing the same CPU that everything else is running on.
The service that provides "show info" probably has a much lower priority than, say, the combat engine services, etc. So it's getting less CPU time for a start.
Show Info is probably a bad example as it also has to pull in information from across the cluster (or at the very least partially out of data from the central SQL repository) like the market. There's an article somewhere about this and CCP do cache information but still...
With regards the chat service I think CCP stated that it's one of the services that's already split out from the rest of the SOL services but I can't find the post.
Step 1. break up the services so they can all run on separate CPU cores, Step 2. re-write the services that sit at 99% CPU so that they can be distributed across multiple CPU's, Step 3. Allow services to span hosts using IB to provide shared memory/or similar HPC service between the distributed processes.
CCP have been working on Step 1 for a while. Would be good to get an update. The complexity involved in (2)/(3) has been detailed by many posters and CCP themselves. Would also be great to hear how they're doing in the lab but I'm not holding my breath.
Forgot this thread even existed...
Rabies is unexpected ~~~~~~~~~~~~~~~~~~~~ dealing with the UNDERPANTS of eve since 2004 |
|
|
|
|
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 |