| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
SleepingBuddah
   |
Posted - 2007.06.27 13:34:00 -
[1]
Edited by: SleepingBuddah on 27/06/2007 13:39:08
It seems that lag problem comes from fact that server works in real time. Even in lag if your warp speed is 5au/s you will fly 20 au in 4 secs
It cases server to choke from incoming and outgoing data.
I suggest to change the time "reality" when node starts lagging. When node computing capacity is exhaused it should slow "real time" to lessen the load. Slowing by 10 times would mean that 20 au will be flown in 40 secs now. Also, missiles, drones and other stuff would fly 10 times slower - less data output per sec - less lag.
|
Chrisak
Minmatar
Shadow Knights of Thelema
|
Posted - 2007.06.27 13:45:00 -
[2]
Easier said than done.
But - The idea has merit if it can be accomplished on that kind of local scale.
Unfortunately, I think that this kind of change would have to apply to the entire node, so if there were a battle accumulating synch problems and slowing down "time" on one system of a node, the rest of the systems on the node would slow down as well, and you'd have scattered solar systems being complained about "lagging" when all they're doing is slowing down "time" on a system that was chosen as the battleground for a large fleet.
|
SleepingBuddah
|
Posted - 2007.06.27 13:54:00 -
[3]
 Originally by: Chrisak
Easier said than done.
But - The idea has merit if it can be accomplished on that kind of local scale.
Unfortunately, I think that this kind of change would have to apply to the entire node, so if there were a battle accumulating synch problems and slowing down "time" on one system of a node, the rest of the systems on the node would slow down as well, and you'd have scattered solar systems being complained about "lagging" when all they're doing is slowing down "time" on a system that was chosen as the battleground for a large fleet.
Yes, it is true, node affects many starsystems. But now it is not better. When huge battle goes on, you can 30 mins clicking warp button without any success with empty local.
I don't think that this suggestion is hard in implementing. Nodes are separated. At least node can be shut down temporarily for applying "time" change.
|
Ser Prius
|
Posted - 2007.06.27 13:55:00 -
[4]
The correct answer is for CCP to buy the hardware necessary to run their application. Right now the nodes are vastly underpowered for 700 ships in a system. They should invest in a rack of supercomputer level nodes for fleet battles, if a node gets over say 50-100 ships undocked they should swing it over to one of the supercomputer nodes. By supercomputer I mean something like this this.
|
Sc0rpion
Archer Daniels Midland
|
Posted - 2007.06.27 14:00:00 -
[5]
Originally by: Ser Prius
The correct answer is for CCP to buy the hardware necessary to run their application. Right now the nodes are vastly underpowered for 700 ships in a system. They should invest in a rack of supercomputer level nodes for fleet battles, if a node gets over say 50-100 ships undocked they should swing it over to one of the supercomputer nodes. By supercomputer I mean something like this this.
Nah, the hardware is fine. The problem is the outdated code. There's no reason why the server architecture needs to be limited to 1 star system per CPU. It's asinine.
The true secret to enjoying life is to live it dangerously.
-Friedrich Nietzsche
Killmails are for pooftas. |
Lady Trade
|
Posted - 2007.06.27 14:07:00 -
[6]
i suggest listening to the first live devblog. IIRC there was some talk about the scalability of CCPs server architecture. I think it was said then, that the main problem with lag is not actually a problem with the CPUs being overloaded but more the communication between the different nodes.
it was said that the interprocess communication is currently done with "normal" ethernet connections (ie. 100 to 1000 Mbit/s) and that this will be changed to a more modern system (i think they mentioned infiniband which would mean anything upward of 2Gbit/s scalable up to as much as about 100Gbit/s).
So maybe after that change we'll at least see some improvment with the session changes. If it were simply a question of getting stronger nodes then i think CCP would have done this a long time ago. |
Belial02
Amarr
The Collective
Against ALL Authorities
|
Posted - 2007.06.27 14:15:00 -
[7]
Remove POSes and capitals, there problem solved !
Originally by: Omeega
diplomacy is f1, f2, f3, really...
|
Dark Shikari
Caldari
Imperium Technologies
Firmus Ixion
|
Posted - 2007.06.27 14:16:00 -
[8]
One idea would be, to reduce database transactions, load everything from the database that matters for combat/etc into the memory of the node for everyone in the system. Delay all transactions back to the database server so that they can be done in bursts, to minimize the total number of transactions. Don't read from the database when possible, instead read from the memory.
23 Member
EVE Video makers: save EVE-files bandwidth! Use the H.264 AutoEncoder! |
rig0r
0utbreak
|
Posted - 2007.06.27 15:19:00 -
[9]
Originally by: Belial02
Remove POSes and capitals, there problem solved !
Agreed. Worst thing ever brought to EVE, in many ways.
EVE's server architecture needs a rewrite. That's probably not gonna happen though as it will cost CCP too much time and money. Instead they choose to fight lag in desperate ways like limiting drone numbers, introducing doomsdays, limiting evemail length and nerfing bios (wtf!). Though this is probably the most logical solution, it is not the best.
To keep my post constructive
- get yourself an Oracle RAC, run it on linux boxes to keep it relatively cheap. Nothing scales better. If you need an admin I'll happily fly over.
- rewrite your server processes in c(++), using multithreading where possible.
- enjoy lagless fleetbattles
/me dreams on
|
Korizan
Oort Cloud Industries
|
Posted - 2007.06.27 15:25:00 -
[10]
I thought I heard CCP stating the Revision 3 was the major rewrite and overhaul of the game engine.
|
Draygo Korvan
Merch Industrial
We Are Nice Guys
|
Posted - 2007.06.27 15:35:00 -
[11]
Originally by: SleepingBuddah
Edited by: SleepingBuddah on 27/06/2007 13:39:08
It seems that lag problem comes from fact that server works in real time. Even in lag if your warp speed is 5au/s you will fly 20 au in 4 secs
It cases server to choke from incoming and outgoing data.
I suggest to change the time "reality" when node starts lagging. When node computing capacity is exhaused it should slow "real time" to lessen the load. Slowing by 10 times would mean that 20 au will be flown in 40 secs now. Also, missiles, drones and other stuff would fly 10 times slower - less data output per sec - less lag.
As long as there is an indicator in the hud somewhere notifying players what speed the node is running at (think adjusting speed in an RTS scale of 1-10).
Also add a /sync command to update your client to where the server thinks you are (with reasonable limitations so it cant be used too often, and compound any lag problem). Perhaps an auto sync can be coded in if the server detects a sync problem with your client.
|
Lord WarATron
Amarr
Black Nova Corp
Band of Brothers
|
Posted - 2007.06.27 15:38:00 -
[12]
Edited by: Lord WarATron on 27/06/2007 15:36:57
Originally by: Korizan
I thought I heard CCP stating the Revision 3 was the major rewrite and overhaul of the game engine.
As far as I am aware, its just a graphical engine rewrite and not a full game network layer rewrite.
--
Billion Isk Mission |
jita90804
|
Posted - 2007.06.27 15:43:00 -
[13]
Migrating the database and infrastructure to Unix/Linux/Solaris would be a start.
Microsoft SQL just isn't up to the job. Even MS migrated to Sun/Solaris when Hotmail started to creak.
|
Tarminic
Black Flame Industries
|
Posted - 2007.06.27 15:52:00 -
[14]
Originally by: Ser Prius
The correct answer is for CCP to buy the hardware necessary to run their application. Right now the nodes are vastly underpowered for 700 ships in a system. They should invest in a rack of supercomputer level nodes for fleet battles, if a node gets over say 50-100 ships undocked they should swing it over to one of the supercomputer nodes. By supercomputer I mean something like this this.
It's really not a problem of hardware, it's a combination of problems regarding software/hardware/information interaction. Also, simply "swinging a system over" to a supercomputer is a vastly complex problem - if they could do it easily they would have already.
Originally by: Dark Shikari
One idea would be, to reduce database transactions, load everything from the database that matters for combat/etc into the memory of the node for everyone in the system. Delay all transactions back to the database server so that they can be done in bursts, to minimize the total number of transactions. Don't read from the database when possible, instead read from the memory.
That's actually a pretty damn good idea, DS. The question remain as to whether the servers can support the internal memory that would be required of them, and that given the amazingly fast access speeds of the RAMSAN drive, how much of a performance increase would this actually provide?
I could see these delayed database transactions as causing problems for anyone who isn't involved in combat, since they will be interacting much more with areas of the database outside that solar system/node - market, chat, excetera.
Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie
IBTL! IBDS! IBTC! 1st in a BoB Post! And other such forum tom-foolery. |
Sc0rpion
Archer Daniels Midland
|
Posted - 2007.06.27 16:00:00 -
[15]
Originally by: Tarminic
Originally by: Dark Shikari
One idea would be, to reduce database transactions, load everything from the database that matters for combat/etc into the memory of the node for everyone in the system. Delay all transactions back to the database server so that they can be done in bursts, to minimize the total number of transactions. Don't read from the database when possible, instead read from the memory.
That's actually a pretty damn good idea, DS. The question remain as to whether the servers can support the internal memory that would be required of them, and that given the amazingly fast access speeds of the RAMSAN drive, how much of a performance increase would this actually provide?
Wait, are we talking about server memory, or client memory?
The true secret to enjoying life is to live it dangerously.
-Friedrich Nietzsche
Killmails are for pooftas. |
Tarminic
Black Flame Industries
|
Posted - 2007.06.27 16:04:00 -
[16]
Originally by: Sc0rpion
Originally by: Tarminic
Originally by: Dark Shikari
One idea would be, to reduce database transactions, load everything from the database that matters for combat/etc into the memory of the node for everyone in the system. Delay all transactions back to the database server so that they can be done in bursts, to minimize the total number of transactions. Don't read from the database when possible, instead read from the memory.
That's actually a pretty damn good idea, DS. The question remain as to whether the servers can support the internal memory that would be required of them, and that given the amazingly fast access speeds of the RAMSAN drive, how much of a performance increase would this actually provide?
Wait, are we talking about server memory, or client memory?
It would have to be server memory - caching all of the required data on the client's computer would only cause more lag, and you would also have to worry about people manipulating that cached memory or running making sure it hasn't been tampered with.
Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie
IBTL! IBDS! IBTC! 1st in a BoB Post! And other such forum tom-foolery. |
Sc0rpion
Archer Daniels Midland
|
Posted - 2007.06.27 16:10:00 -
[17]
Originally by: Tarminic
It would have to be server memory - caching all of the required data on the client's computer would only cause more lag, and you would also have to worry about people manipulating that cached memory or running making sure it hasn't been tampered with.
That's exactly why I was asking.
The true secret to enjoying life is to live it dangerously.
-Friedrich Nietzsche
Killmails are for pooftas. |
Gnulpie
Minmatar
Miner Tech
|
Posted - 2007.06.27 16:13:00 -
[18]
Originally by: Dark Shikari
One idea would be, to reduce database transactions, load everything from the database that matters for combat/etc ...
That would only help partly. It would help more to reduce the overall amount of accesses. As it was stated somewhere earlier the load in group encounters scales up quadratically, means if you have 2 times more people you have 4 times more data to process, 10 times more people means 100 times more data. That is always bad. A different algorithm there would help a lot, escpecially if you find some n*log n algo here. That shouldn't be too difficult and if CCP can implement such stuff they will save thousands of $ in new hardware and large fleet combats will be MUCH faster.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |