I looked a bit more through the source code. The implementation looks fine. It uses syscall clock_gettime with CLOCK_MONOTONIC.
And the reason for my problem is: # CONFIG_MONOTONIC_SYSCALL is not set In this case gettimeofday() is used. Thanks, Adrian W dniu 2012-04-11 18:45, Cathey, Jim pisze: > Is not one of the ways to manage delta-time > timeouts to use uptime() instead of time()? > You don't care what time it is, you only want > to manage a timeout on the order of seconds, > so a monotonic time source like uptime() is > actually preferable. > > It seems to me that 64-bit math is unnecessarily > punitive, especially for many embedded processors. > > Also, DST doesn't affect the value of time() > et al. at all, or should not. > > -- Jim > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Adrian Szyndela > Sent: Wednesday, April 11, 2012 1:41 AM > To: [email protected] > Subject: [PATCH] arpping in udhcpc > > Hi, > > I'm attaching a patch for way too long wait on poll() during arpping > after IP address acquiring over DHCP. > > It happens on a platform which starts with Epoch time. Then, at some > point, a correct time source appears, and an actual time is set. > > If an actual time is set during wait on poll(), computing of a timeout > overflows on unsigned type. The patch just changes types to stay with > long long computing. > > Before applying the patch the side effect of setting an actual time is > close to hangup - with no IP address assigned. After applying the patch > the side effect of time change is that poll() might wait shorter than > desired 2 seconds in case of socket activity. > > I found a comment /* We don't expect to see 1000+ seconds delay, > unsigned is enough */ in networking/arping.c (which probably is affected > by the problem as well). The above case introduces 1000000000+ seconds > delay :). 3600 seconds at daylight saving time change is a piece of > cake. > > Regards, > Adrian > > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
