sensus ultra slow read

[Jef Driesen]

On 2012-08-03 01:46, Artur Wroblewski wrote:
> I am using libdivecomputer 781f0db71f7a06591e819f7960dd5b504b4f16a0
> at the moment and when trying to download the data from my
> Sensus Ultra I can see the following on Linux via strace
>
> select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 
> 999992})
> read(3, "\1\0\323u\245", 31095)         = 5
> select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 2265})
> read(3, "\2\3d\35\321\202\n\7\2\0z\203\177", 31090) = 13
> select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 
> 999869})
> read(3, "\1\371\0\n\0W\4", 31077)       = 7
> select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 
> 999995})
> read(3, "\17\0\1", 31070)               = 3
> select(4, [3], [], [], {5, 0})          = 1 (in [3], left {4, 
> 999968})
> read(3, "\0`@", 31067)                  = 3

The behavior you see with strace is perfectly normal. The serial_read() 
function is implemented as a loop around the select() and read() 
syscalls. The select() call blocks until some data has arrived, and when 
it returns, all the available data is read(). This process is repeated 
until we have received the entire data packet (or the timeout expired). 
This is the standard pattern to read data from character devices (or 
sockets) on linux.

> The data download is very slow (still downloading actually ;) and I 
> wonder
> what that could be
> - some change in libdivecomputer (it reads 1-5 bytes at once :/)
> - the device dies
> - Linux kernel 3.5.0
> - combination of all above
>
> Does anyone experience something similar?

Have you measured the download time? When I check an older logfile of 
mine (version c4172ecdf6c2f6b68eba7e06e446d46aef66a729), a full download 
(2080768 bytes) took 206 seconds on my system. In a more recent logfile 
I have lying around (downloaded on 2012/06/28, don't know the exact 
version, but probably 87397a4ea1c63d78efd9bf751dee19f54257a6f9), it took 
only 186 seconds. So that's perfectly in line with the expected timings. 
Do you get very different numbers?

I would be very surprised if it takes significant longer for you. 
Because due to the very strict timing requirements of the sensusultra, 
any delay longer than 50ms will cause the download to fail. So if you 
have performance problems somewhere (libdivecomputer, kernel, pl2303 
driver), I would expect a failed download, not a slow download.

One exception would be if you receive a large amount of corrupted 
packets. In that case the packet is retried, which will increase the 
download time if you get a significant percentage of corrupted packets. 
However I have never seen any corrupted packets so far.

There have been very little changes to the serial and sensusultra code. 
The only one that may have some effect is 
3c07a3017f383fc14f27a32ae81fddc7e5ba25a7. This commit integrates the 
tcdrain() call into the serial_write() function. Before this change, the 
sensusultra backend didn't call tcdrain() at all. But this only affects 
writing, not reading.

How are you downloading the dives? Are you downloading all dives, or 
just the new dives? In the first case, the download will obviously 
become slower and slower over time as you have more dives on the device. 
This can definitely make the difference between a download of just a few 
seconds and one taking several minutes!

Jef