From owner-freebsd-current Fri Sep 4 08:52:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09115 for freebsd-current-outgoing; Fri, 4 Sep 1998 08:52:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from word.smith.net.au (castles315.castles.com [208.214.167.15]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA09109 for ; Fri, 4 Sep 1998 08:52:49 -0700 (PDT) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (LOCALHOST [127.0.0.1]) by word.smith.net.au (8.9.1/8.8.8) with ESMTP id IAA03514; Fri, 4 Sep 1998 08:44:17 GMT (envelope-from mike@word.smith.net.au) Message-Id: <199809040844.IAA03514@word.smith.net.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp cc: Bruce Evans , caj@lfn.org, freebsd-current@FreeBSD.ORG Subject: Re: bzero bandwidth computation In-reply-to: Your message of "Fri, 04 Sep 1998 13:36:15 +0200." <2797.904908975@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Sep 1998 08:44:16 +0000 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199809041132.VAA10135@godzilla.zeta.org.au>, Bruce Evans writes: > >>>>From a boot -v on my Thinkpad 560E running -current > >>>(GenuineIntel 166MMX pentium): > >>> > >>>i586_bzero() bandwidth = 173130193 bytes/sec > >>>bzero() bandwidth = 688705234 bytes/sec (!!!) > >>> > >>>Hrm, a bit fishy eh? > >> > >>APM strikes again I bet... Your CPU clock changed speed while it ran... > > > >That might have given a negative bandwidth :-). > > No, that would be unlikely. Many APM seem to power up with the CPU in > a reduced speed mode, and then after a short time the crank it up to > full speed. This usually seems to be about the same time they turn the screen on. I think this might more likely be a flurry of SMI activity as the system's warming up the first time around. Changing the CPU speed upwards wouldn't have that effect anyway; it would have resulted in the cycle counter speed being under-estimated, which would have resulted in a scaled under-estimation of copy speed (I think). The current set of symptoms *seem* to be related to cycle-counter related interpolation being off because either the tick rate is erratic or the CPU speed is non-constant. It's looking like we can't rely on the cycle counter for accurate timing - this will be an issue with desktops as PC98 and PC99 systems start to become common too. 8( -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message