Re: netsurf: branch master updated. release/3.2-500-gd08acbc
snip other discussion which i have not addressed 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. Eventually I will add the network fetch bandwidth measurement, however as has been discovered it was hard enough to manage this in the backing store code so I have not done this yet. However I have changed the disabling test to be scheduled 100 time quanta in the future when a single write goes slow and then check against the overall write bandwidth so the low bandwidth writes must occur over a substantial time period before we disable the cache now instead of just a single event. Hope that addresses the lumpy nature of writeouts causing spurious backing store disables. -- Regards Vincent http://www.kyllikki.org/
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sat, 29 Nov 2014 23:57:22 +, Commit Mailer wibbled on for an age: correctly calculate writeout bandwidth and properly impose limits Is this really right? (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache (22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif (22.497485) content/llcache.c llcache_persist 2420: Overran timeslot (22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache (16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png (16.366319) content/llcache.c llcache_persist 2420: Overran timeslot (16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache Even if I spawn it off to another process (so store returns immediately) I still get the not enough bandwidth message. Chris
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, Nov 30, 2014 at 01:40:47PM +, Chris Young wrote: On Sat, 29 Nov 2014 23:57:22 +, Commit Mailer wibbled on for an age: correctly calculate writeout bandwidth and properly impose limits Is this really right? (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache well under 4000 bytes a second is so slow that it is not useful. The disc caching really needs to be several multiples of the network conenction speed to be useful. Although the minimum bandwidth setting is a passe din parameter and you can chnage the default value in desktop/netsurf.c to experiment. (22.497406) content/llcache.c llcache_persist 2414: Wrote 1480 bytes in 114ms bw:12982 http://news.bbcimg.co.uk/view/1_4_38/cream/hi/news/img/services.gif (22.497485) content/llcache.c llcache_persist 2420: Overran timeslot (22.497549) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (22.497751) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache (16.366240) content/llcache.c llcache_persist 2414: Wrote 3931 bytes in 263ms bw:14946 http://i2.cdnds.net/13/47/hearst.png (16.366319) content/llcache.c llcache_persist 2420: Overran timeslot (16.366384) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (16.366585) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache Even if I spawn it off to another process (so store returns immediately) I still get the not enough bandwidth message. Is it possible that your implementation of a milisecond monotonic counter in libnsutils is problematic? If it is returning microseconds instead of miliseconds that would cause this erroneus behaviour. Chris -- Regards Vincent http://www.kyllikki.org/
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, 30 Nov 2014 15:01:54 +, Vincent Sanders wrote: (22.696681) content/llcache.c llcache_persist 2414: Wrote 884 bytes in 225ms bw:3928 http://aminet.net/pics/at.gif (22.696759) content/llcache.c llcache_persist 2420: Overran timeslot (22.696828) content/llcache.c llcache_persist 2426: Cannot write minimum bandwidth (22.697699) amiga/misc.c ami_misc_req 51: Disc cache write bandwidth is too slow to be useful, disabling cache well under 4000 bytes a second is so slow that it is not useful. Agreed... The disc caching really needs to be several multiples of the network conenction speed to be useful. Although the minimum bandwidth setting is a passe din parameter and you can chnage the default value in desktop/netsurf.c to experiment. I'll have a look at that. Is it possible that your implementation of a milisecond monotonic counter in libnsutils is problematic? If it is returning microseconds instead of miliseconds that would cause this erroneus behaviour. I thought it might be wrong, so I rewrote it using a different timer. I get very similar results to before. 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 So there's something weird with the timer, or something slow is happening between the timing interval. 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? Chris
Re: netsurf: branch master updated. release/3.2-500-gd08acbc
On Sun, Nov 30, 2014 at 04:09:51PM +, Chris Young wrote:
On Sun, 30 Nov 2014 15:01:54 +, Vincent Sanders wrote:
Is it possible that your implementation of a milisecond monotonic
counter in libnsutils is problematic? If it is returning microseconds
instead of miliseconds that would cause this erroneus behaviour.
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?:
#include inttypes.h
#include stdio.h
#include time.h
#include unistd.h
#include nsutils/time.h
int main(void)
{
int i;
uint64_t now_mt;
struct timeval tv;
for (i = 5; i 0; --i) {
nsu_getmonotonic_ms(now_mt);
gettimeofday(tv, NULL);
printf(%ld.%ld : %lu\n, tv.tv_sec, tv.tv_usec, now_mt);
usleep(1000);
}
return 0;
}
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?
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.
J.
