On 2008-03-17, Artur Grabowski <[EMAIL PROTECTED]> wrote:
> Most likely (although you haven't provided any information, so we
> can't be sure), your machine is using the 8254 time counter.
The 8s on the core2duo machine seems a bit slow since slower machines
using 8254 take around 3.5s for the sam
Most likely (although you haven't provided any information, so we
can't be sure), your machine is using the 8254 time counter.
Earlier it would have been using TSC for timekeeping, but TSC is so
unreliable on so many machines and it's more or less impossible to
know when it can be trusted, so TSC
We came to this conclusion several posts ago :)
It felt irrelevant to me what timecounter h/w / driver I was using -
as stated repeated times, after reporting about this I was -just
curious- on what changed from 4.1 to 4.2, and that has been perfectly
elaborated already by Otto Moerbeek and yourse
On 2008-03-15, Jonathan Thornburg <[EMAIL PROTECTED]> wrote:
> Apart from these nits... my results on a Thinkpad T41p (i386 Pentium M)
> running 4.2-stable are (test program compiled with gcc 4.2.0, -g -O2):
> ... with 'apm -H' in effect (clock speed 1.7GHz): 2.92 seconds
> ... with 'apm -L' in eff
It's a (very) minor point, orthogonal to gettimeofday() performance,
but the *first* thing that struck me about the test code
(http://pastebin.com/m311250a6) was "why do (two!) double-precision
floating-point divides by 100.0 instead of multplying by 1.0e-6?".
Indeed, doing two integer-to-doubl
* stolendata.net <[EMAIL PROTECTED]> [2008-03-14 22:34]:
> my 4.1 and 4.2 machines are -stable, and all are running i386, clearly.
>
> My surprise and question was all in the fact that this changed from
> 4.1 to 4.2, and WHY it changed from 4.1 to 4.2. Otto Moerbeek has
> already explained that th
my 4.1 and 4.2 machines are -stable, and all are running i386, clearly.
My surprise and question was all in the fact that this changed from
4.1 to 4.2, and WHY it changed from 4.1 to 4.2. Otto Moerbeek has
already explained that there was a change in the timecounter code, and
your addition puts th
Whichever timer hardware your system is using (you can see with
'sysctl kern.timecounter') seems a bit on the slow side, my 1200MHz
X40 runs your test program in 2.9s.
$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=ICHPM
kern.timecou
The question is, how long would that take on the same hardware but on
4.1? :-) My guess is approx. 16 times less time.
I have now tested this on a third machine, a 1.9ghz Sempron LE-1100,
on both 4.1, 4.2 and 4.3 (all i386 dist), and the result is the same;
approx. 16 times slower gettimeofday() o
On Fri, Mar 14, 2008 at 06:08:42PM +0100, stolendata.net wrote:
> Upon trying to locate an unexplained, massive performance reduction
> when switching host for a number of applications from obsd 4.1 to 4.2,
> I found that it seems gettimeofday() has taken a nosedive in
> performance as of openbsd
$ ./time
100 calls to gettimeofday() ... 4.503s
$ uname -srp
OpenBSD 4.2 AMD Athlon(TM) XP 2600+ ("AuthenticAMD" 686-class, 512KB L2 cache)
$
Seems fine here, looks like the error is on your end.. ;)
Have you tested on 4.3/snapshots.. perhaps enabling/disabling acpi.. etc?
4.3-snapshot of today: 8.0sec on same 1.83ghz C2D
-SD
On Fri, Mar 14, 2008 at 7:01 PM, Paul de Weerd <[EMAIL PROTECTED]> wrote:
>
> On Fri, Mar 14, 2008 at 06:08:42PM +0100, stolendata.net wrote:
> | Upon trying to locate an unexplained, massive performance reduction
> | when switching host f
On Fri, Mar 14, 2008 at 06:08:42PM +0100, stolendata.net wrote:
| Upon trying to locate an unexplained, massive performance reduction
| when switching host for a number of applications from obsd 4.1 to 4.2,
| I found that it seems gettimeofday() has taken a nosedive in
| performance as of openbsd 4
Upon trying to locate an unexplained, massive performance reduction
when switching host for a number of applications from obsd 4.1 to 4.2,
I found that it seems gettimeofday() has taken a nosedive in
performance as of openbsd 4.2.
A very blunt test confirmed it; however, I'm not sure wherein the
p
14 matches
Mail list logo
