Worldwide latency

[aatonnomicc]

Good to see you How’s your summer been?

[JPL]

@happybeing

I haven’t kept up with the latest architecture so these questions should be re-examined. Earlier designs were intended to mitigate latency (for example nodes used to compete to be first to deliver each chunk) but I’m not sure if the latest also does so.

@happybeing

JPL do you know if the Primer is up to date in this area and if it could help understand latency?

The competition aspect is not there any more in that nodes not rewarded directly for being the quickest. Instead they are penalised for not providing data quickly enough over time. I guess intelligent caching will replace it for reducing latency for popular files, but I don’t know any details.

[Southside]

@JPL

Instead they are penalised for not providing data quickly enough over time

So eventually a section will tend to consist of nodes with the lowest latency which may map to a common geographical location - or am I talking mince?

[dirvine]

Not really (yes to mince ) Nodes cannot choose sections so will need to provide data fast enough regardless of geography. Latency is not so much an issue as at least starting to transmit.

[Southside]

@dirvine

Nodes cannot choose sections

Yes I get that, but sections can choose (to discard underperforming) nodes. Over time would this not tend to a geographical concentration?
I take your point about speed of response trumping latency, the more efficient disk I/O would mostly compensate for higher latency given that we are dealing with 1Mb chunks, not 200Gb files - or is this even further mince?
Sometimes I need to shake my head out and get the real truth about this network back in.

[dirvine]

@Southside

Yes I get that, but sections can choose (to discard underperforming) nodes. Over time would this not tend to a geographical concentration?

It would do only if all requests for all data in that section (Address range) were from a single geography. I doubt that will happen, though, but …

[futuretrack]

I (almost) never comment here, but I find this one interesting and I’m enjoying the discussion. I was of the same understanding as @Southside .

So is that related to the idea that different elders and adults in the section are geographically separated, and, essentially the fastest responder will be likely from an adult in the the same geographic region as the requester?

(so there could be multiple responders, but the fastest one will likely be in the same location as the client, but the other ones don’t get punished since they may get other requests from geographically closer clients)?

So in this scenario, although we are measuring latency between elders and adults, the client request location has an influence?

Apologies if that’s a bit rambling, but hopefully you get the gist.

[dirvine]

@futuretrack

So is that related to the idea that different elders and adults in the section are geographically separated, and, essentially the fastest responder will be likely from an adult in the the same geographic region as the requester?

Yes, that’s how I would see it.

@futuretrack

So in this scenario, although we are measuring latency between elders and adults, the client request location has an influence?

Yes, kinda. We don’t measure so much (magic numbers and changing resources over time). What we do is relative responsiveness checks as part of the dysfunctional suite. It works like this (mostly)

As each request comes through the elder for an Adult, we increment the requester count. As they respond, we decrease the requester court. If that adult’s count is 50% less than both his neighbour’s, we consider it dysfunctional.

So we don’t check every single response. We aggregate behaviour over “time” relative to the neighbours.

@futuretrack

Apologies if that’s a bit rambling, but hopefully you get the gist.

Never rambling. Questions are always good. We all learn, especially me

[futuretrack]

Thanks David, that makes sense.

[Southside]

Thank you - thats a lot clearer now.