Uwatec Smart Z data download takes 1.5 hours for only 4 dives

Jef Driesen jef at libdivecomputer.org
Tue Dec 24 00:27:53 UTC 2013


On 24-12-13 01:29, Linus Torvalds wrote:
> On Mon, Dec 23, 2013 at 1:25 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>>
>> Linus - I don't remember why we did not use the fingerprint based
>> implementation... can you remind me?
>
> The fingerprint was too much random crud to actually bother saving
> without a sane format (it's just a byte blob). We do use it (to
> generate the dive ID), but we have turned it into something much more
> easily used for our needs.

The only reason why it's a random blob, and not something like a hash, is that 
for some communication protocol it needs to contain some very specific 
information. For example in the case of the uwatecs, the fingerprint contains 
the timestamp that will be send to the device. With a hash, this wouldn't be 
possible because a hash is a one way function and you can't get back the 
original data. There are also devices where we use the fingerprint long before 
the entire dive is downloaded. So calculating a hash is again not possible, 
because the data is not available yet.

Hence the choice of a (small) binary blob, which can contain whatever we need 
for a specific communication protocol.

> Also, it's useless for all the cases we had actually seen, so there
> was very little reason to even worry about it.
>
> But I guess we could save it off for specific dive computers, and then
> in libdivecomputer.c:event_cb(), we cowhen we've calculated the
> deviceid, we could do something like
>
>      /* We don't have this right now, it would walk dives
>       * starting from the most recent to the oldest */
>      for_each_dive_reverse(dive, i) {
>          for_each_dc(dive, dc) {
>              if (dc->deviceid == devdata->deviceid && dc->fingerprint) {
>                  dc_device_set_fingerprint(device, dc->fingerprint);
>                  return 0;
>              }
>          }
>      }
>
> or similar (the above is pseudo-code and the fingerprint isn't a
> string, it would have to be a blob with length etc).

I wouldn't restrict the use of the fingerprint to only a few specific dive 
computers, but instead use it for all models. This will have several advantages:

1. No need to update your code if some new device shows up. The fingerprint just 
works on all devices, so I see no reason to use it only for a few models.

2. It's also the most efficient and user friendly (see my other email), due to 
the use of internal knowledge. That's something an application can't easily do.

3. It's fully independent of the date/time in the application. Even if the user 
changes the date/time, the fingerprint will remain intact, and the dive will not 
be downloaded again.

4. If you also store the most recent fingerprint(s) separately from the dives 
(you can of course still keep the fingerprint on each dive), you can even delete 
dives and they will not be downloaded again. Note that this would also eliminate 
the loop over all dives in your pseudo code.

Subsurface has excellent merging capabilities, but why trying to fix duplicates 
after the fact, when you can prevent them from being downloaded in the first place?

> But this seems to be the first device to actually need it, and the
> 1.5h download seems to really be due to some independent problem (ie
> something is much too slow regardless).

Yes, 1.5h is simply too long. Even the slowest protocols do not take that long.

Jef


More information about the subsurface mailing list