Has anyone out there seen similar problems with SIS630 motherboards?
I know that we discussed this recently and people said that the graphics
chip is eating memory bandwidth but I am not using it, it isn't even in
SVGA mode, it's in text mode and screen blanked. I also tried setting
the AGP mem down to 2MB and that made no difference.
The reason I care is that I like these little cheap boxes called "book pcs"
and the older model was BK810 and used the i810 chipset but the newer ones
are BK630 and use the SIS630 chipset.
The new ones suck on all the stuff I care about, compiles, BitKeeper
regressions, just general software dev stuff.
Any insight appreciated.
----- Forwarded message from Larry McVoy <[email protected]> -----
From: Larry McVoy <[email protected]>
Date: Sat, 6 Oct 2001 13:02:36 -0700
To: [email protected]
Subject: sis/celeron perf sucks?
Cc: [email protected]
This is a 633mhz system on PC133 mem
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU: Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Coppermine) stepping 06
And this is a 466Mhz system on unknown (probably PC66 or PC100) mem:
CPU: Before vendor init, caps: 0183f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Celeron (Mendocino) stepping 05
The bummer is that the memory subsystem sucks doggy doo doo on the former.
Is this a motherboard problem or do the newer celerons suck that bad on
purpose?
Check out the bandwidth stuff, the second row should be faster but isn't:
L M B E N C H 1 . 9 S U M M A R Y
------------------------------------
(Alpha software, do not distribute)
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
i686-linu Linux 2.4.3-2 468 0.6 0.9 5 7 0.06K 1.8 5 0.4K 3K 15K
i686-linu Linux 2.4.2-2 634 0.5 0.7 4 5 0.03K 1.3 3 0.7K 4K 17K
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
i686-linu Linux 2.4.3-2 1 9 137 40 207 60 209
i686-linu Linux 2.4.2-2 0 5 214 82 469 133 470
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
i686-linu Linux 2.4.3-2 1 8 14 27 45 180
i686-linu Linux 2.4.2-2 0 5 9 26 33 188
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
i686-linu Linux 2.4.3-2 14 1 27 2 385 1 0.0K
i686-linu Linux 2.4.2-2 9 1 38 5 274 0 0.0K
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
i686-linu Linux 2.4.3-2 192 68 49 161 284 109 111 284 158
i686-linu Linux 2.4.2-2 93 30 15 82 140 42 42 140 53
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- --- ---- ---- -------- -------
i686-linu Linux 2.4.3-2 468 6 159 203
i686-linu Linux 2.4.2-2 634 4 133 230
----- End forwarded message -----
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Saturday 06 October 2001 16:06, Larry McVoy wrote:
> Has anyone out there seen similar problems with SIS630 motherboards?
> I know that we discussed this recently and people said that the graphics
> chip is eating memory bandwidth but I am not using it, it isn't even in
> SVGA mode, it's in text mode and screen blanked. I also tried setting
> the AGP mem down to 2MB and that made no difference.
>
> The reason I care is that I like these little cheap boxes called "book pcs"
> and the older model was BK810 and used the i810 chipset but the newer ones
> are BK630 and use the SIS630 chipset.
>
> The new ones suck on all the stuff I care about, compiles, BitKeeper
> regressions, just general software dev stuff.
>
> Any insight appreciated.
Run memtest86 to see what your memory bandwidth is.
You can also compare a tight loop ala bogomips with dirtying about as many
pages as you have cache (memtest86 can find this), with dirtying more pages
than you have cache in a big evil loop.
If this shows that your problem ISN'T memory bandwidth, then you'll have
learned something.
> The bummer is that the memory subsystem sucks doggy doo doo on the former.
> Is this a motherboard problem or do the newer celerons suck that bad on
> purpose?
All the celerons I know about have a 66 mhz front side bus speed. (Actually
there was a notebook version with a 100mhz fsb, but no desktop ones I know
of.) It's a totally artificial limitation to get you to buy a real Pentium
III. Intel crippling its low-end to avoid hurting the high end. (They let
AMD do that for them. :)
I've got links bookmarked about this somewhere. You can probably find it on
Tom's Hardware, or check google...
> Check out the bandwidth stuff, the second row should be faster but isn't:
Yup. Blame Intel's marketing department. This isn't a SIS problem, that's
pure Intel's crippling of the DeCeleron...
Rob
> Run memtest86 to see what your memory bandwidth is.
As far as I know, LMbench tells me what my memory bandwidth is just fine.
I don't care if it is telling me the limit (I know it isn't) I only need
to know relative speeds across platforms. It does that.
> Yup. Blame Intel's marketing department. This isn't a SIS problem, that's
> pure Intel's crippling of the DeCeleron...
I checked with a guy who works here, he used to work in Intel's processor
group on performance, and he tells me it isn't the processor, it's the
motherboard. Which jives nicely with the data.
I'm just hoping there is some SiS genius out there who will ask me
"Did you remember to turn off the go 3x slower mode in the BIOS?"
and I'll hang my head in shame and ask to be directed to that magic
BIOS switch.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy <[email protected]> writes:
> > Run memtest86 to see what your memory bandwidth is.
>
> As far as I know, LMbench tells me what my memory bandwidth is just fine.
> I don't care if it is telling me the limit (I know it isn't) I only need
> to know relative speeds across platforms. It does that.
Getting some real memory bandwidth data out of it would be interesting
for tracking the proble. By the time you get to pipe bandwidth the
fact you changed kernels could easily have an effect.
I think LMbench has the equivalent of streams in it so those would be useful.
> > Yup. Blame Intel's marketing department. This isn't a SIS problem, that's
> > pure Intel's crippling of the DeCeleron...
>
> I checked with a guy who works here, he used to work in Intel's processor
> group on performance, and he tells me it isn't the processor, it's the
> motherboard. Which jives nicely with the data.
The PII bus has 64 data pins and transfers data over them at the processor
FSB clock rate. So the processor maximums look something like:
66Mhz 528MB/s
100Mhz 800MB/s
133Mhz 1064MB/s
The data bus for SDRAM happens to follow the same rules, except the
address for the data also happens to go over the data bus, which gives
the processor a small advantage, in pure bandwidth. The biggest hit
SDRAM takes from protocol overhead is when either (a) you don't burst
or (b) you are doing back to back reads and writes. Writes go into
the SDRAM pipeline immediately but reads can't come out of the
pipeline immediately.
And you were getting at most 1/5th of the theoretical which looks
ugly. Not that I have seen the PII core get close to it's bus
potential except under special conditions.
> I'm just hoping there is some SiS genius out there who will ask me
>
> "Did you remember to turn off the go 3x slower mode in the BIOS?"
>
> and I'll hang my head in shame and ask to be directed to that magic
> BIOS switch.
Have you verified that the MTRR's are enabled on your memory? I
suppose there could also be a bad memory controller setting as well.
You might be able to look at the at the linuxBIOS code and see if
your BIOS is doing something different.
Eric
Hi,
> All the celerons I know about have a 66 mhz front side bus speed. (Actually
> there was a notebook version with a 100mhz fsb, but no desktop ones I know
> of.) It's a totally artificial limitation to get you to buy a real Pentium
> III. Intel crippling its low-end to avoid hurting the high end. (They let
> AMD do that for them. :)
Actually the latest celerons are 100MHz FSB.
// Stefan
On Mon, Oct 08, 2001 at 09:50:52PM +0200, Stefan Smietanowski wrote:
> Actually the latest celerons are 100MHz FSB.
And have half the L2 cache associativity of the older ones.
-ben