These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
 

Would a more powerful server fix tidi?
Author
Previous Topic Next Topic
Robert Caldera
Caldera Trading and Investment
#21 - 2013-12-26 13:13:28 UTC  |  Edited by: Robert Caldera
James Amril-Kesh wrote:
Logan Revelore wrote:
It could also be a bandwidth limitation.

No. The amount of bandwidth used by EVE is really, really small.


yes, for you maybe, for the server side its multiplied by the total number of interacting nerds.

In a simplified model lets assume one particular grid would result in network traffic volume of 1 bytes per player and there would be 1 guy on grid -> ensueing server load of 1 bytes per tick for 1 player.
As soon as another player enters the grid would mean 2 bytes of grid data communicating to 2 these players = 4 bytes total load.
With 3rd player on scenery, its 3x3=9 bytes to be communicated over all participants.
4 player = 16 bytes, 5 players = 25 bytes. you see the network requirement grows quadratically with the number of players in a room sharing same universe.
There is surely some optimization implemented to flatten the load curve a bit but you got the basic idea why growing number of players will always tend to push the limits very quckly.
Lors Dornick
Kallisti Industries
#22 - 2013-12-26 13:14:18 UTC  |  Edited by: Lors Dornick
Amhra Rho wrote:
A big part of the genius of the game is that its back-end is run on a single monster server. No other gamer really does it this way, and while it's ingenious in many ways, that single server is also Eve's biggest constraint.

Well no.

TQ is a cluster of several servers with several blades with load and functions shared over the cluster.

The issue is that a the in space calculations for a single system can't be split over multiple servers.

CCP Greyscale: As to starbases, we agree it's pretty terrible, but we don't want to delay the entire release just for this one factor.
Sarah McKnobbo
Sebiestor Tribe
Minmatar Republic
#23 - 2013-12-26 13:23:12 UTC  |  Edited by: Sarah McKnobbo
There was a post by a dev after the last node crash during a big sov battle, where they said the last 3 crashes were down to coding/program errors, not actual server overload. I can't find it at the minute, forum searching is horrid on a smartphone with a cracked screen!

Found it
Amhra Rho
Accujac Elimination
#24 - 2013-12-26 13:28:51 UTC
Robert Caldera wrote:
you guys are just looking at CPU load which grows linear but ignore network load completely, which however increases quadratically with the number of clients on grid. Assuming server architecture scales perfectly (it doesnt) and you can stuff more and more CPUs into the cluster, you cant extend your network bone infinitely, things have physical limits.

Not necessarily the case. You'll find I've provided links that speak to not only the CPU, but the RAM base - as well as how Intel will soon address DDR4 server RAM in the next fiscal quarter - the aggregate bandwidth, load balancing (that's been more than optimized), WAN links (also optimal), multi-threading (largely constrained by the code, as mentioned above), use of fiber infrastructure, advanced leveraged VLAN bandwidth switching, real time system monitoring and response, judicious use of virtualization, strategies for managing huge numbers of multiple connections that's been borrowed from recent advanced cloud computing technology, and SSD drive implementation.

I just can't see where you can take a conservative stance with the intention of ensuring stability, predictability and reliability, while at the same time performing a wholesale systems upgrade to something that would function markedly better at this point. In other words, I really think they've thought of everything for now.

There's real reasons why your Eve character doesn't do /dance.
Kagura Nikon
Native Freshfood
Minmatar Republic
#25 - 2013-12-26 13:33:54 UTC
Amarr Citizen 1312151005 wrote:
Just wondering would a more powerful server fix tidi? Or is it more of a coding issue? Just wondering this because I got bored and started looking up super computer's. The two fastest in the world run at about 20 and 40 petaflops.

And I thought I had read somewhere that tranquility runs at like 300-400 teraflops. Could one of these super computers handle large eve battles without tidi? This is of course hypothetical.

But just curious if it would ever be possible to see the end of tidi. I am thinking hardware wise the tech is out there while not realistic for a small company like ccp to obtain and maintain.

I would think if one if those super computers where designed with the purpose of running eve they could more than handle the processing needs. And in time I think we could see an end to tidi.

However if tidi is related to some deeply coded issue I think we may never see its end..

TL:DR. Could tidi be fixed with pure power or is it a coding issue that may never be fixed?



Do not try to find solutions whn that is not your expertise area. Super computers are massively parallel systems. That measurement is throughput not local speed on a defined thread, therefore irrelevant for the issue.

"If brute force does not solve your problem....  then you are  surely not using enough!"
Amhra Rho
Accujac Elimination
#26 - 2013-12-26 13:35:41 UTC
Lors Dornick wrote:
Amhra Rho wrote:
A big part of the genius of the game is that its back-end is run on a single monster server. No other gamer really does it this way, and while it's ingenious in many ways, that single server is also Eve's biggest constraint.

Well no.

TQ is a cluster of several servers with several blades with load and functions shared over the cluster.

The issue is that a the in space calculations for a single system can't be split over multiple servers.

By definition, a clusteris a single virtual server. Clustering indeed leverages multiple identical physical "boxes" for the purposes of either load balancing or failover, or both, but the cluster will always "read" as a singular server.

There's real reasons why your Eve character doesn't do /dance.
Kagura Nikon
Native Freshfood
Minmatar Republic
#27 - 2013-12-26 13:36:19 UTC
Amarr Citizen 1312151005 wrote:
Ibrahim Vaughn Holtzman wrote:
Supercomputers only work great if they can compute massively parallel.

Eve's backend, however, is mostly single-threaded and scales terribly with number of cores and/or threads. It is basically from a time when Intel kept insisting that 10GHz-CPU's are right around the corner. Which didn't happen due to exponential thermal output.

So a coding issue in other words? Same reason my I7 is worthless for eve client side.



Nope, its a fundamental problem of what is being tryied to acomplish. If you tried to make eve massively paralel on each noce you would face a lot of OTHER issue.

If this was somethign easy to solve by a random internet guy, software engineers would not have such high pay grades.

"If brute force does not solve your problem....  then you are  surely not using enough!"
Kagura Nikon
Native Freshfood
Minmatar Republic
#28 - 2013-12-26 13:37:33 UTC
Amhra Rho wrote:
Lors Dornick wrote:
Amhra Rho wrote:
A big part of the genius of the game is that its back-end is run on a single monster server. No other gamer really does it this way, and while it's ingenious in many ways, that single server is also Eve's biggest constraint.

Well no.

TQ is a cluster of several servers with several blades with load and functions shared over the cluster.

The issue is that a the in space calculations for a single system can't be split over multiple servers.

By definition, a clusteris a single virtual server. Clustering indeed leverages multiple identical physical "boxes" for the purposes of either load balancing or failover, or both, but the cluster will always "read" as a singular server.



Externally yes, but internal to the proccess beign executed not necessarily. YOu can code it manually to distribute the load or use APIs like MPI to offload foryou between nodes, but its never completely transparent for the software.

"If brute force does not solve your problem....  then you are  surely not using enough!"
Themanfromdalmontee
EVE RADIO ARMY
#29 - 2013-12-26 13:46:50 UTC
Not sure why people complain about a bit of tidi, its fun :)
Amhra Rho
Accujac Elimination
#30 - 2013-12-26 13:48:47 UTC
Kagura Nikon wrote:
Amhra Rho wrote:
Lors Dornick wrote:
Amhra Rho wrote:
A big part of the genius of the game is that its back-end is run on a single monster server. No other gamer really does it this way, and while it's ingenious in many ways, that single server is also Eve's biggest constraint.

Well no.

TQ is a cluster of several servers with several blades with load and functions shared over the cluster.

The issue is that a the in space calculations for a single system can't be split over multiple servers.

By definition, a clusteris a single virtual server. Clustering indeed leverages multiple identical physical "boxes" for the purposes of either load balancing or failover, or both, but the cluster will always "read" as a singular server.



Externally yes, but internal to the proccess beign executed not necessarily. YOu can code it manually to distribute the load or use APIs like MPI to offload foryou between nodes, but its never completely transparent for the software.

I'm running the risk that we might be saying the exact same thing, but just to be clear, yes, what you describe is cluster-level load balancing. It works like this - you have, say, nine physical boxes in the cluster. It shows up on your management screens as a single computer with, say, a singular (virtual) drive C:. You can indeed leverage that cluster-level load balancing feature as follows: give a little bit of the processing to box number 3 until it starts to be taxed, then switch the processing to a languishing box number 8 for a while, etc. In other words, you can't view all the multiple cores which are in turn each hyperthreaded as a single CPU - you literally have to parcel out tasks to one physical CPU in the cluster, followed by the next, etc.

Again, it's possible we are saying the same thing.

There's real reasons why your Eve character doesn't do /dance.
Jandice Ymladris
Aurora Arcology
#31 - 2013-12-26 14:17:25 UTC
To keep it a bit out the deep hardware discussion.

Fixing TiDi cannot be done by improving coding & hardware. It can only be done by rebalancing 'blob' warfare. How so you ask?

Look at why TiDi was implemented first: it was created so large fleets could still fight without crashing or seeing a black screen. Once TiDi got generally accepted, fleets in turn grew larger, creating heavier TiDi loads till servers crash once more.

Now if yo'ud 'fix' TiDi, what will happen? Fleets will grow exponentionally till they reach the hardware/coding limits again, bringing back TiDi and subsequent crashes. So in short, no amount of hardware coding can fix it, ti can only move up the problem of overloading servers. In this regard, TiDi does an excellent job.

In short: want to fix TiDi? Find a way to put a gameplay limit on huge fleets (not a hardcap, but a gameplay reason that turns huge fleets into a bad idea) What this would be, I don't know, I don't fly caps.
Do keep in mind, you can't erase big fleet fights from EVE, as they are excellent promotional material for the outside world.

Providing a new home for refugees in the Aurora Arcology
Cazador 64
Deep Core Mining Inc.
Caldari State
#32 - 2013-12-26 16:36:10 UTC
Jandice Ymladris wrote:


Find a way to put a gameplay limit on huge fleets (not a hardcap, but a gameplay reason that turns huge fleets into a bad idea)
.

I could see this working . I wouldn't want to see it get any smaller than they are but; if they fixed tidi and made it counterintuitive to field more caps I could see this working out.

PotatoOverdose
Handsome Millionaire Playboys
Sedition.
#33 - 2013-12-26 16:48:11 UTC
When the node can support 5k people in a single system, the blocs will bring 7k and the nodes will lag/crash/burn again, as they always do.

Those huge fights are great for publicity but offer **** for gameplay (IMO). Unless, y'know, you like fights where modules cycle once every fifteen minutes.
Qmamoto Kansuke
Killing with pink power
Penguins with lasorz
#34 - 2013-12-26 17:04:10 UTC
My own opinion: since the issue is in the code the solution would be to hire more people to fix said code.Dedicated team that would adress only how to make the largest battle a pleasant experience.
Nariya Kentaya
Ministry of War
Amarr Empire
#35 - 2013-12-26 17:08:18 UTC
Amarr Citizen 1312151005 wrote:
Xercodo wrote:
Nope, CCP's pretty much already using the most advanced stuff they can afford. It's really a coding problem that will simply take time to work out.

They gave TiDi as a band aid to the problem until such a time as they have the ultimate solution.

I know they are using the most advanced stuff they can afford but could of of the top 2 super computers run it?

its not just "the most they can afford"

its borderline the best anyone can GET

as in, if they want to upgrade the hardware, it has to be invented, or at least made for practical applcation (alot fo labs have more powerful servers, but they are purely for testing purposes and impractical to ever produce mroe than 1 as theya re unprofitable)

besides that, upgrading electronics gives DIMINISHING returns, sure they could slap more hardware, but that still leaves us with the upper limit we have now (like Jita), the only SUREFIRE way to get noticeable increases in server performance is to redo the SOFTWARE, which is SIGNIFICANTLY harder and more time consuming, and they have been trying to to it for years piece by piece
Freyya
Aliastra
Gallente Federation
#36 - 2013-12-26 17:09:40 UTC
Robert Caldera wrote:
you guys are just looking at CPU load which grows linear but ignore network load completely, which however increases quadratically with the number of clients on grid. Assuming server architecture scales perfectly (it doesnt) and you can stuff more and more CPUs into the cluster, you cant extend your network bone infinitely, things have physical limits.


CCP runs infiniband connections between their blades and loadbalancers etc. afaik. I assume this makes network load not that big of an issue for the tranquility cluster
Icarus Able
Refuse.Resist
#37 - 2013-12-26 17:10:50 UTC
Nothing will ever fix tidi until a server can handle all 500,000 accounts in on esystem. Each time they upgrade the servers people just bring more to the fight.
Carmen Electra
AlcoDOTTE
Test Alliance Please Ignore
#38 - 2013-12-26 17:11:34 UTC  |  Edited by: Carmen Electra
As a software developer, I find it pretty easy to spot the people who are using words like "code" but don't really know the first thing about software engineering.

First, read this:

http://www.joelonsoftware.com/articles/fog0000000069.html

Second, people keep suggesting that EVE's code is in need of some sort of "optimization". Optimization isn't really a thing, and hasn't been a thing for many years. There used to be a time when programmers would comb through code, implementing things like loop optimizations, but that was 30 years ago.

One the things that gets beaten into computer science students nowadays is that the first rule of optimization is not to do it. Hand-optimizing code has a greater chance of breaking the code than making it faster. Modern compilers optimize code to a far greater degree than even the most expert software developer could hope to do.

Sure, there ARE always things that can be done to improve performance, but by the time software is 10 years old, it's probably running as fast as it's ever going to run. The problem with TiDi is that computers can only crunch numbers so fast, and when you get 4,000 people on a single node, then you start running into the physical limitations of modern computers. Sure, faster hardware may exist, but it probably isn't cost-effective for CCP.

TL;DR. Stop complaining about TiDi. TiDi is the price we pay for being able to have thousands of people in the same system.

Bacon makes us stronger
Dinsdale Pirannha
Pirannha Corp
#39 - 2013-12-26 17:47:15 UTC
Cazador 64 wrote:
Jandice Ymladris wrote:


Find a way to put a gameplay limit on huge fleets (not a hardcap, but a gameplay reason that turns huge fleets into a bad idea)
.

I could see this working . I wouldn't want to see it get any smaller than they are but; if they fixed tidi and made it counterintuitive to field more caps I could see this working out.



I have suggested a social engineering solution before.
In short, introduce a risk of ships not jumping, jumping to the wrong system, or being completely destroyed when using jump drives or Titan jumps. The risk increases as the quantity of ships and total mass being jumped increases.

Blob-sec players hate the idea in principle since they are totally risk-adverse, but the general principle of the concept would deter this ridiculous issue. BTW, this issue only affects a tiny portion of the player sub base, so CCP should apply only a tiny amount of resources to it. They have much larger issues that affect the majority of its player base to sort out first.
James Amril-Kesh
Viziam
Amarr Empire
#40 - 2013-12-26 18:18:20 UTC
Robert Caldera wrote:
James Amril-Kesh wrote:
Logan Revelore wrote:
It could also be a bandwidth limitation.

No. The amount of bandwidth used by EVE is really, really small.


yes, for you maybe, for the server side its multiplied by the total number of interacting nerds.

In a simplified model lets assume one particular grid would result in network traffic volume of 1 bytes per player and there would be 1 guy on grid -> ensueing server load of 1 bytes per tick for 1 player.
As soon as another player enters the grid would mean 2 bytes of grid data communicating to 2 these players = 4 bytes total load.
With 3rd player on scenery, its 3x3=9 bytes to be communicated over all participants.
4 player = 16 bytes, 5 players = 25 bytes. you see the network requirement grows quadratically with the number of players in a room sharing same universe.
There is surely some optimization implemented to flatten the load curve a bit but you got the basic idea why growing number of players will always tend to push the limits very quckly.

This was a good and informative post.

Enjoying the rain today? ;)