open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: Fixing Lag: Well, this one doesn't really...
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 [3]

Author Topic

Meno Theaetetus
Wildly Inappropriate
Wildly Inappropriate.
Posted - 2010.09.11 05:32:00 - [61]
 

canTakeDamage = false;

if (clientHasReportedLoadingSystemProperly)
{
canTakeDamage=true;
}

Atomicity

Quote:
In database systems, atomicity (or atomicness) is one of the ACID transaction properties. In an atomic transaction, a series of database operations either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.

Tekei
Meatshield Bastards
The Bastards.
Posted - 2010.09.11 06:15:00 - [62]
 

Awesome dev blog!
I really enjoy any dev blogs touching the technical aspects of eve and I sincerely hope they'll continue to pop up. I would also love to see more blogs on game design choices and the issues involved.

Originally by: Meno Theaetetus
canTakeDamage = false;

if (clientHasReportedLoadingSystemProperly)
{
canTakeDamage=true;
}

Atomicity

Quote:
In database systems, atomicity (or atomicness) is one of the ACID transaction properties. In an atomic transaction, a series of database operations either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.



Now I am not a programmer but wouldn't it be possible to just remove that conditional statement from the code, making your ship permanently invulnerable in that case? If it's up to the client to report if it can take damage or not I mean.

Liang Nuren
Posted - 2010.09.11 08:09:00 - [63]
 

Hey Explorer - glad to see you guys are looking into FBs as causing lag. Several people in my corp were on the test server not so long ago and noticed a tremendous uptick in lag when a SC hit the field. I convinced Cooler to post a thread (http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1369758), but it sat there forever and we all forgot about it after a week or so.

Glad you guys are looking into it... and excellent job hunting down the bug. But really its probably better locking too much than not locking enough. Those race conditions suck.

-Liang

CCP Explorer

Posted - 2010.09.11 08:57:00 - [64]
 

Originally by: Tekei
Originally by: Meno Theaetetus
canTakeDamage = false;

if (clientHasReportedLoadingSystemProperly)
{
canTakeDamage=true;
}

Now I am not a programmer but wouldn't it be possible to just remove that conditional statement from the code, making your ship permanently invulnerable in that case? If it's up to the client to report if it can take damage or not I mean.
The state of the world must be server-authoritative to prevent hackers from having an unfair advantage.

Mioelnir
Minmatar
Cataclysm Enterprises
Ev0ke
Posted - 2010.09.11 10:55:00 - [65]
 

Hmm, fleet jump.

Ok, FC pressing jump and everyone within 2.5km of the gate jumping is bad. I think we all pretty much agree on this. Single players moving entire afk fleets around would not be a benefit to the game (not that much of a problem in nullsec though).

What could work however would be a "fleet movement announcement", based on the Fleet Commander's (fleet role) autopilot destination setting and manually triggerable by Scouts (fleet role), that would switch the gates 2 or 3 jumps ahead into an adaptive batch mode where the server would hand off pilots in packs of 10. The first jump request would sort of mark a transaction start, once 10 pilots are queued, they are batch-processed ('transaction end'). If the queue isn't filled after..5 seconds, it gets flushed and everyone in it so far handed off (to prevent 9 players from being stuck until the 10th guy shows up).

Additionally, these nodes ahead of the path could start preloading client session data structures, to allow them to absorb large amounts of clients faster.

Or check possible encounter systems in the autopilot paths of fleets with more than 100 people in it each. And send the node that is going to get hit a 'YOU ARE DOOMED!' heads-up (or hand off empty constellations running on that node to someone else).

Daneel Trevize
Gallente
Posted - 2010.09.11 13:45:00 - [66]
 

Perhaps an option to 'Jump on FC's command' for players. Then each client needs to push the button, but the FC triggers the batch and it's only those that want to be jumped. Hopefully still an opportunity for preping those clients who have hit this button, at the obvious trade off that they might not jump and it was wasted work.

Blazde
4S Corporation
Morsus Mihi
Posted - 2010.09.11 14:51:00 - [67]
 

We're talking tens or hundreds of people jumping all within a second of each other (when the jump itself is taking many seconds even on a good day). It should be possible to batch them up automagically without adding any extra special fleet commads.

It's not just FCs busing entire fleets around that's a problem, imo you also don't want to take the opportunity away from fleet members to leeroy through the gate early and cause subsequent dramas. Being able to click a button that says "I'll jump when my FC jumps me" feels too safe.

Deva Blackfire
Viziam
Posted - 2010.09.11 15:16:00 - [68]
 

Originally by: Liang Nuren
Hey Explorer - glad to see you guys are looking into FBs as causing lag. Several people in my corp were on the test server not so long ago and noticed a tremendous uptick in lag when a SC hit the field. I convinced Cooler to post a thread (http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1369758), but it sat there forever and we all forgot about it after a week or so.

Glad you guys are looking into it... and excellent job hunting down the bug. But really its probably better locking too much than not locking enough. Those race conditions suck.

-Liang


Prolly connected with missile physics stated earlier. Not only you need 20 drones per supercarier but each drone fires 20 missiles. 1 new player ship, 41 new objects for engine to pay attention to. With battleships you can have fleet of 100 vs 100 = 200 objects (+ say 5 drones each = +1000 ending with 1200). With supercariers... 30 supercariers (circa 1200 objects) will generate more-less as much strain as 200 battleships do. Ofc thats just straightforward count of objects, i have no clue how they DO interact with each other server side so not sure if those 30SCs will create EXACTLY same stress as 200BS, but i guess i wouldnt be far off.

Hm... nerf supercaps? :)

Saul Elsyn
INTERSTELLAR ENTERPRISE
Posted - 2010.09.11 18:01:00 - [69]
 

So... I think more grouping is in order in that case. Group drones into flights of up to five. Have the game treat em as a single object with 5 sets of armor, hull, and shield stats... and tell the client to animate them as five objects circling a common point (or however many there are in the flight).

As for revamping missiles... I suspect some new code will be required to make it so interceptors have a purpose somehow...

Tres Farmer
Gallente Federation Intelligence Service
Posted - 2010.09.12 04:49:00 - [70]
 

Cool blog with background info. Keep it up!

Hope this intel isn't used in the interim to lag out nodes even more.. or is that your intention to get moaaarrr data?! Twisted Evil
*puts on tinfoilhat*

Aineko Macx
Posted - 2010.09.12 08:22:00 - [71]
 

Edited by: Aineko Macx on 12/09/2010 08:36:26
Originally by: CCP Explorer
Originally by: Tekei
Originally by: Meno Theaetetus
canTakeDamage = false;

if (clientHasReportedLoadingSystemProperly)
{
canTakeDamage=true;
}

Now I am not a programmer but wouldn't it be possible to just remove that conditional statement from the code, making your ship permanently invulnerable in that case? If it's up to the client to report if it can take damage or not I mean.
The state of the world must be server-authoritative to prevent hackers from having an unfair advantage.

Naturally, but you do know if the grid instance request has been served or not.

Or you need to alter the sequence of the handover protocol states: Move the sending of grid data to the end of the sequence. Without it, even hackers cannot abuse it, so you can safely not force the player into the simulation. After setting up everything else, sending the grid data as last step is then possible without relying on client confirmation.

Louis deGuerre
Gallente
Malevolence.
Posted - 2010.09.12 09:42:00 - [72]
 

Yay.

CCP GingerDude

Posted - 2010.09.12 11:29:00 - [73]
 

Originally by: Aineko Macx
Edited by: Aineko Macx on 12/09/2010 08:36:26
Originally by: CCP Explorer
Originally by: Tekei
Originally by: Meno Theaetetus
canTakeDamage = false;

if (clientHasReportedLoadingSystemProperly)
{
canTakeDamage=true;
}

Now I am not a programmer but wouldn't it be possible to just remove that conditional statement from the code, making your ship permanently invulnerable in that case? If it's up to the client to report if it can take damage or not I mean.
The state of the world must be server-authoritative to prevent hackers from having an unfair advantage.

Naturally, but you do know if the grid instance request has been served or not.

Or you need to alter the sequence of the handover protocol states: Move the sending of grid data to the end of the sequence. Without it, even hackers cannot abuse it, so you can safely not force the player into the simulation. After setting up everything else, sending the grid data as last step is then possible without relying on client confirmation.


We know if the grid data has been served or not, true, but when you enter a solarsystem a lot of other service and data connections are made allowing a ebil h4xr to simply _not_ request the grid and still perform location based actions without ever being loaded into the grid for anyone else. So, no can do that. However, I do agree that the current mechanism is flawed and we are looking at ways to revamp it.

Harkey
Posted - 2010.09.12 11:48:00 - [74]
 

I'm curious why moveing nodes to dedicated servers seems to be such a painful (manual ?) process.

In my (admittedly limited) experiance of virtual servers, moving a vm between physical machines takes seconds, can be done on the fly and without loss of connection by clients.

Eniy Oh
Gallente
Wildly Inappropriate
Goonswarm Federation
Posted - 2010.09.12 15:05:00 - [75]
 

Originally by: Harkey
I'm curious why moveing nodes to dedicated servers seems to be such a painful (manual ?) process.

In my (admittedly limited) experiance of virtual servers, moving a vm between physical machines takes seconds, can be done on the fly and without loss of connection by clients.



^ this ^. Is virtualization applied on the server cluster at all? I realize the virtualization itself consumes server resources, but there are ways to limit this quite a bit. And it does make it easy to move live nodes.

Aineko Macx
Posted - 2010.09.12 17:14:00 - [76]
 

Edited by: Aineko Macx on 12/09/2010 17:16:21
Originally by: Eniy Oh
Originally by: Harkey
I'm curious why moveing nodes to dedicated servers seems to be such a painful (manual ?) process.

In my (admittedly limited) experiance of virtual servers, moving a vm between physical machines takes seconds, can be done on the fly and without loss of connection by clients.



^ this ^. Is virtualization applied on the server cluster at all? I realize the virtualization itself consumes server resources, but there are ways to limit this quite a bit. And it does make it easy to move live nodes.

Virtualizing the whole OS would not be very appropriate, because you want to move the load generated by a single solar system, not all of them. They'll end up doing handovers of player connections, with a sequence similar to this:
- Slave the simulation of the new server to the current one, so they are in sync.
- Pause simulation
- Handover the player connections to new server (a process affecting mainly the proxy blades)
- Unpause simulation

This isn't transparent to the players (nor would it be to the application if it was run in a VM), but the nearest thing in reach of CCP.

Zagdul
Gallente
Clan Shadow Wolf
Fatal Ascension
Posted - 2010.09.12 18:33:00 - [77]
 

Edited by: Zagdul on 12/09/2010 18:41:16
Edited by: Zagdul on 12/09/2010 18:37:41
Would it be possible to attempt a mass test with the Damage Control as a passive module?

500 people with an active module that does a check for a % of resists seems like it would take up some server resources.

For the people who complain about this being a passive module... it doesn't need to be an active one, don't get into this debate...


Also, last fleet fight I was in, 25 or so stealth bombers came in with bombs. Broadcasts were spammed by half the fleet.

When these two things happened:

A. My client stopped responding.

B. As soon as I saw the bombs, I attempted warping to my align point.

C. My ship didn't blow up where I actually had to re-log. Upon re-entering the system, I was in my pod but couldn't control it... I re-logged again and found myself in a station needing a new clone and new ship.I wasn't the only person in the fleet with this issue.



"Brackets off"
"All settings on low with effects/etc. turned off"
Bombs away....
"Ships blowing up near me"

I lost control of my ship and could not warp.


Same was said for a lot of people in this fight. I didn't bother petitioning this because the server was fine. It was reinforced. It was a very specific circumstance where I lost control of the client and could not warp because of the multiple bombs, ships blowing up and spamming of broadcasts.


So...

1. Test if the Damage Control Unit is causing server load. If so, how much and would it be beneficial to lag to make this a passive module?

2. Bombers on a fleet and their effect while broadcasts are happening.


The sad thing... I shouldn't have lost my ship. The enemy used different bomb types but due to the lag, I lost my ship and proper calculations weren't made for the amount of damage done / vs. amount of health I had vs. which bombs should have blown each other up.


Marconus Orion
D00M.
Northern Coalition.
Posted - 2010.09.13 09:27:00 - [78]
 

I have said countless times that the damage control should be a passive module. There was even an Assembly Hall thread about it and Drone Control Units. The Damage Control is the one module that every single PvP ship fits and has to turn on after every single jump.

Making it passive would be one less thing that the servers would have to answer for when hundreds of players rage press that module on a jump in. Yes it only uses one cap every thirty seconds but having to turn on that module is flat out annoying. The Drone Control Unit is the only module that uses ZERO cap yet you have to turn it on. One of the reasons carriers don't use them is because when lag gets bad, they won't cycle and your fighters get disconnected and lost.

Please CCP, make the Damage Control and Drone Control Unit passive already. You can't tell me that players not having to activate one module that is on every ship would not help lag a bit. Not to mention all the players gratitude for the change.

P L E A S E ! ! !

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2010.09.13 11:00:00 - [79]
 

Quote:
Please CCP, make the Damage Control and Drone Control Unit passive already. You can't tell me that players not having to activate one module that is on every ship would not help lag a bit. Not to mention all the players gratitude for the change.


I have posted an Assembly Hall thread asking players for feedback on this potential change.

Meatypopsicle
Posted - 2010.09.14 18:20:00 - [80]
 

Originally by: Meno Theaetetus


Quote:
In database systems, atomicity (or atomicness) is one of the ACID transaction properties. In an atomic transaction, a series of database operations either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.



Atomicity is great when you only have one process accessing the database at a time but with concurrent systems the more stuff you include inside a single transaction the more problems you have with blocking other processes and the more often you have to do non optimal processing to avoid deadlocks.

Ice Brodie
Minmatar
Vertigo Sun
Mordus Angels
Posted - 2010.09.15 00:22:00 - [81]
 

I have lost a ship to this particular issue, and was not given compensation due to 'no server logs' by the GMs... should I re-file my claim due to this issue or am I pernamently out a good combat ship?

Vossejongk
Caldari
Caldari Provisions
Posted - 2010.09.19 20:46:00 - [82]
 

"PPS. We believe we've uncovered a rather rare (statistically speaking) seperate old issue of not loading the grid. I realize that it's pretty darn impossible for a player to distinguish between being blocked on a lock and that issue, but in the latter case it's actually a client issue. We are working on that."


Thanks to me, now where's my present?

Zagdul
Gallente
Clan Shadow Wolf
Fatal Ascension
Posted - 2010.09.20 15:21:00 - [83]
 

Oh...

Insurance payouts happen when you dock instead of when you blow up.

mail sent + isk + ship blowing up... more data.

I'm sure this won't "fix" anything, but I'd bet this would help :)




Sean Arek
Minmatar
Rionnag Alba
Northern Coalition.
Posted - 2010.09.30 17:37:00 - [84]
 

Originally by: CCP GingerDude
Originally by: Voight Kampf
Nice blog. It still doesn't cover one question. Why we didn't have this lag BEFORE Dominion? If i understood your blog right this issue is independent from sov system etc and still we didn't encounter it in Apocrypha. How you can explain this?
I'm fairly sure that this issue was present before Dominion; you just needed bigger fleets to trigger it before. I can't really explain why the server pain-threshold dropped around Dominion conclusively, since all our metrics suggested that we should've been able to handle even more pilots then before. My pet theory regarding that today is actually the change in playstyles and fitting that we saw after dominion. Some weapons are much more CPU intensive than others and Dominion basically ushered in an era of much increased use of missiles, fighter bombers and smartbombs in fleet fights. These are known to be cpu heavy compared to many other weapons and modules, so a significant increase in the % of ff players using them could very well have moved the tipping point.




Before Dominion I participated in very large BS fleets in Triumnverate Mark Somethingorother and we faced large BS fleets from the likes of MM etc.

After Dominion we continued to run these very same fleets, with the same ship types and found the lag unbearable.

Has CCP actually ever tried installing old code on a test server and benchmarking it against new code?




Joia Crenca
Posted - 2010.10.01 20:03:00 - [85]
 

Just a 'lag related' question. Would in-station graphics as they currently are contribute only to client-side lag? I remember when they had the Gallente "Quafe" or "Pleasure Station" in station graphic. I thought it was the most attractive one, but was removed, presumably for lag? I'd actually like to see it and a Caldari themed one in some stations for variety.


Pages: 1 2 [3]

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only