Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Atticus Fynch
Gallente
|
Posted - 2010.07.30 05:17:00 -
[1]
I'll be the first to admit I don't know the technical workings of this, but will putting 0.0 space on a separate shard alleviate lag by any chance? |
Aessoroz
|
Posted - 2010.07.30 05:31:00 -
[2]
WTH is a shard? Also tranquality is already ran by many servers and the solar systems are distributed across the servers to even the load.
|
Domonique Molvoy
Exploitation Inc.
|
Posted - 2010.07.30 05:35:00 -
[3]
No. just no. Domonique Molvoy Shiptoasting extraordinaire |
Lecherito
|
Posted - 2010.07.30 05:55:00 -
[4]
Originally by: Atticus Fynch I'll be the first to admit I don't know the technical workings of this, but will putting 0.0 space on a separate shard alleviate lag by any chance?
You don't "get" Eve.
-L
|
Furb Killer
Gallente
|
Posted - 2010.07.30 06:11:00 -
[5]
It wouldnt help against lag (well besides by killing eve so no one plays it anymore).
|
Tarasina
|
Posted - 2010.07.30 06:14:00 -
[6]
Eve is already sharded. They are called nodes.
|
Ioci
Gallente Morrigna Order
|
Posted - 2010.07.30 07:04:00 -
[7]
Unlimited hardware or a substantial amout of redundant hardware would allow them to write code that allocated over population to a unique shard.
If a system sees a huge population increase it gets moved to its own shard/ node. That will resolve CCPs obligations but if the average home computer isnt capable of handling 2000 indentifiable objects such as other players it wont matter. Its like hooking your 60 watt speakers up to a 2000 watt amplifier.
I dont think CCP can fix lagg. Not using the graphics we use now. Make a new EvE battlefield maybe. One that is designed to accomodate large scale warfare. It wouldnt be out of sorts with EvE. When we commit to a battle in EvE our fit is our stat or profile. It is what determines if we live or die. A 2D battlefield option where strategy and raw numbers dictate the outcome? Have other software that renders a movie of the battle, available to anyone who was in it?
Just throwing stuff out tho. |
Yuki Kulotsuki
|
Posted - 2010.07.30 07:35:00 -
[8]
Originally by: Ioci stuff
No. That's wrong.
There's no dynamic allocation because CCP don't want the overhead of running a hypervisor. They're using maximum resources on stressed nodes and don't want to decrease the ability of those nodes by running extra stuff on top. The current state of the art hardware isn't much better than what CCP already have. Processor speeds haven't increased like we were promised and the code is not capable of taking advantage of parallel processing.
You also seem to be confusing graphical lag which is client side only with the big crushing issue of server side lag. The black screen is a server side issue. Module lag is a server side issue. There's a reason that CCP is developing thin clients that can be run in multiple instances on a single computer and log into the test server for "fleet fight in can". It's to stress the server, not the client.
Originally by: CCP Lemur THIS IS GOD: ... IF YOU HAVE ANY MORE REQUESTS I'M AVAILABLE SUNDAY FROM 10:30 TO 12:00 TO RECEIVE YOUR PRAYERS.
|
Malcanis
Caldari Vanishing Point. The Initiative.
|
Posted - 2010.07.30 09:48:00 -
[9]
Originally by: Atticus Fynch I'll be the first to admit I don't know the technical workings of this, but will putting 0.0 space on a separate shard alleviate lag by any chance?
No it would not.
Malcanis' Law: Whenever a mechanics change is proposed on behalf of "new players", that change is always to the overwhelming advantage of richer, older players. |
Genya Arikaido
|
Posted - 2010.07.30 10:00:00 -
[10]
Might not be a bad idea to simply add more blades & nodes. *Prods CCP*
More blades = fewer "unused" nodes on the same CPU. Fewer nodes sharing a CPU = fewer cases of a system with 10 pilots in it lagging like it has 1000.
Originally by: CCP Tuxford my bad.
Rest assured I'm being ridiculed by my co-workers.
|
|
Jacobs Mori
|
Posted - 2010.07.30 10:06:00 -
[11]
The moment they split eve into more servers is the moment I cancel all my accounts.
|
Riley Moore
Obscurus Research
|
Posted - 2010.07.30 10:47:00 -
[12]
They really need to get their code in line with parallel processing, getting to properly use multi cores would kickass, as well as making use of GPU's to do additional processing (have you seen how much raw power a GPU can bring if used right compared to a CPU?).
I think CCP's main issue is that the original devs are long gone, and no one who still works there understands the very base of the entire code structure. So all they can do is add new code layers on top, so to speak.
------- Obscuras Blueprints Store
|
Noran Ferah
Red Sky Morning
|
Posted - 2010.07.30 10:55:00 -
[13]
Originally by: Jacobs Mori The moment they split eve into more servers is the moment I cancel all my accounts.
agree
|
Ishina Fel
Caldari Terra Incognita Black Star Alliance
|
Posted - 2010.07.30 11:16:00 -
[14]
Originally by: Riley Moore They really need to get their code in line with parallel processing, getting to properly use multi cores would kickass, as well as making use of GPU's to do additional processing (have you seen how much raw power a GPU can bring if used right compared to a CPU?).
I think CCP's main issue is that the original devs are long gone, and no one who still works there understands the very base of the entire code structure. So all they can do is add new code layers on top, so to speak.
If I were you I would be very careful with claiming that the devs don't understand how their code works - considering YOU don't understand how their code works, either.
The issue is not that they're too lazy to make their code multithreaded. It's the fact that they simply cannot. Picture this (example provided by CCP in anogther thread years ago):
Core 1 is currently accessing the memory pertaining information about the ship of your target; for example, an armor repping cycle just went off and the HP need to be adjusted. Therefore it has a "lock" on that particular part of the memory and no other cores can access the information pertaining your target's ship.
Meanwhile, core 2 calculates your guns firing, and determines that your target's ship is out of HP and explodes. It does not know that core 1 is just now updating the HP count of the ship, because the memory is locked. Therefore it declares dead a ship that still has HP left.
Also, core 3 is busy calculating the enemy's guns firing. It does not know that core 2 just determined the enemy ship is already dead, because the memory is locked and core 2 cannot communicate that information to the other cores. So you are still taking damage from an enemy who maybe is already dead (but not for sure), and possibly lose your ship as well (but also possibly not).
Now which of the following cases is true? - The enemy ship reps HP and you live - The enemy ship reps HP and you die as well - The enemy ship dies and you live - The enemy ship dies and you die as well
So tell me again, how do you build a multithreaded combat engine...? Signature? What signature? |
Dan O'Connor
Cerberus Network Dignitas.
|
Posted - 2010.07.30 12:07:00 -
[15]
Originally by: Aessoroz WTH is a shard? Also tranquality is already ran by many servers and the solar systems are distributed across the servers to even the load.
Tranquility IS the shard of EVE.
<My tools>
CCP Zymurgist > lol thats great Dan O'connor
|
Klandi
Science and Trade Institute
|
Posted - 2010.07.30 12:20:00 -
[16]
Ishina, good point
I have some questions
1) Are the cores on the client or the server?
2) If that condition DID exist, surely the devs code would allow perodic checking of the locked memory. If we examine how things happen today, then expand that out to a multicored environment, there must be instances which must be contained on one core rather than splitting them up. What your example shows me is that there are instances that can be split and instances that must not be and programming intelligence must come into play.
Maybe we are mixing up what parallel processing is vs what multicored processing offers
|
Dr Nefarius
|
Posted - 2010.07.30 12:22:00 -
[17]
Originally by: Ishina Fel
So tell me again, how do you build a multithreaded combat engine...?
I think it's fair to say CCP is long overdue with making eve a turnbased game.
|
Gladys Pank
Amarr Trillionaire High-Rollers Suicidal Bassoon Orkesta
|
Posted - 2010.07.30 13:04:00 -
[18]
Originally by: Noran Ferah
Originally by: Jacobs Mori The moment they split eve into more servers is the moment I cancel all my accounts.
agree
Well you should have quit ages ago then. Or do you not acknowledge the Chinese race as relevant? Quit or be racist.
Signature locked for inappropriate image. Zymurgist |
toxicvega
F.R.E.E. Explorer The Initiative.
|
Posted - 2010.07.30 13:10:00 -
[19]
Originally by: Atticus Fynch I'll be the first to admit I don't know the technical workings of this, but will putting 0.0 space on a separate shard alleviate lag by any chance?
Die in a fire.
|
Rowbin Hod
Cloak and Daggers Black Core Alliance
|
Posted - 2010.07.30 13:23:00 -
[20]
For the clueless: shard != node
|
|
Celestine Santora
|
Posted - 2010.07.30 13:28:00 -
[21]
Originally by: Riley Moore They really need to get their code in line with parallel processing, getting to properly use multi cores would kickass, as well as making use of GPU's to do additional processing (have you seen how much raw power a GPU can bring if used right compared to a CPU?).
I think CCP's main issue is that the original devs are long gone, and no one who still works there understands the very base of the entire code structure. So all they can do is add new code layers on top, so to speak.
Considering how rooms full of PHD's, experienced programmers, and otherwise knowledgeable engineers are still struggling with the industry-wide problem of writing parallel programs I don't think it's very surprising that CPP is struggling there too.
|
Ishina Fel
Caldari Terra Incognita Black Star Alliance
|
Posted - 2010.07.30 13:36:00 -
[22]
Originally by: Klandi Ishina, good point
I have some questions
1) Are the cores on the client or the server?
2) If that condition DID exist, surely the devs code would allow perodic checking of the locked memory. If we examine how things happen today, then expand that out to a multicored environment, there must be instances which must be contained on one core rather than splitting them up. What your example shows me is that there are instances that can be split and instances that must not be and programming intelligence must come into play.
Maybe we are mixing up what parallel processing is vs what multicored processing offers
Server side cores. As far as I remember they're running wolfdales with 3.2 or 3.4 GHz, so they are by no means slow CPUs.
And yes, some things can be split apart from the combat engine, and I'm pretty sure they've done that. Unfortunately you're more or less facing the problem of dcale here - the single most resource hungry things (combat calculation & Destiny, AKA ship movement and collision detection) are the things that cannot be parallelized because they depend on each other so much. After all, you can't allow the combat engine to continue applying damage if a ship flew out of targeting range.
Especially the collision detection is an issue (was explained in a devblog on the topic of desyncing at some point) because every object needs to be checked against every other nearby object. So if you have 200 objects and add 1 more, that one object must check against 200 others AND the 200 others must also check against that object, so you have 400 extra checks for 1 additional object. The larger the numbers grow, the more exponentially worse this gets.
Now imagine you have a fleet fight of 300vs300 ships, and suddenly every single ship deploys 5 drones each.
Yeah, that were indeed the voices of one million hamsters all screaming out and suddenly being silenced. Signature? What signature? |
Dr Slaughter
Minmatar Forsaken Legions Mordus Angels
|
Posted - 2010.07.30 13:45:00 -
[23]
1. GPU's won't help as the in-space simulation has a serial combat loop 2. Hypervisor won't help as the in-space sim is running on ONE SINGLE CORE and all the cores are the same (I lie slightly but the point is that migrating an entire windows instance to another blade that has cores that are only a tiny bit more powerful won't make up for the loss in speed caused by the hypervisor)
3. Faster CPUs will help increase max number of clients being serviced (there will still be lag when you reach the magic number) 4. Refactoring CCP's code to minimize the other services that are taking up CPU slices on that single core, will help. They are and have been, doing this. 5. Adding support for HPC style shared memory (via infiniband) between nodes will help reduce load times between systems on different nodes, and may give them the infrastructure to dynamically shift SOL nodes to quicker blades. This may make it possible to automatically 're-enforce' a node.
It's impossible to 'fix' lag entirely in a system that allows you to keep adding players to the fight and solving a n-body scaling problem for real time combat is non-trivial.
Would be nice to be able to have 200-300 vs 200-300 with almost no lag though, and it would be great, if the UI was better at handling lag (if it told me it was waiting for the server and gave me an idea when it was likely to next be able to send a command that might stop people rage spamming buttons quite so much) ;)
|
Ressiv
Cooperative Freelance Navigators Association
|
Posted - 2010.07.30 13:45:00 -
[24]
Originally by: Ishina Fel
Yeah, that were indeed the voices of one million hamsters all screaming out and suddenly being silenced.
You just made my day by explaining this in easy to comprehend words. Not that it will be understood now, but it did make this joke very funny ========================== Nothing is true, everything is permitted. ========================== |
Tres Farmer
Gallente Federation Intelligence Service
|
Posted - 2010.07.30 14:22:00 -
[25]
Originally by: Ishina Fel Edited by: Ishina Fel on 30/07/2010 13:38:46
Originally by: Klandi Ishina, good point
I have some questions
1) Are the cores on the client or the server?
2) If that condition DID exist, surely the devs code would allow perodic checking of the locked memory. If we examine how things happen today, then expand that out to a multicored environment, there must be instances which must be contained on one core rather than splitting them up. What your example shows me is that there are instances that can be split and instances that must not be and programming intelligence must come into play.
Maybe we are mixing up what parallel processing is vs what multicored processing offers
Server side cores. As far as I remember they're running wolfdales with 3.2 or 3.4 GHz, so they are by no means slow CPUs.
And yes, some things can be split apart from the combat engine, and I'm pretty sure they've done that. Unfortunately you're more or less facing the problem of scale here - you can split off some small things, but the single most resource hungry things (combat calculation & Destiny, AKA ship movement and collision detection) are the things that cannot be parallelized because they depend on each other so much. After all, you can't allow the combat engine to continue applying damage if a ship flew out of targeting range.
Especially the collision detection is an issue (was explained in a devblog on the topic of desyncing at some point) because every object needs to be checked against every other nearby object. So if you have 200 objects and add 1 more, that one object must check against 200 others AND the 200 others must also check against that object, so you have 400 extra checks for 1 additional object. The larger the numbers grow, the more exponentially worse this gets.
Now imagine you have a fleet fight of 300vs300 ships, and suddenly every single ship deploys 5 drones each.
Yeah, that were indeed the voices of one million hamsters all screaming out and suddenly being silenced.
That is a problem yes, but i think (might be completely wrong here) that we're actually not at this barrier yet, we got options...
The smallest thing a core can run is a solar system (lets call this environment-node). So if ccp would be able to reduce this e-node to grid-size (smallest thing we know a fight can happen in) we would have some leeway by probably a factor of 2-3 as all other stuff in the solar system wouldn't matter as it would run on other cores..
The next thing which isn't possible yet is the live movement of such a piece of running software (e-node) from one core where it is running with all the other e-nodes onto another free core with less/no load.
Afaik is ccp working on the latter (live movement of e-nodes), at least that was the information given to us 1 year ago.
Once both those things are ingame we might see fleetfights of 2000+ without pre-ordering of a reinforced node.
|
alittlebirdy
|
Posted - 2010.07.30 14:27:00 -
[26]
Originally by: Ishina Fel
Stuff
Dumb much?, seeing as right now supercaps sometimes respawn after DT... I don't think the server knows anyway! So one core or 10000 cores... what's the difference? No lag / black screen?
|
Ishina Fel
Caldari Terra Incognita Black Star Alliance
|
Posted - 2010.07.30 15:00:00 -
[27]
Originally by: Tres Farmer
The smallest thing a core can run is a solar system (lets call this environment-node). So if ccp would be able to reduce this e-node to grid-size (smallest thing we know a fight can happen in) we would have some leeway by probably a factor of 2-3 as all other stuff in the solar system wouldn't matter as it would run on other cores..
The next thing which isn't possible yet is the live movement of such a piece of running software (e-node) from one core where it is running with all the other e-nodes onto another free core with less/no load.
Afaik is ccp working on the latter (live movement of e-nodes), at least that was the information given to us 1 year ago.
Yeah, that were musings thrown around in the thread discussing the "HPC Cluster Project" (aka Infiniband implementation). Even the treatment of singular grids as a process/node/whatchamacallit was considered.
That said, I work in server cluster monitoring and operation at the moment, and you wouldn't believe how many great ideas are made impossible by the most banal of issues. It's ridiculous! I do not know how far CCP got with the whole HPC project, nor if they are even working on it still, and if yes, which desired features they had to give up on due to technical limitations... we haven't heard anything in a while now.
Of course, Incarna was also announced ages ago and arrives only six months from now. Maybe when CCP tackles the next large-scale upgrade of the cluster hardware, we'll once again hear news on their plans in this regard.
Signature? What signature? |
Professor Tarantula
Hedion University
|
Posted - 2010.07.30 15:13:00 -
[28]
How about putting nullsec and everyone in it on a USB hard drive, and throwing it into Eyjafjallajokull?
My deepest sympathies. Prof. Tarantula, Esq. |
Tres Farmer
Gallente Federation Intelligence Service
|
Posted - 2010.07.30 15:17:00 -
[29]
Originally by: Ishina Fel
Originally by: Tres Farmer
The smallest thing a core can run is a solar system (lets call this environment-node). So if ccp would be able to reduce this e-node to grid-size (smallest thing we know a fight can happen in) we would have some leeway by probably a factor of 2-3 as all other stuff in the solar system wouldn't matter as it would run on other cores..
The next thing which isn't possible yet is the live movement of such a piece of running software (e-node) from one core where it is running with all the other e-nodes onto another free core with less/no load.
Afaik is ccp working on the latter (live movement of e-nodes), at least that was the information given to us 1 year ago.
Yeah, that were musings thrown around in the thread discussing the "HPC Cluster Project" (aka Infiniband implementation). Even the treatment of singular grids as a process/node/whatchamacallit was considered.
That said, I work in server cluster monitoring and operation at the moment, and you wouldn't believe how many great ideas are made impossible by the most banal of issues. It's ridiculous! I do not know how far CCP got with the whole HPC project, nor if they are even working on it still, and if yes, which desired features they had to give up on due to technical limitations... we haven't heard anything in a while now.
Of course, Incarna was also announced ages ago and arrives only six months from now. Maybe when CCP tackles the next large-scale upgrade of the cluster hardware, we'll once again hear news on their plans in this regard.
Yeah, some update would be nice.. can't remember the DEV posting then had been harassed or mocked with by the nerds, so he shouldn't have sentiments/fear posting some updates on that matter.
@Prof.. troll somewhere else.
|
Kuar Z'thain
Amok. Goonswarm Federation
|
Posted - 2010.07.30 15:34:00 -
[30]
CCP bet on processor speeds constantly increasing...
And lost.
Next time ask the hardware guys what they think of your programmer's wonderful idea of code that will require faster and faster processors with the more users you have on the system.
There's a reason we don't have 4+ GHz CPUs and you should have seen the writing on the wall back in 2000.
Were you guys praying cooling solutions would get better or what?
Oh well, hindsight 20/20 and all that.
|
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |