Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 3 post(s) |
Tigerium Volante
Internet Terrorists SpaceMonkey's Alliance
0
|
Posted - 2014.09.07 18:11:13 -
[1] - Quote
So I've been doing a lot of reading lately and i'm just curious..
Tranquility has lots of Nodes used for each Solar system. When there's a ton of load on a single system (like Jita) you assign a special node to it. But when there's large battles happening there's still TiDi. So why not create special nodes that allow for the giant battle happen without any TiDi. You'd only need 1 or 2 of them since there's generally only one giant battle happening at once. Or is there some technical limits i'm not seeing here? |
|
CCP FoxFour
C C P C C P Alliance
3583
|
Posted - 2014.09.08 08:11:37 -
[2] - Quote
"without any TiDi" is, at this point in time, not really possible. What we do have are dedicated fleet fight nodes, and so long as we are told before downtime that a fight is going to happen via the fleet fight notification on the community web site, we will move that solar system to a fleet fight node all on it's during downtime.
The recent Revenant kill event happened with that solar system on a node all to it's self.
At this point in time there just isn't really hardware available to use to do what we need. The biggest thing to keep in mind is that our server code is not multithreaded, for the most part it all runs on a single core. Processor technology for the last few generations has been real big about expanding out into multiple cores, not higher clock rates. We love higher clock rates. They be good for us.
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Sara Tosa
School of Applied Knowledge Caldari State
107
|
Posted - 2014.09.08 09:02:20 -
[3] - Quote
Tigerium Volante wrote:So I've been doing a lot of reading lately and i'm just curious..
Tranquility has lots of Nodes used for each Solar system. When there's a ton of load on a single system (like Jita) you assign a special node to it. But when there's large battles happening there's still TiDi. So why not create special nodes that allow for the giant battle happen without any TiDi. You'd only need 1 or 2 of them since there's generally only one giant battle happening at once. Or is there some technical limits i'm not seeing here? they are allready doing everything that's possible within technological and budgetary limits, its just that everytimes they rise the bar people start bringing even more people on grid. if they bought new superservers capable to handle 5000 people fights, you would see 10000 ones and people whining about lag as its now. |
Sentient Blade
Crisis Atmosphere
1384
|
Posted - 2014.09.08 10:42:14 -
[4] - Quote
Sara Tosa wrote:if they bought new superservers capable to handle 5000 people fights, you would see 10000 ones and people whining about lag as its now.
If they'd spent the money they spent on WoD on re-writing the server code to be multi-threaded they'd be able to support the entire galaxy fighting on one machine* ;)
* Subject to memory bandwidth limitations |
Tyberius Franklin
Federal Navy Academy Gallente Federation
1263
|
Posted - 2014.09.08 20:53:32 -
[5] - Quote
Sentient Blade wrote:Sara Tosa wrote:if they bought new superservers capable to handle 5000 people fights, you would see 10000 ones and people whining about lag as its now. If they'd spent the money they spent on WoD on re-writing the server code to be multi-threaded they'd be able to support the entire galaxy fighting on one machine* ;) * Subject to memory bandwidth limitations Multi-threading only helps when tasks are relatively independent. The past explanations of server performance seemed to indicate that this isn't the case for the majority of lag causing activity.
|
Dragonaire
Here there be Dragons
64
|
Posted - 2014.09.08 21:02:15 -
[6] - Quote
Some day CCP will figure out this whole multiple cores thing is not a fad and make the switch I figure about the time 32-64 cores because the norm at the current rate they are going
Finds camping stations from the inside much easier.
Designer of Yapeal-á for the Eve API.
Check out the Yapeal PHP API Library thread for more information.
|
Durzel
Questionable Ethics. Ministry of Inappropriate Footwork
273
|
Posted - 2014.09.08 23:40:06 -
[7] - Quote
Threads aren't always the right way to go, and in some cases can lead to worse performance - not better.
That's even without touching on the myriad of new and exciting quirky random behaviours it can lead to, or how it complicates debugging. It isn't exactly trivial either, not least with something of the complexity of Eve. |
Dragonaire
Here there be Dragons
64
|
Posted - 2014.09.09 01:33:54 -
[8] - Quote
Didn't say it would be trivial either but since there are already hundreds of other games as complex as Eve and more than that of other types of programs that do it largely correctly every day it's really time that CCP do the same.
The whole 'stack-less' Python idea that is used in Eve is basically the same thing the older AmigaOS did almost 20 years ago and was tried other places but has been replaced by the preemptive way of doing things by every OS still around. Windows, Linux, and OS X all use it and Eve can too Try to do the job of task scheduling in a high level language like Python is never going to out perform the OS working at the machine level and that IS what they are trying to do. I'll give them credit they've pushed it farther and made it work much longer than most people thought they could but in the end it only works as long as processors keep getting fast and just like CCP FoxFour indirectly pointed out processors really haven't been getting faster clock speeds. This has been true for almost 10 years now and isn't expect to change so multiple cores has been the only way to continue to increase performance in both processors and programs and isn't going to change even if they find ways around the issues currently holding clock rates down like the speed of light, etc.
Okay I'll get off my soapbox now since the thread has kind of got away from the original person's question I have a feel.
Finds camping stations from the inside much easier.
Designer of Yapeal-á for the Eve API.
Check out the Yapeal PHP API Library thread for more information.
|
Pete Butcher
Kiss My Shiny Metal Ass
243
|
Posted - 2014.09.09 20:35:56 -
[9] - Quote
In a perfect world, CCP would have enough resources to rewrite eve to modern multithreaded c++, and I bet any amount of beer we'd have 10k battles without a hint of Tidi. One can only dream...
http://evernus.com - the ultimate [u]multiplatform[/u]-áEVE trade tool
http://tradeadvisor.evernus.com - find what to trade anywhere
|
Smallevils
Association of Commonwealth Enterprises Nulli Secunda
2
|
Posted - 2014.09.10 02:29:55 -
[10] - Quote
Hi all.
Now, i don't normal post in forums, mainly due trolls and flames however occasionally i will post if i see something i feel strongly about.
There appears to be many assumptions in the above statements and a lack of understanding in how eve is set up.
When eve was first begin designed multi-core processors were only just coming out and threading on them was not well supported. For instance, when the first multi-cores came out, it took at least a year before any real programs supported them...
Eve is primarily build on stackless python. This at the time offered many benefits. However, stackless languages work differently from normal languages, eg, they don't use a stack, but rather pass a token around. Changing the eve server to support threading would most likely require a rewrite of the entire server,as threads exist as self contained process on a core passing a token between threads would not be easy, and the overhead for inter-thread communication would be quite big with a stackless setup.
Now, to give you an idea of just how much work that would be, let me refer to good old windows 98. Windows 98 is very old, and a lot smaller than a lot of software out today. and yet...for one man to write windows 98 ..it would take him......168 years...this statistic is from Microsoft its self based on the man hours used to create 98. This should give you a good idea of the scale of rewriting the eve server and clients.
The eve server does in fact use cores, but primarily on the solar system blades. Each on a blade processor 1 core == a node. With this set up, the solar system blades would not be able to thread anyway. And although i know other services like Dogma reside on different servers, you can start see what a huge job it would be to rewrite eve to thread.
I believe ccp has been rewriting bits of its code, in fact Carbon I/O is one such rewrite. I also know from keynotes that they are trying to(or woudl like to) move at least some of the code to c libs. However, considering the above it will take quite a while if ever to thread eve.
In the end, ccp must balance its resources between content and rewrites, Right now there is a huge change in game mechanics, so that new content can be rolled out aka destroy-able everything and player build star gates etc etc.
I would think if ccp decided to thread eve, you would not see any new content or changes for at least 1 year, maybe 2...and i am fairly sure that the stagnation of the game would drive many away, and then whats the point in threading a dead game.
In summary. Eve Could be threaded, but the time and resource to do it in the near future would cripple development of the game features itself, and in the near to medium term is not really feasible.
And before any trolls kick in, Yes i know what i am talking about in regards to threading, but i have dumbed it down for general consumption Smallevils |
|
Dragonaire
Here there be Dragons
64
|
Posted - 2014.09.11 07:49:10 -
[11] - Quote
Smallevils - You are right about what you said and I absolutely agree it not a small undertaking but do you really think eve will be able to keep up with newer games in another 10 years if they don't start fixing things now? They have as you pointed out done several things to break part of the server and client out so they can use threads in places I'm just saying it seems like they are spending a lot of time trying to extend the live on something that has to be replaced if Eve is going to continue. With the new shorter development cycle they have gone to it make much more sense to spend more time on it now so they get feedback and can tweak things as they go. The longer they wait the more code from the newer content has to be converted as well so you are basically continuing to shoot yourself in the foot by putting it off.
Finds camping stations from the inside much easier.
Designer of Yapeal-á for the Eve API.
Check out the Yapeal PHP API Library thread for more information.
|
Pete Butcher
Kiss My Shiny Metal Ass
243
|
Posted - 2014.09.11 09:15:12 -
[12] - Quote
Dragonaire wrote:Smallevils - You are right about what you said and I absolutely agree it not a small undertaking but do you really think eve will be able to keep up with newer games in another 10 years if they don't start fixing things now? They have as you pointed out done several things to break part of the server and client out so they can use threads in places I'm just saying it seems like they are spending a lot of time trying to extend the live on something that has to be replaced if Eve is going to continue. With the new shorter development cycle they have gone to it make much more sense to spend more time on it now so they get feedback and can tweak things as they go. The longer they wait the more code from the newer content has to be converted as well so you are basically continuing to shoot yourself in the foot by putting it off.
If there aren't enough resources available, it's just not possible to do such an overhaul. It doesn't matter what will be. Like the old saying goes: if it ain't broke, don't fix it. Unless eve grinds to a halt, I doubt any serious work will take place. More like workarounds in problematic places.
http://evernus.com - the ultimate [u]multiplatform[/u]-áEVE trade tool
http://tradeadvisor.evernus.com - find what to trade anywhere
|
omgdutch2005
FinFleet Northern Coalition.
6
|
Posted - 2014.09.12 14:49:40 -
[13] - Quote
Pete Butcher wrote:Dragonaire wrote:Smallevils - You are right about what you said and I absolutely agree it not a small undertaking but do you really think eve will be able to keep up with newer games in another 10 years if they don't start fixing things now? They have as you pointed out done several things to break part of the server and client out so they can use threads in places I'm just saying it seems like they are spending a lot of time trying to extend the live on something that has to be replaced if Eve is going to continue. With the new shorter development cycle they have gone to it make much more sense to spend more time on it now so they get feedback and can tweak things as they go. The longer they wait the more code from the newer content has to be converted as well so you are basically continuing to shoot yourself in the foot by putting it off. If there aren't enough resources available, it's just not possible to do such an overhaul. It doesn't matter what will be. Like the old saying goes: if it ain't broke, don't fix it. Unless eve grinds to a halt, I doubt any serious work will take place. More like workarounds in problematic places.
Isnt it considered broken already? I mean the work around is the TiDi...
Perhaps a croudfunding for some more dev's so they finally can re-write the code?
I mean if 5K players on 1 core are now 1% TiDi, with current quad or octa core, the performance would be significant of only it would have been like 50% more efficient.... |
Pete Butcher
Kiss My Shiny Metal Ass
243
|
Posted - 2014.09.12 15:29:38 -
[14] - Quote
omgdutch2005 wrote:Isnt it considered broken already? I mean the work around is the TiDi...
It depends on what you consider "broken". From a business perspective, it usually looks like this:
- Is it up and brings money? - Yes. - It's not broken!
So, unless someone manages to convince upper management to make this investment, Eve will never be brought technologically up-to-date. That's how the IT world works.
omgdutch2005 wrote:Perhaps a croudfunding for some more dev's so they finally can re-write the code?
You have no idea how much such project would cost. This would most likely be measured in millions.
http://evernus.com - the ultimate [u]multiplatform[/u]-áEVE trade tool
http://tradeadvisor.evernus.com - find what to trade anywhere
|
|
CCP Explorer
C C P C C P Alliance
2411
|
Posted - 2014.09.15 09:48:58 -
[15] - Quote
CCP FoxFour wrote:"without any TiDi" is, at this point in time, not really possible. What we do have are dedicated fleet fight nodes, and so long as we are told before downtime that a fight is going to happen via the fleet fight notification on the community web site, we will move that solar system to a fleet fight node all on it's during downtime.
The recent Revenant kill event happened with that solar system on a node all to it's self.
At this point in time there just isn't really hardware available to use to do what we need. The biggest thing to keep in mind is that our server code is not multithreaded, for the most part it all runs on a single core. Processor technology for the last few generations has been real big about expanding out into multiple cores, not higher clock rates. We love higher clock rates. They be good for us. We love even more to have increased on-chip cache sizes and increased memory bus bandwidth. There was an extended discussion here https://forums.eveonline.com/default.aspx?g=posts&t=371873 on the Revenant event.
Erlendur S. Thorsteinsson | Senior Development Director | EVE Online // CCP Games | @erlendur
|
|
|
CCP FoxFour
C C P C C P Alliance
3583
|
Posted - 2014.09.15 12:53:52 -
[16] - Quote
CCP Explorer wrote:CCP FoxFour wrote:"without any TiDi" is, at this point in time, not really possible. What we do have are dedicated fleet fight nodes, and so long as we are told before downtime that a fight is going to happen via the fleet fight notification on the community web site, we will move that solar system to a fleet fight node all on it's during downtime.
The recent Revenant kill event happened with that solar system on a node all to it's self.
At this point in time there just isn't really hardware available to use to do what we need. The biggest thing to keep in mind is that our server code is not multithreaded, for the most part it all runs on a single core. Processor technology for the last few generations has been real big about expanding out into multiple cores, not higher clock rates. We love higher clock rates. They be good for us. We love even more to have increased on-chip cache sizes and increased memory bus bandwidth. There was an extended discussion here https://forums.eveonline.com/default.aspx?g=posts&t=371873 on the Revenant event.
Well thats a real nice discussion and I am now going to shut up about things I don't understand so well.
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Eklykti
Zion foundation Legion of xXDEATHXx
10
|
Posted - 2014.09.16 23:16:16 -
[17] - Quote
Tyberius Franklin wrote:Multi-threading only helps when tasks are relatively independent. ShipA and ShipB are flying independently unless they bump. ShipC and ShipD are shooting each other independently of ShipW, ShipX and ShipY shooting ShipZ. ShipN indepently warped out to a distant moon and has been wrecked there by a control tower guns. All this now happens in one single thread for entire solarsystem. This sucks. |
Atum
Eclipse Industrials Quantum Forge
111
|
Posted - 2014.09.19 17:39:41 -
[18] - Quote
Eklykti wrote:Tyberius Franklin wrote:Multi-threading only helps when tasks are relatively independent. ShipA and ShipB are flying independently unless they bump. ShipC and ShipD are shooting each other independently of ShipW, ShipX and ShipY shooting ShipZ. ShipN indepently warped out to a distant moon and has been wrecked there by a control tower guns. All this now happens in one single thread for entire solarsystem. This sucks. Yes, but it was designed this way nearly 15 years ago, when multi-core and multi-threading were going to be released Soon(tm). I don't remember the latest dev blogs on Dogma's design mentioning this, but about the only workaround I realistically see happening is to place each simulation grid in its own thread. Of course, this would break things like probing for PVP targets since one simulation thread would be independent of another unless you do things like cache sharing (which isn't guaranteed to return correct results because the cache could be stale), and I'm pretty sure everybody would agree that's a Bad Thing(tm). |
Joshua Foiritain
Coreli Corporation Ineluctable.
1212
|
Posted - 2014.09.20 09:08:36 -
[19] - Quote
Eklykti wrote:Tyberius Franklin wrote:Multi-threading only helps when tasks are relatively independent. ShipA and ShipB are flying independently unless they bump. ShipC and ShipD are shooting each other independently of ShipW, ShipX and ShipY shooting ShipZ. ShipN indepently warped out to a distant moon and has been wrecked there by a control tower guns. All this now happens in one single thread for entire solarsystem. This sucks.
lol that's not even remotely close to how it works. Just because two objects aren't physically interacting in game doesn't mean they're not interacting in the code.
When you hit dscan the server has to access the locations of all ships in system to see if they're in range and should be displayed on your scanner. Result; your thread is pausing until all other threads are done processing their ship movements so it can get updated locations. Performance increase from multithreading reduced or removed and potential performance decrease from the increased overhead added.
And that's just a single instance, there are a fuckton of ways ships interact within system without actually seeing each other that will ruin most of the performance gain provided by multithreading. The idea that 2x threads = 2x performance is hilariously clueless.
Come play Crink, over 192 billion in prizes paid out already!
Join the channel 'crink' in game or visit crink.corelicorp.net to play.
|
Eklykti
Zion foundation Legion of xXDEATHXx
10
|
Posted - 2014.09.20 09:28:49 -
[20] - Quote
My noobish opinion about how it could be:
Each ship is a separate thread (or possibly something like an Erlang 'process'). When the ship need to interact with another, it sends them a message, something like 'I shoot you with GM Ultra Mega Super Death Ray for 100500 damage', and receives a reply 'you made 1005 damage' (because the tarhet ship has 99% resistances).
Scanning will posibly be something like a broadcast message 'Report all who are in range of 14 au from my position', and the result is displayed after receiving all responces. This can be done asynchronously and doesn't require to pause an entire thread until all other threads respond.
Possibly this will also require a separate physics thread for each active grid. |
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |