On Sun, 30 Nov 2014 18:18:31 +0000, John-Mark Bell wrote:
> > 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?:
1417374580.535953 : 1304710
1417374580.537786 : 1304712
1417374580.539558 : 1304714
1417374580.541320 : 1304716
1417374580.543073 : 1304717
(after I changed the printf to %llu for now_mt)
> > 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?
Nothing to do with I/O, that's not writing anything to disk - just
spawning a process and returning, so it's basically doing nothing.
> > 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.
Yes, but the performance of the whole browser will suck so disabling
the cache is the wrong solution.
In this case the OS has seemingly decided that some other task is more
important whilst NetSurf is timing something critical, and
re-allocated the CPU for rather more milliseconds than the bandwidth
checker would like.
Using clock() seems to be a better solution and rather more portable.
Chris
No comments:
Post a Comment