Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Motorcycle Emptiness
Gallente Federal Navy Academy
|
Posted - 2007.03.30 10:27:00 -
[1]
Edited by: Motorcycle Emptiness on 30/03/2007 10:25:07 We've all been told that they're basically the best money can buy, so what are they, and what do other games use? (pictures would be nice ^.^)
Perhaps it will put an end to the CCP have crap servers thing, and help people realise that playable 1000+ man fleets simply can't be done over the current internet.
we've already been told they use these monsters
http://www.superssd.com/
oh! and look, a CCP quote on the main page :P
(http://www.superssd.com/success/ccpgames.htm)
Flashing White Box (rank 1) |
Karmic
Caldari Sharks With Frickin' Laser Beams Mercenary Coalition
|
Posted - 2007.03.30 10:33:00 -
[2]
I believe there are 2 ramsans now and a heap of ibm blade servers. Also I think they have been adding more blades recently, would be nice to know thou I think they should issue a piccie of the server which hosts Jita. - - - - - - - - -
|
Vegetto Ichikai
Caldari Point-Zero Ratel Alliance
|
Posted - 2007.03.30 10:37:00 -
[3]
500 Hamsters working in tandem, overseen by a giant Chinchilla. During downtime, the Chief Chinchilla chooses which Hamsters are worthy for the next days uptime. Those deemed unworthy get fed to the mods on toasted sandwich.
It's like a viking warship, where the Chinchilla bangs a drum for the hamsters to work to.
|
ApaKaka
Minmatar
|
Posted - 2007.03.30 10:57:00 -
[4]
Solution to problem:
1. IP-anycasting. similar to Root DNS:es on the internet. All servers share the same IP, but can be in any country, and the closest/fastest to the user responds.
2. Change the platform to redistribute load over nodes depending on current needs. One server can host many system-nodes, several servers can host one system-node. All dynamically according to what's needed.
The problem really isn't hardware, as there are a lot of unused flops and servers wasted for systems that have no activity, while others naturally have a heavy load because of wars or on-the-highway activity. The Eve platform is built on an old generation of ideas, albeit very impressive in what it can do, it wastes a lot of cpu resources.
We've all seen how impressive results distributed 'screensaver' programs that calculate cancer-treatments or folding proteins or finding primes give. They use every cycle for something worthwhile. Eve just can't do that.
But yeah, throw more hardware at the problem, wait for hardware to get faster, more energy efficient, and we can keep upping the cap on players by a couple of hundred for every system once every year.
|
Pan Crastus
|
Posted - 2007.03.30 11:04:00 -
[5]
Originally by: ApaKaka Solution to problem:
Your assumptions are wrong. The problem isn't the network, it's the fact that the crappy server-side code can only use 1 CPU(!) per system. At least that's what CCP said.
So they should hire someone with a clue about multithreading, rewrite that part of the code to utilize several CPUs effectively (it's not as if the type of workload isn't inherently suited for multithreading) and buy some 8- or 16-way boxes.
|
|
Chribba
Otherworld Enterprises Otherworld Empire
|
Posted - 2007.03.30 11:05:00 -
[6]
any anycasting is what any average company can do without good relations to the major IXP...
Help me help you. |
|
ApaKaka
Minmatar
|
Posted - 2007.03.30 11:11:00 -
[7]
Your assumptions are wrong. The problem isn't the network, it's the fact that the crappy server-side code can only use 1 CPU(!) per system. At least that's what CCP said.
Not really talking about network only here, it's dependant on solution 2) really, as with a fat internal pipe between servers they could be localized anywhere geographically but still share the same system-node.
That way if one geographic region is naturally more inclined to load the system, you can just put more servers less jumps (packet-wise) to that. That would reduce a lot of of network stack control which means a lot of cpu saved in not having to resend or recalculate lost or unacknowledged client-server transfers.
But number 2) is basically what you're saying, just that limiting the programming to one server per node is still not enough imo. It needs to be distributed with a solid, and almost on the level of supercomputing, solution.
|
Splagada
Minmatar Tides of Silence Hydra Alliance
|
Posted - 2007.03.30 11:16:00 -
[8]
The node went down because CCP was busy with a corporate meeting.
Things went back to normal after a couple hours and a few coffees ------
Relaxed corp recruiting |
ApaKaka
Minmatar
|
Posted - 2007.03.30 11:17:00 -
[9]
Originally by: Splagada The node went down because CCP was busy with a corporate meeting.
Things went back to normal after a couple hours and a few coffees
ROFL. What I wouldn't give for my computer to have all those oldschool gauges and whatnot :D
|
Splagada
Minmatar Tides of Silence Hydra Alliance
|
Posted - 2007.03.30 11:23:00 -
[10]
and me for such corporate meetings! ------
Relaxed corp recruiting |
|
Emily Spankratchet
Minmatar Pragmatics
|
Posted - 2007.03.30 11:35:00 -
[11]
Originally by: ApaKaka 1. IP-anycasting. similar to Root DNS:es on the internet. All servers share the same IP, but can be in any country, and the closest/fastest to the user responds.
But would that help? There's a single database at the heart of all this, and spreading your servers geographically might just move the problems to a different part of the system as a whole.
|
Vasiliyan
PAX Interstellar Services Freelancer Alliance
|
Posted - 2007.03.30 11:35:00 -
[12]
Originally by: Pan Crastus
Originally by: ApaKaka Solution to problem:
Your assumptions are wrong. The problem isn't the network, it's the fact that the crappy server-side code can only use 1 CPU(!) per system. At least that's what CCP said.
So they should hire someone with a clue about multithreading, rewrite that part of the code to utilize several CPUs effectively (it's not as if the type of workload isn't inherently suited for multithreading) and buy some 8- or 16-way boxes.
Multithreading is a lot harder than you make it sound.
I suspect the key issue is not so much computing stuff as synchronising stuff. I thikn your average home PC would be able to handle the simulation calculations necessary for a fleet battle, the difficult bit is getting that data formatted and sent out to the right places in a very short amount of time.
|
Maam
|
Posted - 2007.03.30 11:49:00 -
[13]
I have no idea where the bottleneck lies. Only the CCP insiders would really have this information. CCP do have experts working on this, but to be honest I think the only real way of making bigger inroads to the lag problem might involve too much of a rebuild from the ground up.
Given a complete blank cheque and clear page to start on, I'd be thinking about:
Hiring a major, major expert in a low level language to absolutely tighten the critical code as much as possible. Ideally look into ways to parallelise that code.
Split the functions of the code as much as possible, so different servers can handle "non space" actions such as market, hangar contents etc. and other servers can just concentrate on "in space" actions like communicating ship positions etc.
Keep a rolling pattern of buying a couple of the fastest possible servers every couple of weeks.
I imagine CCP will be well aware of the problems and will try to sort things out. It just depends on how many resources they will bring to bear on fixing "boring" behind the scenes stuff.
I would love to see a Dev blog addressing these changes, talking about CPU / network load, objects calculated per second, that sort of thing.
From my point of view, things started to go badly from the release of RmR (I think ... the Christmas 2005 patch)
|
ApaKaka
Minmatar
|
Posted - 2007.03.30 11:54:00 -
[14]
Well, so far as I understand. There are a big number of bottlenecks that can potentially happen. I don't think even CCP has them all covered as gameplay changes by the smallest balance fixes or release of a new shiptype etc, eg. new bottlenecks ensue.
The question though, is what can they do? Well, I think they have an excellent opportunity with the new engine they are making to also make a solid network and computing platform that lie at the bottom of the whole Eve engine. A completely new platform.
This is almost on par with creating a new OS though, with all sorts of scheduling and smart algorithms, and mainly a sound future-safe foundation, and takes a huge amount of resources. The game itself doesn't necessarily need to change, just what it lies on top of, kind of a huge virtual computer composed of potentially thousands of servers.
While expensive, yes, I think it's the only way to go forward to grow the game.
|
TOGAKURE Daisuke
Sty's Haulink
|
Posted - 2007.03.30 14:06:00 -
[15]
I just think that they should have taken a different approach to the resource allocation. Having resources bound to nodes causes overloads while if threads in cpu's were tied to players... They would just need to add cpu's to allow more players when they hit the hard cap.
This would of course also mean that they would have to run a realtime os.
And a crap load of different synchronization problems that completely different pov to resource allocation causes.
And then they should stop buying those crappy IBM blades *hate them* and go for the good next-get HP blades with kick-ass interconnects (just installing a c7000).
|
RaTTuS
BIG Interstellar Alcohol Conglomerate
|
Posted - 2007.03.30 14:17:00 -
[16]
Old but relevent -- BIG Lottery, BIG Deal | RaTTuS @ Skills Showroom
|
Topaz Skydiver
Minmatar Narrative Freshfood
|
Posted - 2007.03.30 14:22:00 -
[17]
Edited by: Topaz Skydiver on 30/03/2007 14:22:45
Originally by: TOGAKURE Daisuke I just think that they should have taken a different approach to the resource allocation. Having resources bound to nodes causes overloads while if threads in cpu's were tied to players... They would just need to add cpu's to allow more players when they hit the hard cap.
A lot of those players interact with eachother and the environment. So if there is a thread for each player, those threads need to communicate and access common data.
Now you might think: Ok, lets put all these players, who can interact with eachother, on the same node to keep that communication overhead low (accessing shared memory is cheap), put the environment simulation there too and then you have the whole system on that node, or at least the grid.
Ok, it can be done differently, but it could be a reason, why they chose to put the whole system on a single node.
|
Random Caldari
|
Posted - 2007.03.30 15:18:00 -
[18]
The problem is not with the speed of the internet. It is not with the distribution of nodes over cpus/threads/servers
The problem is in the design limitations of the game and is essentially unsolvable.
10 ship battle. the position and status of 10 ships has to be comunicated to 10 players. 10 x 10 = 100 operations.
100 ship battle. the position and status of 100 ships has to be comunicatted to 100 players.
100 x 100 = 10,000 operations.
1000 ship battle. 1000 x 1000 = 1,000,000 operations.
As fleet sizes increase the amount of work that needs to be done increases Quadratically.
If you want to eliminate lag then you would have to accept a cap on the number of ships allowed in any one system/node.
|
Yggdrassil
STK Scientific Rule of Three
|
Posted - 2007.03.30 15:25:00 -
[19]
Originally by: Random Caldari The problem is not with the speed of the internet. It is not with the distribution of nodes over cpus/threads/servers
The problem is in the design limitations of the game and is essentially unsolvable.
10 ship battle. the position and status of 10 ships has to be comunicated to 10 players. 10 x 10 = 100 operations.
100 ship battle. the position and status of 100 ships has to be comunicatted to 100 players.
100 x 100 = 10,000 operations.
1000 ship battle. 1000 x 1000 = 1,000,000 operations.
As fleet sizes increase the amount of work that needs to be done increases Quadratically.
If you want to eliminate lag then you would have to accept a cap on the number of ships allowed in any one system/node.
Then add each ship shooting 2 times each sec: (100*2) * (100*2) = 40.000 operations.
Then each ship has 5 drones: (100*5) * (100*5) = 250.000 operations.
Add gang benefits, hardeners, sensor boosters ++ - and you have a ****LOAD of caluculations that got to be done every second.
Yggdrassil |
Jason Marshall
Hammer Of Light
|
Posted - 2007.03.30 15:31:00 -
[20]
/me jumps up and down so that some of this stuff might hit him instead of flying over his head.
So...guys i have what they call a Central Proccesing Unit on my PC.
And a hard drive, that kinda sounds kinky if you think about it.
LETS SEE YOU NERF THIS ONE Kreul!!!... ...if that is your REAL name o_O Tacky lens flares in sigs 4tw! |
|
Robin Sherwood
|
Posted - 2007.03.30 15:44:00 -
[21]
No idea for server induced throughput/latency, but there's *obvious* huge latency (a.k.a. lag) caused by the client. Just open a page in the IGB, browse market data, etc - everything freezes for a few seconds. I could make the educated guess that this is due to the non-preemptive nature of Stackless Python "threads".
|
Jim McGregor
|
Posted - 2007.03.30 16:21:00 -
[22]
The solution is to rewrite Eve in assembler. Doh! --- Eve Wiki | Eve Tribune |
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |