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