Extremely slow Petrel import + crash when saving

Jef Driesen jefdriesen at telenet.be
Sat Sep 21 12:44:43 UTC 2013


On 20-09-13 22:30, Jef Driesen wrote:
> On 20-09-13 20:34, Henrik Brautaset Aronsen wrote:
>> Jef Driesen wrote:
>>> Can you try the attached patch on your mac? Because sending data
>>> appears to be the problem, sending the packet byte by byte is
>>> certainly not going to be the fastest. With the attached patch, the
>>> packet is send at once.
>>>
>>> Another thing that's worth looking at are the tcdrain calls in
>>> serial_write. Just add some extra WARNING or INFO between the write
>>> and tcdrain. I wonder if it's the write or the tcdrain which taking
>>> most of the time.
>>
>> Massive improvement!   The whole download process took 4.5 minutes,
>> that's about 4.7 seconds per dive.  Thanks a lot!
>
>   From 40 to 4.5 minutes. That's no doubt a very nice improvement!
>
> I assume the overhead of sending a single byte or an entire packet remained
> roughly the same. So by sending the entire packet at once, you get a speed
> increase proportional to the length of the packet. I'm still surprised sending a
> byte/packet is in the order of seconds instead of milliseconds. But at the least
> the download speed is now acceptable.
>
> Could you do me a favor, and do a testrun with the attached patch applied, and
> the previous one (temporary) reverted? And then send me the logfile. I would
> like to have a look at the timings of the write vs tcdrain calls to get a better
> understanding of what might be going on. I just need a few packets, so you can
> cancel the download after a minute or so. If you still have it, I'm also
> interested in the logfile of your fast download.

Patch has been pushed.

@Henrik: Thanks for the logfiles. As I already suspected it's not the write() 
call that is slow, but the tcdrain(). But now that the entire packet is send at 
once, it's not really an issue anymore. But still good to know of course :-)

Jef


More information about the subsurface mailing list