Dive data import error with Hollis DG03

[Jef Driesen]

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 
>> NAK
>> causes the retry to succeed immediately. And from then on, the extra 
>> 4ms
>> 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):

http://www.windowstimestamp.com/description

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.

Jef