open All Channels
seplocked EVE General Discussion
blankseplocked How about putting null-sec on a separate shard?
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: [1] 2

Author Topic

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
Nohbdy.
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
Men of Questionable Moral Fibre
Posted - 2010.07.30 05:35:00 - [3]
 

No. just no.

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
Space Mermaids
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.

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.

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.

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
Sentinum 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.

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
Intrepid Crossing
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...?

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.

Klandi
Consortium of stella Technologies
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.

toxicvega
F.R.E.E. Explorer
EVE Animal Control
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
InterSun Freelance
The Forsaken.
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
Intrepid Crossing
Posted - 2010.07.30 13:36:00 - [22]
 

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. Laughing

Dr Slaughter
Minmatar
Coreli Corporation
Naraka.
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
Massive PVPness
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. Laughing


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 Laughing

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. Laughing

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
Intrepid Crossing
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! Shocked 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.

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?

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! Shocked 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. Wink

@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

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only