On Sun, 30 Nov 2014 19:52:03 +0000, John-Mark Bell wrote:
> > > 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?
The store operation I've set to offload to another process. For the
purposes of testing this that function should then return almost
immediately. I get the "too slow" error whether I do that or not.
> > > 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.
My point was that if this is affecting disk writing, it is also
affecting network access. If NetSurf for some reason is getting
randomly suspended during the caching code for an extended period, it
will also be getting randomly suspended during network access for an
extended period. Therefore the net gain for using the disk cache is
the same, even if it is sometimes taking a longer time than deemed
normal.
The disk cache throughput should be measured against network
throughput, not against some arbitrary ideal. I'd argue that it
shouldn't be disabling itself based on one bad result either, which is
what is happening here.
> > 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.
People do tell me Exec's task scheduler sucks, so it's not
inconceivable that it has handed the CPU to something (or many things)
more important for a second at the exact point we're trying to
measure. There are lots of processes that run at a higher priority
than NetSurf, although mostly they don't hog the CPU.
Chris
No comments:
Post a Comment