I was playing around with a program that I was using to time differences
between kernels (a silly prime program that puts out 1000000 primes). I
noticed a very strange behaviour. On a fresh boot, with the Penguin
pictures that the Matrox FB driver puts up, the prime program runs
1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X,
and exit, it runs 48 seconds. Is this a known behaviour? Thanks.
Andy Carlson |\ _,,,---,,_
[email protected] ZZZzz /,`.-'`' -. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org
On Mon, Apr 23, 2001 at 08:06:11PM -0500, Andy Carlson wrote:
> I was playing around with a program that I was using to time differences
> between kernels (a silly prime program that puts out 1000000 primes). I
> noticed a very strange behaviour. On a fresh boot, with the Penguin
> pictures that the Matrox FB driver puts up, the prime program runs
> 1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X,
> and exit, it runs 48 seconds. Is this a known behaviour? Thanks.
is there any change in /proc/mtrr before and after X?
Good luck,
Jurriaan
--
BOFH excuse #176:
vapors from evaporating sticky-note adhesives
GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.13 0.03 0.01
time prime before x
real 1m23.535s
user 0m40.550s
sys 0m42.980s
/proc/mtrr before x
reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
reg01: base=0xfd800000 (4056MB), size= 4MB: write-combining, count=1
time prime after x
real 0m48.732s
user 0m41.070s
sys 0m7.690s
/proc/mtrr after x
reg00: base=0x00000000 ( 0MB), size= 256MB: write-back, count=1
reg01: base=0xfd800000 (4056MB), size= 4MB: write-combining, count=1
time prime in X
real 0m42.835s
user 0m41.180s
sys 0m1.710s
/proc/version
Linux version 2.4.3-ac12 (root@bigandy) (gcc version 2.95.2 19991024 (release)) #15 SMP Mon Apr 23 19:35:33 CDT 2001
/proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 1
model name : Pentium Pro
stepping : 9
cpu MHz : 199.312
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
bogomips : 397.31
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 1
model name : Pentium Pro
stepping : 7
cpu MHz : 199.312
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
bogomips : 398.13
Andy Carlson |\ _,,,---,,_
[email protected] ZZZzz /,`.-'`' -. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://andyc.dyndns.org
On Mon, 23 Apr 2001, Mark Hahn wrote:
> > I was playing around with a program that I was using to time differences
> > between kernels (a silly prime program that puts out 1000000 primes). I
> > noticed a very strange behaviour. On a fresh boot, with the Penguin
> > pictures that the Matrox FB driver puts up, the prime program runs
> > 1 minute, 30 seconds. If I reset, it still runs 1M30S. If I start X,
> > and exit, it runs 48 seconds. Is this a known behaviour? Thanks.
>
> do you mean that running and exiting X makes your computer faster?
> is /proc/mtrr sane at both times?
>
On Tue, Apr 24, 2001 at 06:19:31AM -0500, Andy Carlson wrote:
> time prime before x
> real 1m23.535s
> user 0m40.550s
> sys 0m42.980s
>
> time prime in X
> real 0m42.835s
> user 0m41.180s
> sys 0m1.710s
There can be two reasons:
(1) You are using matrox's mga module. They have
'program chip core to production level frequency
instead of bios safe one' in their changelog.
Although difference 100% makes (2) more probably.
(2) matroxfb does not try to activate any AGP transfer
mode. Maybe some X driver tries and succeeds.
You can try:
time dd if=/dev/zero of=/dev/fb0 bs=1M count=8
before X and after X. If times are same, then it is
chip core frequency. If times are 2:1, it is either
chip memory freqency, or AGP...
Petr Vandrovec
[email protected]