Defect: Round Time Calculations in Lich

[OSXLich-Doug]

Round times as supported by various waitrt and castwaitrt methods are inaccurate, leading to additional '... wait' messages which slow game response time, and leading to 'spam' approaches due to the realization that wait times often have a longer duration than the game reported roundtime expiry.

Ondreian has provided greatly simplified code for these methods that needs to be incorporated. The root of the issue remains, however. The root of the issue is the calculated offset of local time to server time. This value varies widely between -1 and 1 with infrequent results outside those ranges observed. As a result, adding the lower range offset results in a shorter waitrt or castwaitrt than is expected increases the frequencies of the '... wait' message. Adding the upper range of the offset needlessly increases the sleep period for the method and supports the 'spam' approach competitive script authors are using.

To address, the calculated offset should be capped to a max value (recommend -.20) and should be subtracted - thereby resulting in appropriately increasing the calculated waitrt or waitcastrt to the expected value with a significantly improved performance.

[OSXLich-Doug]

Code - existing method with Ondreian proposed simplifications

def waitrt?
  sleep checkrt
end

def checkrt
  [0, XMLData.roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f].max
end

def checkcastrt
  [0, XMLData.cast_roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f].max
end

def waitcastrt?
  sleep checkcastrt
end

Test results - 1000 waits with login / death / thought (and lnet) messages enabled.

[exec4: fastest / slowest so far: 1.3176641464233398 / 3.0029592514038086 of 1000 attempts]
[exec4: number of ...wait messages: 33]
[exec4: logons/logoffs/deaths/thoughts: 50]
[exec4: Average wait time is 2.002129964351654.]

[OSXLich-Doug]

Code - proposed method (subtract offset)

def waitrt?
  sleep checkrt
end

def checkrt
  offset = [ XMLData.server_time_offset - 1.0, -0.20 ].max
  [0, XMLData.roundtime_end.to_f - Time.now.to_f - offset].max
end

def checkcastrt
  offset = [ XMLData.server_time_offset - 1.0, -0.20 ].max
  [0, XMLData.cast_roundtime_end.to_f - Time.now.to_f - offset].max
end

def waitcastrt?
  sleep checkcastrt
end

Test results - 1000 waits with login / death / thought (and lnet) messages enabled

[exec4: fastest / slowest so far: 1.7997219562530518 / 2.201582908630371 of 1000 attempts]
[exec4: number of ...wait messages: 0]
[exec4: logons/logoffs/deaths/thoughts: 98]
[exec4: Average wait time is 1.9999505522251129.]

[ondreian]

- offset is not the appropriate arithmetic operation because the offset can be both positive and negative.

What you are essentially simulating here with XMLData.server_time_offset - 1.0, -0.20 is network traversal time, but this is not a constant, it should be a heuristic or not included at all. The second revision is a happy path change, you will never notice it when your network state is good, but it will be very painful if it's bad.

This type of change also cannot be tested in this in the manner because of the way networks work, It would be far more appropriate to alternate strategies so the results are at least temporally correlated.

[OSXLich-Doug]

@ondreian - agreed on all points, but you didn't ask why. Let me illuminate. The first run is essentially the simplification methods you provided. And thank you sincerely - good stuff! I call it "O's methods" only for that reason. I separate out the offset only to draw attention to what is changing - not because it is superior in any way. The delta for the second run: It does not coerce the Integer value from SIMU when calculating the offset.

Bottom line up front - the second method is statistically superior to the first. Range of fastest / slowest times experienced, and average wait time are keys; secondary is the number of ...wait messages recorded in the test. Both of these tests are from the same network, take about 35 to 40 minutes to run and occurred back to back (but not sequentially).

Amplification - I generally test across 4 different networks that I have access to from the same host system. In this case, I did not attempt to do that, since a consistent comparison was what I felt best to share for this discussion. The callout you mention about simulating network traversal time isn't what I had intended though I agree that it does appear to be exactly that as a goal. More on that after you comment on below observations.

offset as Float - added in formula

-code as tested-

XMLParser -

@server_time = attributes['time'].to_i
@server_time_offset = (Time.now.to_f - @server_time)

Lich checkrt -

def checkrt
  offset = XMLData.server_time_offset.to_f
  [ 0, XMLData.roundtime_end.to_f - Time.now.to_f + offset ].max
end

-results-

[exec1: fastest / slowest so far: 1.1255290508270264 / 3.492724895477295 of 1000 attempts]
[exec1: number of ...wait messages: 98]
[exec1: logons/logoffs/deaths/thoughts: 314]
[exec1: Average wait time is 2.2095331287384035.]

This next run is still O's method, but rather than coercing @server_time_offset to Float in either class XMLParser or method checkrt, I leave it as Integer (Simu sends XML text of what I presume is their Time.now.to_i. This simply retains that value as sent without coercion beyond String to Integer.)

offset as Integer - added in formula

-code as tested-

XMLParser -

@server_time = attributes['time'].to_i
@server_time_offset = (Time.now.to_i - @server_time)

Lich checkrt -

def checkrt
  offset = XMLData.server_time_offset
  [ 0, XMLData.roundtime_end.to_f - Time.now.to_f + offset ].max
end

-results-

[exec1: fastest / slowest so far: 1.8035531044006348 / 2.0100951194763184 of 1000 attempts]
[exec1: number of ...wait messages: 38]
[exec1: logons/logoffs/deaths/thoughts: 264]
[exec1: Average wait time is 1.9994522638320922.]

[OSXLich-Doug]

I will simply add - if my math is right:

The delta between the two 'Average wait time' values of 0.21 across 1000 2-second iterations is an increase of approx. 10.5% or 3.5 minutes for the total run. Hence the use of the term 'statistically significant'. And hence the range of variability in how long the tests take.

[ondreian]

I'm not really saying either is perfect, I'll trust your judgement, but i would be cautious about drawing too much statistical conclusions in the manner they are being performed. Any of these standardizations will be better than the current mess, so I'm fine to ship it and see what happens

On Thu, Sep 23, 2021, 11:26 OSXLich-Doug @.***> wrote:

@ondreian https://github.com/ondreian - agreed on all points, but you didn't ask why. Let me illuminate. The first run is essentially the simplification methods you provided. And thank you sincerely - good stuff! I call it "O's methods" only for that reason. I separate out the offset only to draw attention to what is changing - not because it is superior in any way. The delta for the second run: It does not coerce the Integer value from SIMU when calculating the offset.

Bottom line up front - the second method is statistically superior to the first. Range of fastest / slowest times experienced, and average wait time are keys; secondary is the number of ...wait messages recorded in the test. Both of these tests are from the same network, take about 35 to 40 minutes to run and occurred back to back (but not sequentially).

Amplification - I generally test across 4 different networks that I have access to from the same host system. In this case, I did not attempt to do that, since a consistent comparison was what I felt best to share for this discussion. The callout you mention about simulating network traversal time isn't what I had intended though I agree that it does appear to be exactly that as a goal. More on that after you comment on below observations. offset as Float - added in formula

-code as tested-

XMLParser -

@server_time = attributes['time'].to_i @server_time_offset = (Time.now.to_f - @server_time)

Lich checkrt -

def checkrt offset = XMLData.server_time_offset.to_f [ 0, XMLData.roundtime_end.to_f - Time.now.to_f + offset ].max end

-results-

[exec1: fastest / slowest so far: 1.1255290508270264 / 3.492724895477295 of 1000 attempts] [exec1: number of ...wait messages: 98] [exec1: logons/logoffs/deaths/thoughts: 314] [exec1: Average wait time is 2.2095331287384035.]

This next run is still O's method, but rather than coercing @server_time_offset to Float in either class XMLParser or method checkrt, I leave it as Integer (Simu sends XML text of what I presume is their Time.now.to_i. This simply retains that value as sent without coercion beyond String to Integer.) offset as Integer - added in formula

-code as tested-

XMLParser -

@server_time = attributes['time'].to_i @server_time_offset = (Time.now.to_i - @server_time)

Lich checkrt -

def checkrt offset = XMLData.server_time_offset [ 0, XMLData.roundtime_end.to_f - Time.now.to_f + offset ].max end

-results-

[exec1: fastest / slowest so far: 1.8035531044006348 / 2.0100951194763184 of 1000 attempts] [exec1: number of ...wait messages: 38] [exec1: logons/logoffs/deaths/thoughts: 264] [exec1: Average wait time is 1.9994522638320922.]

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elanthia-online/lich-5/issues/35#issuecomment-926012054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKHAW263KFNHDNENBAEKTUDNPMLANCNFSM5EKS2ZVQ .

[OSXLich-Doug]

i would be cautious

Very significant point that I am losing sight of. Thank you for the reminder.

[ondreian]

your math appears correct, but since the results are not temporally parallel, there is the distinct possibility that there are underlying processes which might alter the significance of the results.

i would perhaps spin up 2 f2ps and run the tests in parallel, and if you are up for it, do it with some sort of simulated network latency (a basic VPN should be enough for now).

On Thu, Sep 23, 2021, 11:38 OSXLich-Doug @.***> wrote:

I will simply add - if my math is right:

The delta between the two 'Average wait time' values of 0.21 across 1000 2-second iterations is an increase of approx. 10.5% or 3.5 minutes for the total run. Hence the use of the term 'statistically significant'. And hence the range of variability in how long the tests take.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elanthia-online/lich-5/issues/35#issuecomment-926019703, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKHAW7LG5OJTTFJH3GOCLUDNQYBANCNFSM5EKS2ZVQ .

[ondreian]

ultimately, that is a lot of work, i realize, we are just moving from a very conservative algorithm with a built in 0.6s latency buffer to living closer to the edge of real time, and there are a lot of hurdles and potential footguns with this type of work.

On Thu, Sep 23, 2021, 11:52 Benjamin Clos @.***> wrote:

your math appears correct, but since the results are not temporally parallel, there is the distinct possibility that there are underlying processes which might alter the significance of the results.

i would perhaps spin up 2 f2ps and run the tests in parallel, and if you are up for it, do it with some sort of simulated network latency (a basic VPN should be enough for now).

On Thu, Sep 23, 2021, 11:38 OSXLich-Doug @.***> wrote:

I will simply add - if my math is right:

The delta between the two 'Average wait time' values of 0.21 across 1000 2-second iterations is an increase of approx. 10.5% or 3.5 minutes for the total run. Hence the use of the term 'statistically significant'. And hence the range of variability in how long the tests take.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/elanthia-online/lich-5/issues/35#issuecomment-926019703, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIKHAW7LG5OJTTFJH3GOCLUDNQYBANCNFSM5EKS2ZVQ .