<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 1, 2008, at 11:55 AM, Matthew Toseland wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Courier; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><blockquote type="cite">I'm not saying this is an issue, but when a node is busy the 90-second-<span class="Apple-converted-space"> </span><br></blockquote><blockquote type="cite">standard might actually make the average chk transfer time (over long <br></blockquote><blockquote type="cite">distances) always exactly 90 seconds (through the busiest node). Since <br></blockquote><blockquote type="cite">the transfer timeout is 120 seconds, this actually leaves only 30 <br></blockquote><blockquote type="cite">seconds to accumulate acceptable latency; by your previous value of 30 <br></blockquote><blockquote type="cite">hops, this means one second per hop (1/2 ping time plus coalescing <br></blockquote><blockquote type="cite">delay?).<br></blockquote><br>Hmmm. Perhaps. So we should reduce the 90 seconds to say 60 seconds? That<span class="Apple-converted-space"> </span><br>might cut actual bandwidth usage...</span></blockquote><div><br class="webkit-block-placeholder"></div><div>If my understanding is right, that would only be the case during the transition period (other nodes feed us at the 90 rate, but we expect the 60). This would be a good reason to not drastically cut it in one build (like, to 30; as for the time nodes would be running at 1/3 bandwidth).</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Courier; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Or else, how many transfers are aborted because nodes disconnect, and </span></blockquote><blockquote type="cite">if they would succeed if the target transfer time was shorter than 90 <br></blockquote><blockquote type="cite">seconds? Particularly as the CHK is streaming, that the traffic up <br></blockquote><blockquote type="cite">unto the abort is wasted (50% payload?).<br></blockquote><br>Hmmm. IIRC that is fatal?</span></blockquote></div><br><div>For the request, yes. But my point is that we have already transferred a lot of data which then does not count as payload, right? And it will probably be retried almost immediately; there is no stat AFAICS which represents request failure percentages (except Success, how many TRANSFER_FAILED, ACCEPT_TIMEOUT, FATAL, etc).</div><div><br class="webkit-block-placeholder"></div><div>--</div><div>Robert Hailey</div><div><br class="webkit-block-placeholder"></div></body></html>