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.
No comments:
Post a Comment