Deal with network latency

[arr28]

...to make a sensible judgement about when to submit our move.

[arr28]

I'm working on this in the network-latency branch, but it's proving more difficult than I expected. See http://stackoverflow.com/questions/22417228.

[SteveDraper]

TCP backoff-retry is inherently (and explicitly in most implementations) pseudo-random because that leads to better global queuing behavior (some implementations double the timeout on each retry up to the max, but most modern ones are pseudo-random I believe). How adaptive are you trying to make this (i.e. - how responsive to changing sampling over the period the player is active)? If you just plan to measure it once at startup maybe you're over-engineering and it would suffice to take a ping time as a command line param! (i.e. - the user should do a ping first if they wan to optimize, and just invoke with the value they get). If you plan to be more adaptive you need to be careful to use relatively long run moving averages to avoid adapting to unreliable (downward) spikes

Steve

On Sat, Mar 15, 2014 at 3:56 AM, Andrew Rose notifications@github.comwrote:

I'm working on this in the network-latency branch, but it's proving more difficult than I expected. See http://stackoverflow.com/questions/22417228 .

Reply to this email directly or view it on GitHubhttps://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37720955 .

[arr28]

I was planning to be adaptive with a long moving average - and also keep a note of the high watermark and stddev. But it looks like my technique isn't going to work because I can't find a way of reliably measuring a single round trip unless I can find a socket to connect to or the server responds to pings. And there's no guarantee that a GGP server will have an open socket or respond to pings.

On 15 March 2014 14:01, SteveDraper notifications@github.com wrote:

TCP backoff-retry is inherently (and explicitly in most implementations) pseudo-random because that leads to better global queuing behavior (some implementations double the timeout on each retry up to the max, but most modern ones are pseudo-random I believe). How adaptive are you trying to make this (i.e. - how responsive to changing sampling over the period the player is active)? If you just plan to measure it once at startup maybe you're over-engineering and it would suffice to take a ping time as a command line param! (i.e. - the user should do a ping first if they wan to optimize, and just invoke with the value they get). If you plan to be more adaptive you need to be careful to use relatively long run moving averages to avoid adapting to unreliable (downward) spikes

Steve

On Sat, Mar 15, 2014 at 3:56 AM, Andrew Rose <notifications@github.com

wrote:

I'm working on this in the network-latency branch, but it's proving more difficult than I expected. See http://stackoverflow.com/questions/22417228 .

Reply to this email directly or view it on GitHub< https://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37720955> .

Reply to this email directly or view it on GitHubhttps://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37726418 .

[SteveDraper]

It would be worth raising this on the boards/with Sam (or the former with an email to Sam to draw this attention to the board posting), as a suggestion for an improvement to the GGP protocol, though TBH, a more ideal improvement would be to allow interim results to be sent with the semantics that the server takes the last one received before the timeout. I guess the problem there is that the 'server' is actually the client, so that would require polling...

On Sat, Mar 15, 2014 at 11:49 AM, Andrew Rose notifications@github.comwrote:

I was planning to be adaptive with a long moving average - and also keep a note of the high watermark and stddev. But it looks like my technique isn't going to work because I can't find a way of reliably measuring a single round trip unless I can find a socket to connect to or the server responds to pings. And there's no guarantee that a GGP server will have an open socket or respond to pings.

On 15 March 2014 14:01, SteveDraper notifications@github.com wrote:

TCP backoff-retry is inherently (and explicitly in most implementations) pseudo-random because that leads to better global queuing behavior (some implementations double the timeout on each retry up to the max, but most modern ones are pseudo-random I believe). How adaptive are you trying to make this (i.e. - how responsive to changing sampling over the period the player is active)? If you just plan to measure it once at startup maybe you're over-engineering and it would suffice to take a ping time as a command line param! (i.e. - the user should do a ping first if they wan to optimize, and just invoke with the value they get). If you plan to be more adaptive you need to be careful to use relatively long run moving averages to avoid adapting to unreliable (downward) spikes

Steve

On Sat, Mar 15, 2014 at 3:56 AM, Andrew Rose <notifications@github.com

wrote:

I'm working on this in the network-latency branch, but it's proving more difficult than I expected. See http://stackoverflow.com/questions/22417228 .

Reply to this email directly or view it on GitHub< https://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37720955> .

Reply to this email directly or view it on GitHub< https://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37726418>

.

Reply to this email directly or view it on GitHubhttps://github.com/SteveDraper/ggp-base/issues/16#issuecomment-37730855 .

[arr28]

Polling not required. A couple of other possibilities include...

• Player tags response as an interim response. Match host immediately requests another order. Player is in control of how many interim responses it submits. Problem with this is that each interim order introduces a full round-trip delay before another can be sent. The whole point of this is to deal with large latency - so that wouldn't be great.
• Player uses chunked transfer encoding in the response. It sends a further chunk each time it wants to submit an interim order.
  • If it is finished thinking, it sends the spec-definied 0-length chunk to close the response.
  • When the deadline comes, the server uses the most recently received chunk and tears down the connection.
  • Existing players continue to send a single unchunked response, which the server processes exactly as now.

I have proposed the latter to Sam today (17/3).

[arr28]

Sam writes...

I'd love to do this -- I'm definitely of the opinion that we should support optional "draft moves" so that latency issues are less disruptive. Unfortunately this hasn't really garnered support yet from the folks at Stanford who actually write the spec for GGP network communication. And I don't want to modify Tiltyard in a way that doesn't conform to the GGP spec. (Keep in mind that the Stanford folks have a separate system they use for running the world competitions, so even if I do something crazy in Tiltyard, that won't help during a real competition unless the Stanford system also supports it.)

I've cc'd Bertrand on this discussion, since he's one of the folks at Stanford who works on the GGP spec.

[arr28]

I'm getting some traction with Sam & Bertrand for updating the spec. to permit draft moves.

[arr28]

This has gone quiet. Unassigning because I'm not actively persuing it.