On Sun, Nov 30, 2014 at 07:19:55PM +0000, Chris Young wrote:
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)
OK, so modulo usleep(1000) sleeping for ~2ms, rather than 1, that looks
about right.
> > 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 must be missing something fundamental here, then. What is spawning a
process? (I'd also suggest that it's not doing nothing if, in some
circumstances, it's taking >1000 times longer to complete than in
others)
> 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.
Why? We care about throughput, which needs to be measured against some
real clock; if we don't take scheduler context switches into account,
then that will skew the results such that, as far as the bandwidth
calculator is concerned, everything is fine, whereas in reality, it's
not.
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.
We're talking about a difference of over 1000ms here, though. That
doesn't sound like normal behaviour for any scheduling algorithm.
Using clock() seems to be a better solution and rather more portable.
That then means we're not measuring the right thing, though.
J.