Yes, I can do PR. (once I figure out how to do signing) but I don't understand:
> sleeping for small chunks of time can end up being better.
The modification I did used the exact same constant 1ms sleep after each
ftdi_read_data() call that the current code does but it checked elapsed time
prior each 1ms sleep
rather than counting the number of 1ms sleeps until they equaled the desired
millisecond timeout.
Counting the number of 1ms sleeps done does not work since it does account for
the time inside the loop (which can be significant like 100+ ms) since
sometimes the ftdi_read_data() doesn't return immediately
when there is no data.
That is why looking at elapsed time is required.
Are you wanting something smarter than changing the way the loop exits by
checking elapsed time instead of blindly looping {timout} times?
--- bill
On 09/14/2018 04:39 PM, Lubomir I. Ivanov wrote:
> On 13 September 2018 at 21:44, Bill Perry <[email protected]> wrote:
>> Just a reminder that last summer I saw that the code in serial_ftdi_read()
>> doesn't guarantee that a timeout occurs
>> in the desired timeout period.
>> Due to the way it is written, you can get MUCH longer delays when the bytes
>> don't stream in right away or
>> This was an issue I was fighting last year when I was trying to get retries
>> to work on the Pelagic data cable with Android.
>> It actually affects any ftdi device.
>> This is likely an issue on Windows as well.
>>
>> ftdi_read_data() took a few milliseconds of time before returning and that
>> time is not accounted for.
>> And on android the the LIBUSB_ERROR_INTERRUPTED was also happening.
>> This caused the while loop to loop for several minutes before timing out.
>> My solution (which I posted a patch for to the list back in Nov 2017) was to
>> get rid of slept and to always sleep for 1ms.
>> Then rather than comparing slept >= timeout - which doesn't work, was to use
>> gettimofday()
>> to check for the elapsed time to check for the desired timeout period.
>>
> sleeping for small chunks of time can end up being better.
> would you like to submit a github PR to address this improvement as
> per your experiments?
>
> lubomir
> --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
