FSB influence on Pentium dual core

[prox2far]

I have not been able to find any info on this subject, more info below.

I am currently running a E2160 at 2.4 GHZ ( 6 x 400 ) but I have not been able to find any information on the influence of this FSB speed.

Should I be able to get the same amount of speed from this chip if it runs it at 343 x 7, 300 x 8 or 267 x 9, given the memory still runs at 800 MHz with all the suggested settings. ( Impossible I know )

Does anybody know the actual impact the FSB has on these chips with a low amount of L2 cache.

I'm running Linux making it a bit difficult to test capable of showing the possible difference myself, making it an interesting question for people here in this forum.

 

[blackwidow_rsa]

It should only make a tiny difference. The only apps that like high fsb, are mathematical ones. Running a lower fsb will make your northbridge run cooler and less 'stressed'.

 

[blackwidow_rsa]

3rd time this happens. Double post

 

[prox2far]

LOL double posting is always a bitch

I could not help wondering since the L2 cache is so small, for an Intel CPU, the cpu has to exchange a lot of information with the memory and the FSB speed should influence this.

Talking about hot northbridge the damn this is running close to 50 C, while the CPU is below 40 C.

 

[Lupiron]

I would guess that it does, since your FSB is the memories pathways to junk. Providing your memory is running in sync with it.

Why not down load Saundra lite, and everest freeware version and test it for yourself? It would only take you less than 30 mins, and you'll have your answer.

As far as all other concerns go, as long as its not super hot, or anything else, might as well get the free gains, because there will be some.

Done it all before.

--Lupi

 

[prox2far]

Would love to, but I'm running Linux not a lot of servers host Sandra or Everest for Linux

The closest thing I have to a benchmark are some simple number crunching programs, and they show no difference, probably because the numbers being processed are not very large.

 

[Lupiron]

Damn, got a Super Pi version ported to Linux? The 32 Million test may work.

--Lupi

 

[prox2far]

Should be able to find Super PI for Linux and will try it soon.

 

[Lupiron]

Cool, just do the 32 mil test when you have 20 mins to spare with the lower FSB, then re do it with the higher one, and we'll see. Obviously if there is an increase, its worth keeping, provided your temps are in order!

--Lupi

 

[Evilonigiri]

I'd think it would take longer than 20min. 30mins sounds more like it.

 

[prox2far]

LOL

Do people wanna bet how much time it takes ( I already know )

The problem is that is does not only take 20 -30 minutes, it should take 20 - 30 minutes for each run and I have different FSB settings to test ( 6 x 400, 343 x 7, 300 x 8 and 267 x 9 )

Unfortunately I already now know that the results will not count as a proper FSB influence test, because there will not be any CPU cross talk etc.

 

[prox2far]

Oh well I just made 2 test runs.

One was performed with 6 x 400 and the other at 9 x 266 to find the two extremes of this problem.

6 x 400 MHz:
[cpp]
./super_pi 25
Version 2.0 of the super_pi for Linux OS
Fortran source program was translated into C program with version 19981204 of
f2c, then generated C source program was optimized manually.
pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
compilation.
------ Started super_pi run : man jun 9 17:40:24 CEST 2008
Start of PI calculation up to 33554432 decimal digits
End of initialization. Time= 15.429 Sec.
I= 1 L= 0 Time= 46.991 Sec.
I= 2 L= 0 Time= 53.467 Sec.
I= 3 L= 1 Time= 53.683 Sec.
I= 4 L= 2 Time= 54.127 Sec.
I= 5 L= 5 Time= 53.435 Sec.
I= 6 L= 10 Time= 53.591 Sec.
I= 7 L= 21 Time= 53.843 Sec.
I= 8 L= 43 Time= 53.503 Sec.
I= 9 L= 87 Time= 53.699 Sec.
I=10 L= 174 Time= 53.383 Sec.
I=11 L= 349 Time= 53.871 Sec.
I=12 L= 698 Time= 54.263 Sec.
I=13 L= 1396 Time= 54.119 Sec.
I=14 L= 2794 Time= 53.815 Sec.
I=15 L= 5588 Time= 53.527 Sec.
I=16 L= 11176 Time= 53.655 Sec.
I=17 L= 22353 Time= 53.955 Sec.
I=18 L= 44707 Time= 53.911 Sec.
I=19 L= 89415 Time= 53.283 Sec.
I=20 L= 178831 Time= 53.451 Sec.
I=21 L= 357662 Time= 53.187 Sec.
I=22 L= 715326 Time= 52.427 Sec.
I=23 L= 1430652 Time= 50.623 Sec.
I=24 L= 2861304 Time= 47.463 Sec.
End of main loop
End of calculation. Time= 1321.719 Sec.
End of data output. Time= 3.376 Sec.
Total calculation(I/O) time= 1325.095( 337.235) Sec.
------ Ended super_pi run : man jun 9 18:03:26 CEST 2008
[/cpp]

9 x 266 MHz:
[cpp]
./super_pi 25
Version 2.0 of the super_pi for Linux OS
Fortran source program was translated into C program with version 19981204 of
f2c, then generated C source program was optimized manually.
pgcc 3.2-3 with compile option of "-fast -tp px -Mbuiltin -Minline=size:1000 -Mnoframe -Mnobounds -Mcache_align -Mdalign -Mnoreentrant" was used for the
compilation.
------ Started super_pi run : man jun 9 18:07:56 CEST 2008
Start of PI calculation up to 33554432 decimal digits
End of initialization. Time= 16.173 Sec.
I= 1 L= 0 Time= 49.595 Sec.
I= 2 L= 0 Time= 56.300 Sec.
I= 3 L= 1 Time= 56.492 Sec.
I= 4 L= 2 Time= 56.420 Sec.
I= 5 L= 5 Time= 56.472 Sec.
I= 6 L= 10 Time= 56.516 Sec.
I= 7 L= 21 Time= 56.360 Sec.
I= 8 L= 43 Time= 56.464 Sec.
I= 9 L= 87 Time= 56.275 Sec.
I=10 L= 174 Time= 56.284 Sec.
I=11 L= 349 Time= 56.560 Sec.
I=12 L= 698 Time= 56.452 Sec.
I=13 L= 1396 Time= 56.664 Sec.
I=14 L= 2794 Time= 56.568 Sec.
I=15 L= 5588 Time= 56.484 Sec.
I=16 L= 11176 Time= 56.624 Sec.
I=17 L= 22353 Time= 56.587 Sec.
I=18 L= 44707 Time= 56.332 Sec.
I=19 L= 89415 Time= 56.259 Sec.
I=20 L= 178831 Time= 56.388 Sec.
I=21 L= 357662 Time= 55.871 Sec.
I=22 L= 715326 Time= 55.119 Sec.
I=23 L= 1430652 Time= 53.615 Sec.
I=24 L= 2861304 Time= 49.967 Sec.
End of main loop
End of calculation. Time= 1389.611 Sec.
End of data output. Time= 3.412 Sec.
Total calculation(I/O) time= 1393.023( 363.723) Sec.
------ Ended super_pi run : man jun 9 18:31:52 CEST 2008
[/cpp]

Clearly there is a difference, it is not big but it is still there. I would still love to see some benchmarks with a game or two, just to se the impact the FSB has on games.

 

[Lupiron]

yeah, its obviously there. I gained 28 seconds on a 20 min test from 333, to 400 FSB. So I already knew the results.

I guess its not a matter that its just s small gain, because all the small free extra speed the Overclocker is looking for does add up! So, if it takes a minute to set up in the Bios, and other than that, if all looks well with temps and stability, its time to look for the next free small bonus of speed!

I'd love to see some game benchies as well, but not from me yet! I have my paws full with my p5n-d and p5n72t. Crazy boards!

--Lupi

 

[prox2far]

Well I could not help wondering, since Intel cut back on FSB on the cheap models, and all reviews mention the low FSB but miss the impact of raising it.

I'm sure the difference is bigger in games than in SuperPI, but i don't have a chance of testing it and 2.4 GHz is plenty for me.

Just to show of, here's my OC results:

Pentium Dual Core 2160 @ 2.4 GHz ( 6 x 400MHz, 1.2 volt )
Sunbeam Silent Whisper with no fan
Geil value 800 MHz @ 4-4-4-12 ( unknows command rate probably 2T )
Gigabyte GA-P35C-DS3R
Antec Solo case ( the supplied fan is set at low speed )
Cheap 450 Watt 140 mm fan power supply ( slightly silent )

A link to a picture as proff:

http://xs.to/xs.php?h=xs128&d=08233&f=inside348.jpg


Is the p5n-d worth the trouble? I am considering it for a friend build, but I hear a lot of people complaining about the Nforce chipsets lately.

 

[Evilonigiri]

According to Anandtech, there is absolutely no difference between high fsb vs low fsb with their respective multiplier. They explained that in the past, the tRD timings weren't adjustable, thus higher fsb = better performance. Now days, the timings are adjustable, so there shouldn't be any difference, at least that's what Anandtech concluded.

You should see gains in synthetic memory tests (Super pi), but I doubt you'll see any gains in games.

 

[prox2far]

Would be nice if you could post a links to the article that has analysed this problem, because I can't find it. I was able to find a old 533 MHz vs. 800 Mhz FSB article with Pentium 4 processors showing healthy improvements with high FSB and "fast" memory.

http://www.anandtech.com/showdoc.aspx?i=1806&p=1

I think that I may try a converting job, to see if there is an impact when encoding video, since this should be rather CPU and memory intensive.

 

[lardy]

I think this is the article you want:

http://www.anandtech.com/mb/showdoc.aspx?i=3208

It's a must read. I had been testing this myself without knowing it by running x264 encode benchmarks at various multiplier/FSB/divider settings. By accident had discovered that setting the divider at constant FSB had an impact that seemed to be contrary to all the advice about high FSB and 1:1 divider settings as being the best. I didn't realize what the effect of the different straps or tRD were until I ran across this article. Once I realized what was going on it really helped me fine tune settings. I set my multiplier back to stock, then lowered FSB to achieve the same processor rate as I had before. Then upped the divider (or, more correctly, lowered the strap) to the memory stability limits, and finally reduced tRD to the stability limit. In the end I had a 3-5% faster system on real world benchs (the x264 encodes) and it was now doing it at lower Vcore settings because I had lowered the FSB.

This was on a P35 ASUS PK5-E board, Q6600, 2x2GB DDR2 800. I'd be very interested in your results if you try the same thing.