Dive data import error with Hollis DG03
jef at libdivecomputer.org
Wed Mar 26 07:27:37 PDT 2014
On 2014-03-26 14:38, Rick Walsh wrote:
> On 26 March 2014 23:38, Jef Driesen <jef at libdivecomputer.org> wrote:
>> There is still a failure early on, so I doubt the 100ms delay at the
>> end of
>> the open call (e.g. the one you patched above) changed anything. But
>> as I
>> already suspected, the fixed 100ms delay before the retry after the
>> causes the retry to succeed immediately. And from then on, the extra
>> does the trick for all later packets. Excellent.
> I think the reason for the early failure may actually be that zero
> delay (the initial value) between calls just isn't enough, at least
> some of the time, so it fails early on. After the first failure, the
> delay increases to 1ms, which is ok, at least with my computer / dive
> computer. So, I tried setting the initial delay value to 1ms (line 437
> of oceanic_atom2.c).
> // Set the default values.
> device->port = NULL;
> device->delay = 1;
> Now I get zero errors, and the total time is under 1 minute. That's 7
> seconds less than on Windows, which also had no errors. Boo ya.
That's correct, but there is a very good reason why I want to start with
a zero delay: we don't want to impact systems that don't need a delay at
all. We try to detect the minimal delay on the fly. That's the whole
point of using an adaptive delay. If you don't need a delay, it will
stay at zero. But if you do need it, you'll reach the minimal value
after a few attempts.
You may not be aware of this, but the resolution of the Windows system
timer isn't very high. It's typically around 15ms (unless an application
increases it, at the expense of higher power consumption). The result is
that, if you try to sleep for less time, you'll end up sleeping for a
much longer time than you requested. But if that overhead of 1ms per
packet turns into some 15ms per packet, then the total download time
becomes rather long...
You can find a nice explanation here (section 2.2):
Note that the Windows sleep and the Linux nanosleep functions do not
guarantee that they will never sleep longer than requested. This all
depends on the kernel's scheduler (e.g. if there is another task
running, your application may not get scheduled again immediately). But
in general Linux does much better in this regard.
More information about the subsurface