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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
