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 Information Portal

 
  • Topic is locked indefinitely.
First pagePrevious page8910
 

Dev Blog: Building a Balanced Universe

First post First post
Author
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#181 - 2013-12-07 23:50:36 UTC
Rain6636 wrote:
still waiting for confirmation that failed wormhole jumps with traffic control messages count against the wormhole mass, but will be looked into. (meanwhile there will be support tickets, handled by uninformed customer service staff)



Why referencing this dev blog?

As it has nothing to do with wormhole jumps, just which nodes start up on what hardware at the end of downtime?

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Rain6636
GoonWaffe
Goonswarm Federation
#182 - 2013-12-08 00:18:03 UTC  |  Edited by: Rain6636
because this change might be the reason for traffic control messages when attempting to make wormhole jumps. fewer nodes = standby mode which causes jump attempts to fail, with a traffic control message similar to the ones you'll experience on the test server. the problem with this condition is the failed jump also counts against the wormhole's mass limit, even though the jump was unsuccessful. This leads to unexpected wormhole collapse due to mass limitations that are reached prematurely. The inaccurate mass accumulation after failed jumps is the issue, beyond the inconvenience of needing to re-attempt wormhole jumps because the node was unprepared.

The traffic control message is a preexisting condition, and is made worse by the reduced number of nodes dedicated to w-space. in the case of jump gates which lack the mass limitations of wormholes, traffic control messages simply mean 'try again'.

This dev blog was referenced because internally, within CCP, it's not guaranteed everyone has up-to-date knowledge of changes such as CCP Prism X's node remapping dev blog. Without knowledge of such a change, employees of CCP and players are likely to assume wormhole mass limitations are handled correctly, without any cause to believe otherwise.

to put the severity of this into perspective, a wormhole with a 3 billion kg mass limit can handle 3 capitals. with a failed jump attempt due to traffic control, the wormhole can only handle 2, after the first capital's mass was inaccurately counted against the wormhole's mass limit.

further implications of this condition include collapsing a 3 billion kg wormhole with 3 capitals that attempt their jumps simultaneously, which would be rejected by traffic control of an unprepared node, and collapse the hole without any jumps made. depending on the goal of the players making the jump with those capitals, this could be good or bad.

a potential "off switch" for wormholes, if a wormhole on an unprepared node is overwhelmed by the initial jump attempt.

this inquiry of mine can be dismissed if it can be confirmed that mass limits are not affected by failed jump attempts due to traffic control. however, i'm farily certain I experienced this bug yesterday when attempting a jump with some ships of considerable mass. it was a sequence of jumps that I have made several times previously.

the basic question is: If a wormhole jump fails because the node is unprepared (and generates a traffic control message), does a ship's mass count against the mass limit of the wormhole, even though the jump was rejected by the node.
Rain6636
GoonWaffe
Goonswarm Federation
#183 - 2013-12-08 07:09:08 UTC  |  Edited by: Rain6636
The jump sequence I mentioned:

a set of 3 orcas jump through a 3 billion kg wormhole for two round trips. at a quarter-billion kg each, this sequence of orca jumps will close a 3 billion kg wormhole very cleanly.

normally, simultaneously:
(colloquially described as "jump jump jump... jump jump jump")

orca 1 - jump out - jump in
orca 2 - jump out - jump in
orca 3 - jump out - jump in

return to pos to wait out the polarization timer, and repeat

orca 1 - jump out - jump in
orca 2 - jump out - jump in
orca 3 - jump out - jump in

and the hole is closed.

on the 6th of December, the sequence looked like:

orca 1 - jump out - jump in
orca 2 - jump out - jump in
orca 3 - jump out - jump in

return to pos to wait out the polarization timer, and repeat

orca 1 - jump out - jump in
orca 2 - jump out - jump, traffic control: you are cleared to jump in 120 seconds, the wormhole closes before your jump completes
orca 3 - jump out - jump, traffic control: you are cleared to jump in 120 seconds, the wormhole closes before your jump completes

the unusual part about this sequence is the traffic control notification. the math and prior experience suggests the jumps would be successful. I could be wrong, but my bug report is unanswered (and i have not received the email to say it is a known bug, or that it is new and has been added to the list of bugs).

I run my clients on separate screens, and my jumps were nearly simultaneous. If wormhole mass accumulation and session changes are handled separately, and there are conditions where jumps fail while mass is still counted, it would explain the bug.

I'm bad at explaining things sometimes. is there anything unclear about the situation i'm describing
Rain6636
GoonWaffe
Goonswarm Federation
#184 - 2013-12-08 10:44:50 UTC
sorry about the triple post, this is something I found (all I've found so far).

https://forums.eveonline.com/default.aspx?g=posts&m=777940#post777940

Quote:
I could go track down an engineer if you want a totally firm answer, but my understanding is that the client is waiting for the server when jumping rather than vice versa. It's only when the *server* has finished the transfer and told the client it's OK to go ahead and load that it finishes the transaction and deducts the mass, and jump requests are not completed strictly in the order they were requested.
(CCP Greyscale)

if that answer could be updated to include how traffic control fits in, that would be greeeeat
Mr Beardsley
Royal Amarr Institute
Amarr Empire
#185 - 2013-12-11 12:26:20 UTC
Highsec should have its own server infrastructure. Better yet, it should be a separate game. All EVE problems solved.
CCP Prism X
C C P
C C P Alliance
#186 - 2013-12-11 15:42:07 UTC
I dislike leaving things hanging.

Wormhole Mass reduction is well outside of the scope of my work. Obviously mass should not be decreased on a denied jump but that should be bug reported through the proper channels so that it receives proper due diligence. Apparently this has been BR'd already so YAY! Lol

Libras are not trustworthy. We're extremely dodgy characters who seem to be willing to adopt any side of everything for the sake of whatever deviant impulses drive us at that given moment.

I do believe everything else has been covered already in previous posts. Blink

Fly safe...
..ish!
Rain6637
GoonWaffe
Goonswarm Federation
#187 - 2013-12-12 00:46:42 UTC
CCP Prism X wrote:
I dislike leaving things hanging.

Wormhole Mass reduction is well outside of the scope of my work. Obviously mass should not be decreased on a denied jump but that should be bug reported through the proper channels so that it receives proper due diligence. Apparently this has been BR'd already so YAY! Lol

Libras are not trustworthy. We're extremely dodgy characters who seem to be willing to adopt any side of everything for the sake of whatever deviant impulses drive us at that given moment.

I do believe everything else has been covered already in previous posts. Blink

Fly safe...
..ish!

tyty o7 o7
Jessica Danikov
Network Danikov
#188 - 2013-12-12 19:20:48 UTC
CCP Prism X wrote:
I do believe everything else has been covered already in previous posts. Blink


So is there going to be any investigation into whether static striping of nodes will give better performance for large fleets moving through systems because of the inter- vs. intra- node thing?
CCP Prism X
C C P
C C P Alliance
#189 - 2013-12-13 08:19:03 UTC
No. Distributing connected solar systems between different nodes will not make any load dissapear. It will just move it elsewhere. Perhaps I wasn't clear enough when I said that intra-jumps were more expensive: It's more expensive for that specific node as it will have to do both the tasks. Jumping between nodes does not magic away some part of the work that needs to be done. It's just done by two nodes. Remember: We do not want a fleet in the south to cause TiDi in the north.

And to reiterate this point: This is not about reducing load, it's about using currently available resources more efficiently. I've already started on another project, that will take some time, that is aimed at actually reducing load generated per client. It will also most probably end up in offloading much work from the system nodes to other nodes thus making any work put into "no adjacent systems on the same node" redundant. I'd rather just start working on an actual performance boost rather than attempting to satisfy unpredictable spike load with a static load balancer.
James Amril-Kesh
Viziam
Amarr Empire
#190 - 2013-12-16 02:16:41 UTC
CCP Prism X wrote:
No. Distributing connected solar systems between different nodes will not make any load dissapear. It will just move it elsewhere. Perhaps I wasn't clear enough when I said that intra-jumps were more expensive: It's more expensive for that specific node as it will have to do both the tasks. Jumping between nodes does not magic away some part of the work that needs to be done. It's just done by two nodes. Remember: We do not want a fleet in the south to cause TiDi in the north.

Who cares about some random system in bum **** egypt? When you have adjacent systems all on the same node, that makes the game even more unplayable than it was previously. It makes the issue of moving large fleets even worse than it was before.

Seriously, what the hell were you thinking? You clearly have no idea how people actually play this game.

Enjoying the rain today? ;)

James Amril-Kesh
Viziam
Amarr Empire
#191 - 2013-12-16 02:19:04 UTC
Hope the pubbie retards are happy.

Enjoying the rain today? ;)

First pagePrevious page8910