netsurf: branch master updated. release/3.2-500-gd08acbc

John-Mark Bell jmb at netsurf-browser.org
Sun Nov 30 18:18:31 GMT 2014


On Sun, Nov 30, 2014 at 04:09:51PM +0000, Chris Young wrote:
> On Sun, 30 Nov 2014 15:01:54 +0000, Vincent Sanders wrote:
> 
> > Is it possible that your implementation of a milisecond monotonic
> > counter in libnsutils is problematic? If it is returning microseconds
> > instead of miliseconds that would cause this erroneus behaviour.
> 
> I thought it might be wrong, so I rewrote it using a different timer. 
> I get very similar results to before.

You've verified that the timer returns sane answers, presumably? What
does this print out?:

#include <inttypes.h>
#include <stdio.h>
#include <time.h>
#include <unistd.h>

#include <nsutils/time.h>

int main(void)
{
        int i;
        uint64_t now_mt;
        struct timeval tv;

        for (i = 5; i > 0; --i) {
                nsu_getmonotonic_ms(&now_mt);
                gettimeofday(&tv, NULL);

                printf("%ld.%ld : %lu\n", tv.tv_sec, tv.tv_usec, now_mt);

                usleep(1000);
        }

        return 0;
}

 
> When I return immediately, I'm still getting things like:
> Wrote 94314 bytes in 1305ms
> even though above it says:
> Wrote 91944 bytes in 1ms

That variance is insanely large. I presume I/O performance is consistent
on Amiga OS?
 
> I've just had a thought that some other task might be nicking the CPU
> whilst the timing is happening - We're measuring how long it takes,
> not how much CPU time it takes.  Perhaps the monotonic timer should be
> measuring CPU time for the task it's running under?

I don't think so, no. If the system scheduler is preventing tasks
running for prolonged periods, then performance is going to suck,
regardless. Thus, disabling the cache under these conditions isn't the
world's worst idea.


J.



More information about the netsurf-dev mailing list