Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: progress(1) a bit drunk?

On Sunday 20 July 2008 20:17:15 David Holland wrote:
> On Sun, Jul 20, 2008 at 08:50:38PM +0200, Martin S. Weber wrote:
>  > > > (...)
>  > > > To me it seems as if the reference to start-time has been
>  > > > lost. Instead of the data RATE, all data read until now are
>  > > > displayed as rate.
>  > >
>  > > Wading through the code, I don't see any obvious way for this to
>  > > happen. Are your timecounters working properly?
>  >
>  > How do I test that? (and I'm usually losing time as I'm on a SMP
>  > system. As nptd used to make the machine thrash at times I'm adjusting
>  > the time regularly with ntpdate. Maybe that's the cause? But ntp
>  > shouldn't cause such things, should it??)
> Well, if the system clock is running anything like normally the
> problem isn't that the system clock isn't running.
> If the time jumps backward it will confuse progressbar.c, but to get
> the results you were seeing with the rate it'd need to have jumped
> back to before the transfer started. (Plus, if you're losing time
> that's probably not it.)
> If you can reproduce this easily the best approach might be to load
> debug printfs into progressbar.c... e.g. on line 244 or so print what
> "bytes" and "elapsed" are. The most likely explanation of what you're
> seeing is that "elapsed" is crap, but I don't see how that's possible
> unless gettimeofday() is returning bad stuff.

Maybe the code should use the clock_gettime(CLOCK_MONOTONIC, &timespec) 
function instead then, so any clock changes don't affect the progress bar.



Home | Main Index | Thread Index | Old Index