[2019] No Downtime Feedback Thread

Refer to this dev blog for information.

Please provide your feedback about the ongoing effects of our No Downtime experiment in this thread. We are interested to find out what unusual behaviors you might encounter taking place on Tranquility as we explore the consequences of skipping our daily maintenance routine.

This thread will remain locked until actual commencement of the experiment at 11:00 UTC on Wednesday, December 4th.

General discussion about the experiment should be kept to this thread.

Quick note for people.

If you’re running into a bug, try bug reporting it from within Eve.
That gives CCP more logs from your client, meaning they have a better chance to actually run the bug to ground.

https://community.eveonline.com/support/test-servers/bug-reporting/

You can file it as a bug report here and provide the logs privately: https://community.eveonline.com/support/test-servers/bug-reporting/

Nothing you experienced before 11:00 UTC today would be related to this experiment.

Nothing you experienced before 11:00 UTC today would be related to this experiment.

The experiment only really started at 11 o’clock UTC today, before that TQ was just on its normal 24 hours run. So nothing you experienced prior is related to this experiment.

Yep, thanks for the report; we are indeed following up on some chat presence issues that are possibly related to the #nodowntime experiment.

Very probably different issues; but, yes, we are following up on chat presence issues that may be related to the #nodowntime experiment.

Indeed, a known issue that asteroids only respawn during downtime.

FYI https://www.eveonline.com/article/q1zzbn/solution-for-stuck-structure-timers-during-no-downtime

FYI https://www.eveonline.com/article/q1zzbn/solution-for-stuck-structure-timers-during-no-downtime

We are following up on reports on this.

Yep, noted, thanks; we’ve found the code for this…

We are following up on chat presence issues and believe we understand why this is happening. Will resolve itself during the next downtime.

We believe we have found the relevant code and it is linked to this #nodowntime experiment.

We are following up on reports on issues with chat presence.

These are the chat presence issues I have referenced above.

We are aware of this issue; across the cluster right now then different nodes can disagree on the correct time by up to 3.3 seconds. If the Location Node hosting the solar system you are in and the Proxy Node your Client is connecting through are at opposite ends of that spectrum then your Client will simulate the actions differently than the Location Node is executing them, as in at a different time.

We were not intending to reboot unless the cluster became inoperable. This will have corrected itself at DT this morning.

I was looking at the relevant code yesterday, what is your source?

Interesting, thanks for the report.

Indeed, we know why this is and were tracking the severity of this issue throughout the experiment.