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.
