On Wednesday 14 April 2010 01:01:08 Steve Bennett wrote:
> On 13/04/2010, at 11:09 AM, Rob Landley wrote:
> > On Tuesday 13 April 2010 10:08:56 Kim B. Heino wrote:
> >> BusyBox 1.16.1 on a small armv4tl system:
> >>
> >> $ time hwclock -w
> >> real    0m 24.34s
> >> user    0m 0.00s
> >> sys     0m 0.00s
> >>
> >> $ time hwclock -w
> >> real    0m 24.07s
> >> user    0m 0.01s
> >> sys     0m 0.00s
> >>
> >> $ time hwclock -w
> >> real    0m 24.20s
> >> user    0m 0.00s
> >> sys     0m 0.00s
> >>
> >> rem_usec seems to be about 996600 after every iteration. Changing sync
> >> resolution from 1ms to 5ms helps, but there has to be better solution.
> >> Denys?
> >
> > I can confirm this on my armv4tl system image:
> >
> >  wget
> > http://impactlinux/com/fwl/downloads/binaries/system-image-armv4tl.tar.bz
> >2 tar xvjf system-image-armv4tl.tar.bz2
> >  cd system-image-armv4tl
> >  ./run-emulator.sh
> >
> > wait through the boot messages...
> >
> >  (armv4tl) /home # time hwclock -w
> >  real        0m 24.98s
> >  user       0m 0.01s
> >  sys         0m 0.01s
> >
> > This assumes you have qemu 0.12.x installed.
> >
> > Rob
> >
> > P.S: As expected, application emulation is useless here:
> >
> >  $ qemu-arm ./hwclock
> >  Unsupported ioctl: cmd=0xffffffff80247009
> >  hwclock: RTC_RD_TIME: Function not implemented
>
> Interesting.
>
> BusyBox v1.17.0.git
>
> armv5teb
> ~ # strace hwclock -w
> ... blah blah ...
> open("/etc/adjtime", O_RDONLY)          = -1 ENOENT (No such file or
> directory) open("/dev/rtc", O_WRONLY)              = -1 ENOENT (No such
> file or directory) open("/dev/rtc0", O_WRONLY)             = 3
> gettimeofday({1271224598, 269609}, NULL) = 0
> open("/etc/config/TZ", O_RDONLY)        = 4
> read(4, "EST-10\n", 68)                 = 7
> read(4, "", 61)                         = 0
> close(4)                                = 0
>
> ... lots of these ...
>
> open("/etc/config/TZ", O_RDONLY)        = 4
> read(4, "EST-10\n", 68)                 = 7
> read(4, "", 61)                         = 0
> close(4)                                = 0
> gettimeofday({1271224622, 14271}, NULL) = 0
> nanosleep({0, 984729000}, NULL)         = 0
> gettimeofday({1271224623, 8166}, NULL)  = 0

That's a largeish looking nanosleep.

At a guess, that would be this util-linx/hwclock.c snippet:

                /* Try to sync up by sleeping */
                rem_usec = 1000000 - tv.tv_usec;
                if (rem_usec < 1024) {
                        goto small_rem; /* already close, don't sleep */
                }
                /* Need to sleep.
                 * Note that small adj on slow processors can make us
                 * to always overshoot tv.tv_usec < 1024 check on next
                 * iteration. That's why adj is increased on each iteration.
                 * This also allows it to be reused as a loop limiter.
                 */
                usleep(rem_usec - adj);


I'm guessing the tv.tv_usec is larger than 1000000 and thus it wraps?

When CELF is over, I should look at what gettimeofday() is returning to fill in 
the tv field.  Right now, I'm at a conference and thus a bit overscheduled...

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to