<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 10, 2015 at 10:50 AM, Jef Driesen <span dir="ltr"><<a href="mailto:jef@libdivecomputer.org" target="_blank">jef@libdivecomputer.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br></span>
It seems the estimated size is off by 64 to 832 bytes (or 2-26 samples). That's a bit worse than the numbers I got. I wonder where those extra samples come from. One possibility is that the divetime does not include shallow samples. If that's true, then it might be impossible to find an upper bound.<br></blockquote><div><br></div><div>I have configured a 4 minute delay at the end of the dive, maybe that's the reason?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ideally, we want an upper bound for the estimated size. If the actual size is larger than our estimated size (underestimation), the progress will exceed 100%. That's certainly not good. We can always force the current progress to stay below our estimated value to avoid this problem. But the downside is that doing that will "freeze" the progress at 100% although there is still data being transferred. With an overestimation, the progress may not reach 100%, but that's fine.</blockquote><div></div></div><br></div><div class="gmail_extra">A ballpark estimation is way better than about 2^24 off :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Henrik</div></div>