[U-Boot] [PATCH 1/3] net: Make TFTP server timeout configurable

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Bartlomiej Sieka wrote:
> There are two aspects of a TFTP transfer involving timeouts:
> 1. timeout waiting for initial server reply after sending RRQ
> 2. timeouts while transferring actual data from the server
> 
> Since the upcoming auto-update feature attempts a TFTP download during each
> boot, it is undesirable to have a long delay when the TFTP server is not
> available. Thus, this commit makes the server timeout (1.) configurable by two
> global variables:
> 
> TftpRRQTimeoutSecs
> TftpRRQTimeoutCountMax
> 
> TftpRRQTimeoutSecs overrides default timeout when trying to connect to a TFTP
> server, TftpRRQTimeoutCountMax overrides default number of connection retries.
> The total delay when trying to download a file from a non-existing TFTP server
> is TftpRRQTimeoutSecs x TftpRRQTimeoutCountMax seconds.

Hi Bartlomiej,

Are seconds an appropriate scale factor for the timeout?  Using tenths 
(thousandths?) of seconds seems much better for allowing timeout 
choices.  (Thousandths could cause problems with clock tick resolution 
and is unnecessarily fine grained.  Gut feel is tenths of seconds is 
sufficient granularity and practical.  Hundredths should be practical too.)

With seconds, you only can chose 1, 2, 3, ... seconds for the timeout. 
This becomes more severe with the number of timeouts that you chose.

My gut feel is that some multiple of tenths of seconds times some number 
of retries totaling 1-2 seconds (say 0.2 seconds x 10 retries or 0.5 
seconds x 4 retries) is much more practical than 2 retries at 1 second 
intervals.

Best regards,
gvb