View Full Version : Expected Core 2 Production
Attached is a little excel spreadsheet detailing expected Core 2 SMP production. It's a work in process, but will help answer some of the "How's this look?" questions while I finish it.
Updated using Sorin's Conroe VMware/Linux numbers.
Anyone have Allendale VMware/Linux Numbers?
William Hung
06-11-07, 11:07 AM
This is great ChasR! I'm sure this will prove VERY helpful!
drshivas
06-11-07, 05:03 PM
Nice work, sir.
For sure there will be anomolies as I noted in my post on testing results.
LandShark
06-11-07, 10:04 PM
very nice work and very close to real world ppd figures!! :thup:
I'm struggling with an anomoly now. The frame times from my vmware/linux E6600 (sig rig #1) are better than my native Linux E6600 @ 3.4 GHz on p2608 and p2609 by a lot. Does anyone else have data on vmware/Linux performance?
leelegend
06-12-07, 11:01 AM
i will have a look tonight for you.....my son's computer is a E6600 with that combo
lee
I'm struggling with an anomoly now. The frame times from my vmware/linux E6600 (sig rig #1) are better than my native Linux E6600 @ 3.4 GHz on p2608 and p2609 by a lot. Does anyone else have data on vmware/Linux performance?
I don't know how you wanted it formatted, but here are my times, according to FahMon's benchmark window (shows min/avg tpf).
Windows XP host system, VMWare running Ubuntu. E6600 3.4GHz (425MHz x 8). Box #1 in sig, but running 3.4GHz at the moment.
2605
Min - 11m11s, 2266.23 ppd
Avg - 11m12s, 2262.86 ppd
2608
Min - 11m38s, 1714.38 ppd
Avg - 11m41s, 1707.05 ppd
2609
Min - 11m32s, 1901.55 ppd
Avg - 11m32s, 1901.55 ppd
Updated using Sorin's numbers. Will post my FAHmon Conroe vmware/Linux numbers tonight after reviewing the logs for correctness.
I need some Allendale vmware/Linux numbers.
Sorin,
As an experiment, you should compare your rig at 400 x 8 to 425 x 8. From what i'm seeing, you have the same ram bandwidth at 400 x 8 on the 1066 strap as 450 x 8 on thw 1333 strap. At 425, you have less bandwith than you'd have at 400.
Sorin,
As an experiment, you should compare your rig at 400 x 8 to 425 x 8. From what i'm seeing, you have the same ram bandwidth at 400 x 8 on the 1066 strap as 450 x 8 on thw 1333 strap. At 425, you have less bandwith than you'd have at 400.
Sure. I'm only going to be able to get numbers for the current unit though, which is a 2605. I'll do it at 400 x 8 like you mention, and then I'll also do it at 400 x 9. What should I do, like 3-5 frames or something at each setting?
And I'll do this again as I get different units.
Edit: Oops, it's actually a 2605 right now. Not that it's that much different from 2604 though.
400 x 9 should provide the same ppd/GHz as 400 x 8. The P5B series loosens NB latency fairly dramatically on the 1333 strap, where you currently are at 425 x 8. I found in two instances OCing P5Bs that I made more ppd @ 400 x 8 than any other combo I could reach with the ram (800 MHz) on hand. I found that 400 x 8 was 2% faster than 413 x 8 at the same ram latency. Ram bandwidth at 400 x 8 is 10% higher than ram bandwith @ 401 x 8 as a result of lower NB latency on the 1066 strap. I'm not certain you'll see lower frame times on p2604 or p2605 but it should make a difference on p2608 and p2609, which seem to be available in higher quantaties ATM.
I'm going to get some Corsair Dominator and run a real test of bandwidth and latency on a Q6600 soon.
400 x 9 should provide the same ppd/GHz as 400 x 8. The P5B series loosens NB latency fairly dramatically on the 1333 strap, where you currently are at 425 x 8. I found in two instances OCing P5Bs that I made more ppd @ 400 x 8 than any other combo I could reach with the ram (800 MHz) on hand. I found that 400 x 8 was 2% faster than 413 x 8 at the same ram latency. Ram bandwidth at 400 x 8 is 10% higher than ram bandwith @ 401 x 8 as a result of lower NB latency on the 1066 strap. I'm not certain you'll see lower frame times on p2604 or p2605 but it should make a difference on p2608 and p2609, which seem to be available in higher quantaties ATM.
I'm going to get some Corsair Dominator and run a real test of bandwidth and latency on a Q6600 soon.
Currently testing at 400 x 8. I'm waiting for the tpf to balance out before posting the results. It's been about 7 frames so far and it looks like it's stabilized. Going to give it another frame or two to see.
It makes sense that 400 x 9 would be the same ppd/ghz, just higher overall ppd because of the higher frequency. But I want to try it anyways just to see the tpf :p
Here's my anomoly, vmware/Linux on Signature rig #1 appears to outperform native Linux on p2608 and p2609 on a E6600/P5B @ 378 x 8 (3.4 GHz), ram 1:1, 4-4-4-12
P2604
-- ChasR-Linux SMP --
Min. Time / Frame : 10mn 23s - 2440.83 ppd
Avg. Time / Frame : 10mn 48s - 2346.67 ppd
P2605
-- ChasR-Linux SMP --
Min. Time / Frame : 10mn 31s - 2409.89 ppd
Avg. Time / Frame : 10mn 51s - 2335.85 ppd
P2608
-- ChasR-Linux SMP --
Min. Time / Frame : 9mn 54s - 2014.55 ppd
Avg. Time / Frame : 10mn 43s - 1861.03 ppd
P2609
-- ChasR-Linux SMP --
Min. Time / Frame : 10mn 30s - 2088.69 ppd
Avg. Time / Frame : 10mn 32s - 2082.08 ppd
FAHmon reports
p2604 = 724 ppd/GHz
p2605 = 720 ppd/GHz
p2608 = 574 ppd/GHz
p2609 = 642 ppd/GHz
As a check, I calculated times from the log for one completed WU of each type, frame 1 through 100, no up/down load time and founf FAHmon reasonably close to correct.
p2604 = 704 ppd/GHz
p2605 = 704 ppd/GHz
P2608 = 572 ppd/Ghz
p2609 = 625 ppd/GHz
Native Linux numbers for the E6600/P5B @ 3.4 GHz:
p2604 = 720 ppd/GHz
p2605 = 720 ppd/GHz
P2608 = 512 ppd/Ghz
p2609 = 574 ppd/GHz
I'll work on this some more till I figure it out. It would be easy if I could test on the same machine.
drshivas
06-12-07, 09:37 PM
I need some Allendale vmware/Linux numbers.
Here you go- data for an Allendale - e6400@3.4Ghz on vmware/linux:
--2604--
Min. Time / Frame : 11mn 21s - 2232.95 ppd
Avg. Time / Frame : 11mn 21s - 2232.95 ppd
--2605--
Min. Time / Frame : 10mn 58s - 2311.00 ppd
Avg. Time / Frame : 11mn 07s - 2279.82 ppd
--2608--
Min. Time / Frame : 15mn 29s - 1288.09 ppd
Avg. Time / Frame : 15mn 55s - 1253.03 ppd
--2609--
Min. Time / Frame : 15mn 51s - 1383.67 ppd
Avg. Time / Frame : 16mn 58s - 1292.61 ppd
Okay, here's the results through 10 frames on 2605. 400 x 8 = 3.2GHz
Min. tpf = 11m27s
Avg. tpf = 11m33s
Comes out to 685.7143 ppd/GHz for 2194.286 ppd.
Compare that to 665.5462 ppd/GHz at 425 x 8 for 2262.857 ppd.
Interesting. The 425x8 is 200MHz faster than the 400x8, but it's only 68 ppd faster overall. The 400x8 is 20 ppd/GHz faster. 400MHz bus > 425MHz bus. That extra 200MHz faster overall speed barely compensates. 400MHz bus seems to make more sense since it's almost as fast, but you'll save a little bit of power and heat.
LandShark
06-12-07, 11:07 PM
Here's my log of E6600s from one machine runs either WinSMP or VMware/LinuxSMP + a NativeLinuxSMP machine. I've edit out a couple other machines from the log tho (like CoreDuo laptop, etc.)
Project : 2608
Core : Gromacs SMP
Frames : 100
Credit : 1385
-- SMP Box2 -- E6600@3.1ghz Linux
Min. Time / Frame : 14mn 09s - 1409.47 ppd
Avg. Time / Frame : 14mn 10s - 1407.81 ppd
-- //Linux-server/fah/ -- E6600@3.2ghz VMware/Linux
Min. Time / Frame : 12mn 35s - 1584.95 ppd
Avg. Time / Frame : 12mn 36s - 1582.86 ppd
-- //Linux-htpc/fah/ -- E6600@2.9ghz VMware/Linux
Min. Time / Frame : 13mn 05s - 1524.38 ppd
Avg. Time / Frame : 13mn 05s - 1524.38 ppd
-- WinSMP HTPC -- same machine as above but WindowsSMP
Min. Time / Frame : 12mn 48s - 1558.13 ppd
Avg. Time / Frame : 12mn 56s - 1542.06 ppd
-- WinSMP Bedroom -- E6450 @ 2.8ghz WindowsSMP
Min. Time / Frame : 12mn 29s - 1597.65 ppd
Avg. Time / Frame : 12mn 36s - 1582.86 ppd
-- WinSMP Boris -- E6400 @ 2.9ghz Vista WindowsSMP
Min. Time / Frame : 21mn 42s - 919.08 ppd
Avg. Time / Frame : 21mn 42s - 919.08 ppd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~]
same machine/spec as above
Project : 2609
Core : Gromacs SMP
Frames : 100
Credit : 1523
-- SMP Box2 --
Min. Time / Frame : 14mn 02s - 1562.79 ppd
Avg. Time / Frame : 14mn 02s - 1562.79 ppd
-- //Linux-server/fah/ --
Min. Time / Frame : 12mn 29s - 1756.84 ppd
Avg. Time / Frame : 12mn 29s - 1756.84 ppd
-- //Linux-htpc/fah/ --
Min. Time / Frame : 12mn 59s - 1689.18 ppd
Avg. Time / Frame : 13mn 04s - 1678.41 ppd
-- WinSMP HTPC --
Min. Time / Frame : 12mn 57s - 1693.53 ppd
Avg. Time / Frame : 13mn 02s - 1682.70 ppd
-- WinSMP Bedroom --
Min. Time / Frame : 12mn 27s - 1761.54 ppd
Avg. Time / Frame : 12mn 27s - 1761.54 ppd
-- WinSMP Boris --
Min. Time / Frame : 20mn 38s - 1062.90 ppd
Avg. Time / Frame : 20mn 38s - 1062.90 ppd
what other WU you'd like to see?
Now with 400 x 9, same 2605 project through 10 frames:
Min. tpf = 10m07s
Avg. tpf = 10m11s
Comes out to 691 ppd/GHz. I think I'm going to leave it at this frequency, so after a few days I can come back here with times for whole units.
The times per frame should be lower when I get some whole units in, so the ppd/GHz should be a little higher. That's with the 400 x 9. The 425 x 8 numbers are for whole units.
Thanks for all the info. I'm off to catch a plane to Denver. I'll sort it out on Friday.
Gary's numbers corroborate mine, vmware/Linux is faster than native Linux on p2608 and p2609 on some machines.
Gary's numbers corroborate mine, vmware/Linux is faster than native Linux on p2608 and p2609 on some machines.
Here are the 2609 numbers for me. This is at 400 x 9, which I'm going to keep it at now, instead of the 425 x 8. My early numbers were from the 425 x 8.
Project : 2609
Core : Gromacs SMP
Frames : 100
Credit : 1523
-- E6600 SMP --
Min. Time / Frame : 10mn 23s - 2112.15 ppd
Avg. Time / Frame : 10mn 28s - 2095.34 ppd
Comes out to 582 ppd/GHz.
scratches head ... curious results.
perhaps the virtual bios with vmware makes the linux vm run leaner so less cache contention?
The result on p2608 and p2609 is machine specific. The ram in the machine I got my vmware/Linux results was running @ 900 MHz 4-4-4-12 while the ram on the native Linux machine was running @ 756 MHz 4-4-4-12. The added performance resulting from the ram bandwidth on the VM/Linux machine more than makes up for the VM overhead, but only on bandwidth intensive WUs, 2608 and p2609. If I ran the test on the same or identical machines, Native Linux would produce more on all WUs. Sorin's results are the norm.
jmorgan
06-19-07, 09:27 AM
If you can use clockgen you can boot at 400fsb then with clockgen up the fsb and you will remain in the 800 strap which is the fastest.
For those who might not read the link I posted in the Q6600 testing results because they don't have a quad, here are the results that led me to this conclusion:
http://www.overclock.net/overclock-net-folding-home-team/199593-smp-folding-understanding-improving.html
Wouldn't it be the 1066 strap?
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.