FSB and Multiplier Mix
With multiplier control available, there's another new 'wrinkle' to keep in mind when setting your processor clock - do you want to push the FSB as high as you can go or go for higher multiplier first? The rule of thumb is to raise the FSB first, since theoretically you're pushing more data from and to the processor. Is that still true for these processors? Let's take a closer look. We set the processor to run at 2.4 GHz, then ran test under two settings - first with 7 x 343 MHz and then with 6 x 400 MHz. For this test, we've included results with fixed memory timing as well, mostly to see the influence of timing in ideal conditions (synchronous mode).| 343 Mhz SPD | 343 Mhz | 400 Mhz | 400 Mhz | |
| Bandwidth | 5429.04 MB/s | 5466.46 MB/s | 5913.74 MB/s | 5913.74 MB/s |
| Latency | ||||
| 4 byte stride | 3 cycles | 3 cycles | 3 cycles | 3 cycles |
| 16 byte stride | 8 | 8 | 9 | 9 |
| 64 byte stride | 34 | 34 | 34 | 34 |
| 256 byte stride | 121 | 120 | 125 | 125 |
| 512 byte stride | 138 | 137 | 143 | 143 |
| Compared to 343 MHz SPD | Compared to 343 MHz SPD | Compared to 343 MHz | ||
| Bandwidth | 0.69% | 8.93% | 8.18% | |
| Latency | ||||
| 4 byte stride | 0 cycles | 0 cycles | 0 cycles | |
| 16 byte stride | 0 | 1 | 1 | |
| 64 byte stride | 0 | 0 | 0 | |
| 256 byte stride | -1 | 4 | 5 | |
| 512 byte stride | -1 | 5 | 6 |
And here are CPU-Z's memory timing dump.
343 MHz
400 MHz
Apparently, higher FSB is still the way to go. You still gain some bandwidth with higher FSBs, despite the slightly higher latencies we believe is 'inside' the chipset. Assuming everything else is constant (processor clock, memory timing), raising the FSB by 57 MHz in synchronous mode allows us to enjoy pretty much the same benefit from using asynchronous settings (say 343 MHz FSB and 1029 MHz memory). In fact, if we look back at the synchronous mode test results, we can see the increase from raising the FSB is actually higher, since the gain you get from asynchronous mode decreases with even higher FSBs.
Now, is that kind of gain (less than 10 percent) noticeable at all in real life? We've keept everything else pretty much constant (processor clock, memory timings) but we don't really know for sure. We think SuperPi test results can offer a glimpse of what the answer might be. We choose the 8 M digits option, which seems to be a pretty good compromise between speed and quality. Here are the results:
| 343 Mhz SPD | 343 Mhz | 400 Mhz | |
| Iterations | seconds | seconds | seconds |
| 1 | 13 | 13 | 13 |
| 2 | 25 | 25 | 24 |
| 3 | 37 | 37 | 36 |
| 4 | 49 | 49 | 47 |
| 5 | 61 | 61 | 59 |
| 6 | 73 | 73 | 70 |
| 7 | 85 | 85 | 82 |
| 8 | 96 | 97 | 93 |
| 9 | 108 | 108 | 105 |
| 10 | 120 | 120 | 116 |
| 11 | 132 | 132 | 128 |
| 12 | 144 | 144 | 139 |
| 13 | 156 | 156 | 151 |
| 14 | 168 | 168 | 162 |
| 15 | 180 | 180 | 174 |
| 16 | 191 | 192 | 185 |
| 17 | 203 | 204 | 197 |
| 18 | 215 | 215 | 208 |
| 19 | 227 | 227 | 219 |
| 20 | 238 | 239 | 231 |
| 21 | 250 | 250 | 241 |
| 22 | 260 | 260 | 251 |
The easiest way to spot the difference is to compare values in the last row - a 9 second difference between running synchronously at 400 MHz and 343 MHz. However, it is interesting to note that there are some very small differences between 343 MHz values. The SPD values are lower on the 16th and 17th iteration, in addition to the 20th. Rounding error perhaps? Or caused by that single TRAS cycle? Overall, it doesn't really matter really. That 9 second difference translates to a mere 3 percent performance increase. We're doubtful it will show up in real life conditions such as game benchmarks and gameplay testing sessions. But we will conduct game benchmarks just to be sure.
Now, let's look back at the asynchronous vs synchronous results. if under ideal conditions (synchronous mode) an 8 percent gain in bandwidth nets us only a 3 percent increase in performance, it's very likely we'll see the same, perhaps less with asynchronous settings. What if we raise the bar and use higher multipliers? A higher clocked processor is more likely to be bandwidth starved than a lower clocked one. Let's test that assumption. First - the FSB. This time we're going to run the processor slightly faster at 2.8 GHz - first with 7 x 400 MHz and then with 6 x 466 MHz. For brevity, we use the same memory timing on both runs.
| 400 Mhz | 466 Mhz | |
| Bandwidth | 6229.61 MB/s | 6783.84 MB/s |
| Latency | cycles |
cycles |
| 4 byte stride | 3 | 3 |
| 16 byte stride | 9 | 9 |
| 64 byte stride | 36 | 34 |
| 256 byte stride | 128 | 128 |
| 512 byte stride | 146 | 146 |
| Compared to 400 MHz | ||
| Bandwidth | 8.90% | |
| Latency | cycles | |
| 4 byte stride | 0 | |
| 16 byte stride | 0 | |
| 64 byte stride | -2 | |
| 256 byte stride | 0 | |
| 512 byte stride | 0 |
Interestingly enough, we're seeing practically the same amount of bandwidth increase as we did from 343 MHz to 400 MHz - around 8 to 9 percent. That seems to be the average gain for every 66 MHz increase in FSB. Important to note, this time we're seeing practically no difference in latency between the two settings. It's very likely chipset timings didn't change between these two settings, not like we saw earlier with 343 and 400 MHz. Now, let's take a look at SuperPi test results.
| 400 Mhz | 466 Mhz | |
| Iterations | seconds | seconds |
| 1 | 12 | 11 |
| 2 | 22 | 21 |
| 3 | 32 | 31 |
| 4 | 42 | 41 |
| 5 | 53 | 51 |
| 6 | 63 | 61 |
| 7 | 73 | 71 |
| 8 | 84 | 81 |
| 9 | 94 | 91 |
| 10 | 104 | 101 |
| 11 | 115 | 111 |
| 12 | 125 | 121 |
| 13 | 135 | 131 |
| 14 | 146 | 141 |
| 15 | 156 | 151 |
| 16 | 166 | 161 |
| 17 | 176 | 171 |
| 18 | 187 | 181 |
| 19 | 197 | 191 |
| 20 | 207 | 200 |
| 21 | 217 | 210 |
| 22 | 226 | 218 |
The 400 MHz jump we got from 2.4 GHz to 2.8 GHz allows us to shave off 25 to 34 seconds. However, that's not really what we're interested in. If you compare values in the last row, you'll see that we managed to shave off 8 seconds by using a slightly higher FSB (66 MHz higher). Still, the gain in performance is only about 3 percent - similar, if not the same to what we saw earlier with 343 and 400 MHz FSB.
Though it would have been much more fun to raise the FSB to 533 MHz, we were unable to get that far. Remember, we have not raise any voltage for any of the components and we're still using the processor's stock air cooling. Running at 533 MHz FSB means we have to compare results at 3.2 GHz, either by using 6 x 533 MHz or 7 x 457 MHz, but 3.2 GHz is not really attainable using stock air cooling. At 466 MHz, the Intel P965 chipset on our Gigabyte P965-DS3P sample was already running quite hot, it was not entirely rock stable without a much more effective cooling solution. At that setting we were unable to run stable long enough to conduct our game benchmarks.
[Previous Page]
[Go to top]
[Next Page]