|
|
| Author |
Thread Statistics | Show CCP posts - 23 post(s) |
|
CCP Zymurgist
C C P
C C P Alliance
87
   |
Posted - 2011.09.09 17:50:00 -
[1] - Quote
Team Gridlock talks about this in their dev blog about Time Dilation that if you haven't read this already I highly suggest giving it a glance.
Zymurgist
Community Representative
CCP NA, EVE Online
Contact Us at http://support.eveonline.com/pages/petitions/createpetition.aspx |
|
|
CCP Veritas
C C P
C C P Alliance
49
|
Posted - 2011.09.09 18:43:00 -
[2] - Quote
Malcanis wrote:Which kind of lag do you prefer?
(1) Unevenly applied, unpredictable, causes weird effects like ships remaining in space, benefits some types of ships disproportionately
(2) Evenly applied, predictable, everything works as normal, just somewhat slower overall
Quoting this post as it's a good summary of what we're hoping to achieve with Time Dilation. #1 is what we have currently when the server becomes overloaded, #2 is what we'd greatly prefer happen.
As for this signifying us becoming lazy about server optimization, that's a fair concern, as it'll certainly make the pain of being overloaded less acute. At the same time, it's not cool to leave a painful thing alone just because it reminds us that performance is important. I have a baseball bat for reminding people of that.
Fate willing, we'll be doing public tests of Time Dilation in the coming weeks' mass tests, so you can get a first-hand impression of it there~ |
|
|
CCP Veritas
C C P
C C P Alliance
49
|
Posted - 2011.09.09 20:20:00 -
[3] - Quote
To say what Tippia said in different words...
Most of the things we talk about when we talk about "fixing fleet lag" have to do with increasing the capacity of these fights, that is, the number of players it takes to make the server start exhibiting "lag". Team Gridlock has been at that for over a year now, and have delivered very good results.
Time Dilation does not increase capacity at all. These days we handle about 1000 players (more or less depending on the type of activity being done) before lag starts kicking in. The day after we ship Time Dilation, it'll be exactly the same. The difference is what happens *after* that threshold is passed. Instead of the effects we all know and hate, it'll simply slow the game down until able to cope with the load.
After we ship, we plan to go back to work increasing capacity. These things are not mutually-exclusive. Rather, they're quite complementary. |
|
|
CCP Veritas
C C P
C C P Alliance
49
|
Posted - 2011.09.09 21:00:00 -
[4] - Quote
Vincent Athena wrote:[quote=CCP Veritas]How will you get a big blob of lag on Sisi? Ive been in the last few mass tests and there has been some lag, but not that much.
The sane plan is to add in thin clients. The insane plan is to allow time to go past 1x speed.
I haven't decided which is better. |
|
|
CCP Veritas
C C P
C C P Alliance
49
|
Posted - 2011.09.10 10:25:00 -
[5] - Quote
Happy to have your endorsement, inexistin ;) |
|
|
CCP Habakuk
C C P
C C P Alliance
6
|
Posted - 2011.09.10 13:58:00 -
[6] - Quote
Ashalin Tora wrote:I won't lie, this is pretty awesome.
Would the time dilation be effective only in the grid where the big fight takes place or is it system wide? And if not the latter, how would this look to an distant observer, perhaps monitoring the situation with probes and by scanning?
The whole system will be dilated, including warping or scanning itself. |
|
|
CCP Habakuk
C C P
C C P Alliance
6
|
Posted - 2011.09.10 14:32:00 -
[7] - Quote
Abrazzar wrote:
Will the station environment be dilated, too? And the connected WiS?
The station environment will be not dilated and there will be also a few parts of the in-space environment which will not be dilated like reinforcement timers. Planetary interaction for example will also not be dilated.
|
|
|
CCP Veritas
C C P
C C P Alliance
49
|
Posted - 2011.09.10 14:37:00 -
[8] - Quote
Abrazzar wrote:Will the station environment be dilated, too? And the connected WiS?
Walking of any variety won't be dilated in the first deployment. It may stay that way, it may not, I don't know at this point.
There may be elements of the station environment that we dilate in order to convey to the player what's going on back in space. |
|
|
CCP Veritas
C C P
C C P Alliance
56
|
Posted - 2011.09.10 16:01:00 -
[9] - Quote
J0HN RAMB0 wrote:Will time dilation affect aggression timers and log-off-despawn timers?
Yes. |
|
|
CCP Veritas
C C P
C C P Alliance
56
|
Posted - 2011.09.10 17:16:00 -
[10] - Quote
Digital Messiah wrote:Q: Will Carbon IO work along with time dilation?
Carbon IO is a system that allows for lightweight communication between the cluster and the clients. In other words, it's a new mechanism by which our computers talk to your computer. It has nothing conflicting with Time Dilation.
Digital Messiah wrote:Q: What results can we expect from Carbon IO to improve cluster performance alone?
It has very little benefit to cluster capacity by itself. It enables us, the programmers in Eve, to use a new communications method in new code, which we're planning to do but nothing has happened yet.
Digital Messiah wrote:Q: How long will TIDI run in a system, If enabled? "until the cluster is free of lag, or is lessened in lag."
TiDi will kick in when a node has become overloaded and will stop when that node is no longer overloaded. Do note that only that node is effected, not the whole cluster.
Digital Messiah wrote:Q: As Carbon IO allows C++ code. When can we expect to see C++ integrated?
We already have some C++ systems. Carbon IO allows C++ code on the server to communicate directly to C++ code on the client via BlueNet, which is a new capability that makes it easier for us to move performance-critical systems over to C++, which was already on our roadmap to do. That it's easier and more effective for us to do now means it's higher on our priority list than it was before.
Digital Messiah wrote:Q: What is your perfect Sunday?
Common decency forbids me from answering this. |
|
|
|
|
CCP Veritas
C C P
C C P Alliance
56
|
Posted - 2011.09.10 18:59:00 -
[11] - Quote
Yes, if a large scale fight breaks out on a non-reinforced node, other systems hosted on the same node will slow down as well. While this isn't ideal, it's still considerably better than what happens today. |
|
|
CCP Veritas
C C P
C C P Alliance
56
|
Posted - 2011.09.11 10:07:00 -
[12] - Quote
Leon Razor wrote:So to the devs reading this thread: how (or even just will) EVE time dilation and DUST not break the live game to game interaction?
I can't go into the details, but I have been in contact with the dudes working on the EVE/DUST interaction and we have solutions. |
|
|
CCP Veritas
C C P
C C P Alliance
59
|
Posted - 2011.09.11 12:00:00 -
[13] - Quote
Salpun wrote:Salpun wrote:CCP Veritas wrote:Yes, if a large scale fight breaks out on a non-reinforced node, other systems hosted on the same node will slow down as well. While this isn't ideal, it's still considerably better than what happens today. Have you decided yet if you will be showing which systems are using TiDi on the map like other states of the game or will FC's have to send scouts out to see what the state of other systems are? Hay Veritas you skipped a question   
Sorry 'bout that. I hadn't considered putting it on the map like that, but with a few hours for it to rattle around my brain, I'm not a fan. Primarily because it should be a rather rare event and 3-way fights (such that 1 group wouldn't already know the dilation state) are very rare.
I'm quite willing to be wrong. |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 11:31:00 -
[14] - Quote
I think the key thing you're missing Ms. Vanszar is that fights are already taking long than they would under ideal server situations. Modules already take longer to cycle than they should under heavy load, in addition to any problems with black screening and the like preventing pilots from participating. It's already possible for a force to slow down a fight in order to call in more reinforcements.
That said, I keep a fairly tight eye on what the load in fleet fights is. If I see something pop up that's obviously trying to deny the field, I'll have some work to do to correct that.
It's likely that guns in particular will be a bit slower after TiDi than before, as manual cycling won't give any advantage like it does now - they'll be effected by server overloading exactly the same as any other module now instead of having preferential treatment. Ultimately that's what this is all about - preserving the game mechanics even if the server becomes overloaded.
Maybe keeping game mechanics intact will cause fights to take longer. Maybe they'll be faster instead. There's good arguments either way and I'm quite excited to see which way it goes once the feature is active.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 11:33:00 -
[15] - Quote
Fawcks wrote:Instead of making it so that no one has lag, now everyone is going to have it?
I'm confused. :(
Yessir, you very much are confused
We're taking a break from increasing capacity to make going over capacity considerably less painful, as it's functionally impossible for us to guarantee never going over capacity.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 12:40:00 -
[16] - Quote
Miilla wrote:Great, so CCP's solution to the lag problem that a few people get is to, LAG EVERYBODY.
I have no idea where you're getting this idea.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 14:16:00 -
[17] - Quote
Miilla wrote:So why did you remove my post asking about why the patch was over 100mb and what happened to the Incarna performance patch that was removed?
It had absolutely nothing to do with this thread?
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 14:21:00 -
[18] - Quote
Grey Stormshadow wrote:Stuff about a delay on jump-in
This is commonly brought up, but inducing a delay on jump in so the "times line up" is not something we're doing. It does make reinforcing mid-fight more powerful than it would be if the fight were lagless, but compared to today's situation it's no worse.
If we were to do such a delay, it'd create a minor nightmare in the details. Are ships stuck in the delay for the duration? Are they in some kind of "limbo" invulnerable state the entire time? What if their eventual jump in time would be after downtime? It gets pretty bonkers.
I totally understand that it feels weird to have differences in time advancement not accounted for in some way, but the oddness of that is less odd than actually accounting for it.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 14:35:00 -
[19] - Quote
Miilla wrote:Can time dilation be abused? What if large fleets jump in and out or log on and off, what if the large fleet does lots of actions?
Is the dilation localised to the grid? or System wide?
It can be abused in the same way that the current degradation scheme can be abused, sure.
Dilation, at least in the first implementation, is a node-level construct. Any solar systems being run by the overloaded node will be dilated. This, while not ideal, is no worse than today - when a node becomes overloaded, all systems running on it suffer.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 15:05:00 -
[20] - Quote
Salpun wrote:So is the TiDi test on Sisi this week we or do we get more CQ/ Carbon OI/ team BFF stuff first
There is no mass test this week. Next week's a maybe for TiDi.
CCP Veritas - Senior Programmer - EVE Software |
|
|
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 15:20:00 -
[21] - Quote
Miilla wrote:And what happened to this "dynamic node balancing" scheme that was to be added?
What, specifically, are you referring to? I can think of a few things that might fit that description depending on interpretation.
Miilla wrote:What is the density of systems per blade?
Anywhere from 1 to about 500 systems per node, depending on a great many things. Your garden variety non-reinforced 0.0 node runs around 50-75 systems these days. There are presently 4 nodes per blade, though thinking per-blade is not very useful currently as each node is quite independent and the blades are apportioned to be able to run all 4 nodes at very near full capacity simultaneously.
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 15:35:00 -
[22] - Quote
Miilla wrote:Well it was a while back that dynamic node balancing was the ability to "hot" shift systems across nodes.
We call that "non-disruptive live remapping." It's something we absolutely want, but is still a ways away. There is an effort currently to bring disruptive live remapping - the ability to move a system between nodes after disconnecting everyone - up to par. Once that's done, we'll be prioritizing the work of making it non-disruptive against everything else we could be up to.
Time Dilation does help with that effort though - it provides a mechanism which we can use to pause the simulation of a system while it's moved, so we have some progress on that front without even trying 
CCP Veritas - Senior Programmer - EVE Software |
|
|
CCP Veritas
C C P
C C P Alliance
104
|
Posted - 2011.09.13 16:38:00 -
[23] - Quote
Crasniya wrote:Are "nodes" VMs running on the blades? Is there a software limitation which prevents you from moving VMs off a blade and giving that one node more of the blade's power, allowing it to handle a single overloaded node better?
They are not VMs - they're separate invocations of the server process. We are investigating ways in which we can use modern virtualization to solve the non-disruptive remap problem, but they're just investigations at this point as the problem is not trivial.
Crasniya wrote:Could one 'disruptively' move systems off an overloaded node that are currently devoid of players, so the interruption isn't noticed by anyone in-game? Without players in them, would moving about empty systems even help?
That's something we do occasionally and likely will do more once destructive remapping is a more reliable thing. Moving off empty systems doesn't really help anything at that moment, but when someone subsequently jumps into that previously-empty system, I'm sure they're happier having it been moved 
CCP Veritas - Senior Programmer - EVE Software |
|
|
|
| |
|