[ale] Trouble with new Pentium D

[Chuck Huber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ale-request at ale.org wrote:

> ------------------------------ Message: 5 Date: Tue, 9 Jan 2007 15:59:35 -0500 (EST)
> From: "Michael Smith" <msmith at mikeandmel.com>
> Subject: Re: [ale] Trouble with new Pentium D
>
> Should you see 2 cpu's here?
>
> >
> > jbouse at eragon:~$ cat /proc/cpuinfo
> > processor       : 0
> > vendor_id       : GenuineIntel
> > cpu family      : 15
> > model           : 4
> > model name      : Intel(R) Celeron(R) CPU 2.80GHz
> > stepping        : 9
> > cpu MHz         : 2793.281
> > cache size      : 256 KB
> >

He's not running a P4D.  Below is what I from the machine at work. It's
correctly showing the "D" model on both CPU's.  As you can see, this is
Suse 10.1 running a 2.6 kernel.  One of the nice things about the dual
core architecture is that data hazards in each cache are resolved within
the chip - no external hardware required.

For those not familiar with data hazards, such is created when one
processor writes a value to memory that is required by the another
processor.  If the write is cached local to the first processor, the 2nd
CPU winds up using the previous value.  To resolve such a hazard, when
data gets written, its address is marked as dirty.  When the 2nd CPU
attempts to access that address, it now knows that it must fetch the new
value from RAM (much slower than accessing a local cache).

Typically, caches are wider than the native word length of the system
and are usually a 2^n multiple of the external memory data buss width.
i.e. On a system with 64-bit memory, a local cache might be 512 bits
wide.  Such a would require 8 memory reads to fill one word of cache.

The wider the cache, the faster the system to a limit.  The trade-off is
 that when a cache word is marked dirty multiple memory accesses are
required to fill the cache.  This is the case if the internal cache
width is wider than the external memory buss.  The widest cache I've
seen was 4096 bits wide and it was feeding from 64-bit memory on a
32-bit MIPS processor.  The memory was designed to perform a burst read
of 64 cycles from aligned addresses.  A burst read requires only one
address setup cycle whereas non-burst reads require an address setup on
each read cycle.

As for the P4 series, and specifically the P4D, I have no idea how wide
the caches is.  If I recall correctly, DIMM memory is now 256 bits wide.
 Please correct me if I'm wrong.

'nuf of that.  Here the P4D system at work:


chuck at lightning:/home/chuck> cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) D  CPU 2.66GHz
stepping        : 7
cpu MHz         : 2666.815
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
bogomips        : 5338.78

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) D  CPU 2.66GHz
stepping        : 7
cpu MHz         : 2666.815
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc pni monitor ds_cpl tm2 cid cx16 xtpr lahf_lm
bogomips        : 5333.58

chuck at lightning:/home/chuck> cat /etc/issue

Welcome to SUSE LINUX 10.1 (i586) - Kernel \r (\l).


chuck at lightning:/home/chuck> uname -r
2.6.16.21-0.13-smp



- --
Chuck Huber
Duke Pro, Inc.
Office: 828-684-6022
Cell: 828-778-3776
Home: 828-683-7324
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFpBxGiR3HaLbYCa4RAqlWAKC6eB81MMdhFEXBzfX3HYU/dIJmZwCdFiWi
pMmvqhLwQ8iH85SV0MO6mHA=
=tnjz
-----END PGP SIGNATURE-----