Flaky dividers???

I was doing some gaming the other day, and thought my game could benefit from a slight OC... well, I rarely ever max it (3.0Ghz), so I set it at 2.6ghz (11x240) and set my memory divider to 180 - which shouldve kept my DDR speed around 200mhz according to A64tweaker, but when I rebooted, CPUz shown my memory running at 215mhz... now this didnt cause a problem or anything, it just didnt match the speed that I had previously come up with to set it at. Do the memory dividers sometimes screw up and not end up with the correct speed?
I'm not at my pc now, so I'm going off memory here, so the settings I described might be off a mhz or two... but basically, why did my memory wind up running faster than it was supposed to? I notice this more with the 180 divider rather than the 166?
Thanx in advance!

I think you need to provide the exact numbers if you want anyone to get to the bottom of this. CPU/12 gives a memory speed of 220 MHz, and CPU/13 gives 203 MHz. There is no possible way you could get a memory speed of 215 MHz if you were truly running 11x240 = 2640 MHz.

As far as flaky dividers go, I have experienced incorrectly mapped dividers on my Asus A8V Deluxe board. This was a BIOS issue. Aside from this experience, dividers have always done what I expected.

Two things ... note that it's an 11:!2 ratio (183 MHz) not 180 MHz. Also, using a multiplier of 11.0x and an 11:12 ratio results in a 13 divider, not a 12 divider, and many CPUID programs do not take this into account. So in your case, the memory speed would be 240 * 11 / 13 = 203 MHz.

The 5 "exceptions" to the easy to to calculate ceil(...) thing are
1) 1:1 with a 4x multiplier results in a divider of 5
2) 11:12 ratio with multipliers 5.5x, 11.0x, 16.5x, and 22.0x result in a divider 1 higher than it should be.

No, a 180 or 183 setting (i.e., 11:12 ratio) in conjunction with an 11x CPU multiplier yields a CPU/12 divider. To avoid an argument over this I've already submitted a CPU-Z profile using those numbers:

http://valid.x86-secret.com/show_oc?id=118923

I'm not sure how you managed to get to CPU/13 ...

QuietIce said:

No, a 180 or 183 setting (i.e., 11:12 ratio) in conjunction with an 11x CPU multiplier yields a CPU/12 divider. To avoid an argument over this I've already submitted a CPU-Z profile using those numbers:

Click to expand...

Sorry, you're not going to avoid my argument. A true 180 setting (9:10 ratio), if it exists, yields a CPU/13 divider when CPU multi is 11. I'm pretty sure I've seen both 180 and 183 settings.

QuietIce said:

No, a 180 or 183 setting (i.e., 11:12 ratio) in conjunction with an 11x CPU multiplier yields a CPU/12 divider. To avoid an argument over this I've already submitted a CPU-Z profile using those numbers:

http://valid.x86-secret.com/show_oc?id=118923

I'm not sure how you managed to get to CPU/13 ...

Click to expand...

The question is more how did AMD engineers get to a 13 divider (the answer is that they forgot to take into account floating point roundoff error, but it's a long story).

CPU-Z is almost certainly wrong, since it has had this problem (the 11:12 ratio with multiplier divisible by 5.5) for as long as I can remember. Oskar Wu sat down with an oscilliscope and measured the RAM frequency (and hence the divider) for a complete range of settings. That's about as authoritive as you can be. You can see the results at:
http://www.xtremesystems.org/forums/showpost.php?p=539462&postcount=7
Additionally, the place that did the whole "half multipliers don't exist" thing (can't remember the name right now) did bandwidth measurements that followed exactly where they should for the 13 divider.

There is a slight chance that AMD corrected this mistake in the divider table in the rev E's, given that the dividers were undocumented. It works perfectly - excluding the 5 wierd points - using the ratios 1:1 (200 MHz), 11:12 (183 MHz), 5:6 (167 MHz), 3:4 (150 MHz), 5:7 (143 MHz), 2:3 (133 MHz), 5:8 (125 MHz), and 1:2 (100 MHz). I haven't seen any data to suggest this (or otherwise) but if you could do some unbuffered Sandra tests for the multipliers 10.0x to 12.0x (in half-integer steps) with the 11:12 ratio it hopefully should show up if they have.

edit: KillrBuckeye replied while I was posting ... the 11:12/183/180/whatever ratio must be at least 182.6 (21.0 multiplier 23.0 divider), so since it always has the memory speed below or equal to the desired speed, it can't be 9:10 or 180 MHz.

"If it exists" is the key here. But I'm not here to argue over a "true 180" setting even though I don't believe nF4 supports it regardless of the BIOS label.

emboss specifically mentioned an 11:12 ratio with an 11x CPU multiplier and I'm 100% sure it yields a CPU/12 divider.



emboss:
Oops - time overlap.

I'm always up for a good experiment. I've got plenty of SiSandra tests already recorded at 1:1 - get back to you in a few ...

OK - tests completed using SiSandra Lite 2007.5.10.98 bandwidth benchmarks:
246x11 @ 1:1 . 6691/6662
246x11 @11:12 6080/6048 (-9.1% / -9.2%)

251x11 @ 1:1 . 6835/6811
251x11 @11:12 6206/6180 (-9.2% / -9.3%)

The 11:12 ratio is labeled "183 MHz" in my BIOS and the RAM timings were unchanged - all 2.5-3-2-6-1T.

The expected results (all else being equal) for a CPU/12 divider should be -8.4%.
The expected results for a CPU/13 divider should be -15.4%.

BTW - Everest reports the same RAMclock (±0.2 MHz) as CPU-Z ...



Edit:
I missed the unbuffered part earlier - though there isn't much difference in the outcome:
246x11 @ 1:1 . 5525/5565
246x11 @11:12 5078/5054 (= -8.1% / -9.2%)

I also ran a test of my day-to-day settings:
225x12 @ 7:6 5528/5496 (CPU/11 = 245.45 MHz RAMclock)
246x11 @11:12 5078/5054 (= -8.1% / -8.0% and maybe another -0.2% for the speed difference)

emboss said:

the 11:12/183/180/whatever ratio must be at least 182.6 (21.0 multiplier 23.0 divider), so since it always has the memory speed below or equal to the desired speed, it can't be 9:10 or 180 MHz.

Click to expand...

I believe what you are saying since you certainly know more about this than me, but I don't understand your explanation here. Why is not possible to have a 9:10 (180/200) divider? In your explanation, what is "it", where do 21.0 and 23.0 come from, and what do you mean by "desired speed"?

QuietIce said:

OK - tests completed using SiSandra Lite 2007.5.10.98 bandwidth benchmarks:
246x11 @ 1:1 . 6691/6662
246x11 @11:12 6080/6048 (-9.1% / -9.2%)

251x11 @ 1:1 . 6835/6811
251x11 @11:12 6206/6180 (-9.2% / -9.3%)

The 11:12 ratio is labeled "183 MHz" in my BIOS and the RAM timings were unchanged - all 2.5-3-2-6-1T.

The expected results (all else being equal) for a CPU/12 divider should be -8.4%.
The expected results for a CPU/13 divider should be -15.4%.

Click to expand...

This is approximately consistant with a 13 divider, since the Sandra memory benchmark scales sublinearly with the ratio (ie: if it should drop by 15.4%, then you'll see a less than 15.4% drop). However, it's much easier and more conclusive if you do a multiplier scan. Set your system clock to 200 MHz, ratio to 11:12, and step the multiplier from 10.0x to 12.0x in half integer steps. Take a memory bandwidth reading at each step (the memory bandwidth number from memtest86 works as well IIRC, and is quicker than going into Windows, loading Sandra, etc).

QuietIce said:

BTW - Everest reports the same RAMclock (±0.2 MHz) as CPU-Z ...

Click to expand...

Yeah, it's a fairly common bug. Ironically, this particular bug didn't used to show up as much, since the "standard" way of coding the divisor calculation is the ceil(...) thing, which DOES return a 13 divisor (but stuffs up in other places, depending on how exactly you code it and your compiler compiles it). This is almost certainly how AMD came up with the "wrong" numbers. Once people became aware of the problems with the floating point approach, they switched to an integer based approach which does the MATHS correctly, but in most cases they forgot to account for the 5 "wrong" points.

KillrBuckeye said:

I believe what you are saying since you certainly know more about this than me, but I don't understand your explanation here. Why is not possible to have a 9:10 (180/200) divider?

Click to expand...

Because there aren't enough bits Prior to rev E, the memory ratio was selected through 3 bits. This means that there are only 8 possible ratios, determined to have the values I gave before. With rev E and later chips it gets more complex (you have odd divisor correct at the high range for >1:1 ratios) but the low range should have remained the same.

The reason why the second-highest ratio (11:12 or whatever) cannot be set to 180MHz is that the ratios operate by setting a maximum frequency. They tell the CPU "do not operate the RAM any faster than {ratio} to the system clock". So an 11:12 ratio would mean that the RAM must not operate any faster than system_clock*11/12, which for the default system clock of 200 MHz comes out to be 183.333333... MHz. Therefore, the CPU must choose the divisor that gives the highest RAM frequency less than this value.

With a bit of messing around, you can find that the ratio associated with the second highest ratio must be in the range 0.913043478 to 0.916666667, which at a 200 MHz system clock gives 182.609 MHz to 183.333 MHz. Now, the interesting thing is that it must be strictly below this upper value which corresponds to an 11:12 ratio exactly. Which is why using a 11:12 ratio doesn't work correctly.

The two solutions are to use a 183.000 MHz speed (corresponding to a 183/200 ratio I suppose) or to use 11:12 (which fits in, as all the other divisors except the 143 MHz one are divisible by 1/12) and code in the exceptions.

KillrBuckeye said:

In your explanation, what is "it", where do 21.0 and 23.0 come from, and what do you mean by "desired speed"?

Click to expand...

The 21 and 23 come from Oskar's table, and the "desired speed" is the ideal speed you'd get by multiplying the system clock by the ratio (so would be 183 MHz for an 11:12 ratio, etc etc).

emboss said:

This is approximately consistant with a 13 divider, since the Sandra memory benchmark scales sublinearly with the ratio (ie: if it should drop by 15.4%, then you'll see a less than 15.4% drop). However, it's much easier and more conclusive if you do a multiplier scan.

Click to expand...

Let's just stick with the CPU settings we started with, OK? We can easily change the RAM ratio and get BM results. Perfect or not they're certainly close enough to figure out what divider is being used.

With that in mind, we now have a setting of 166 in the BIOS. Starting with our baseline CPU of 246x11 we end up with a CPU/14 divider. This holds true whether we use 166 MHz or a 5:6 ratio (166.666666666666 ...). We should expect a result of about -21.4%:

246x11 @ 5:6 buffered .. 5245/5212 (- 21.6%/ -21.8%)
246x11 @ 5:6 unbuffered 4420/4411 (- 20.0%/ -20.7%)

Are we now in dispute over the resultant CPU divider with a 166 (5:6) setting or are we still blaming SiSandra for "sublinear" scaling ...?

QuietIce said:

Let's just stick with the CPU settings we started with, OK? We can easily change the RAM ratio and get BM results. Perfect or not they're certainly close enough to figure out what divider is being used.

Click to expand...

I'm trying to help you here ... The result you are claiming is at odds with precise measurements done by a highly respected motherboard designer, and numerous bandwidth tests done previously to determine this. They have all, without exception (at least the one's I've seen), shown that a 13 divider is being used. I should note that I haven't been actively chasing this topic for the last year so it's possible I may have missed results on more recent chips. While it's not impossible that AMD have changed the divider table on later rev chips (especially as it was marked as reserved), I'd like to see something more conclusive than just two points, and a plot of memory bandwidth with respect to multiplier does this very cleanly - if a 12 divider is being used, you will see a big peak at 11x, and if a 13 divider is being used you will see a big trough at 11x. Identically at 5.5x, 16.5x, and 22.0x multipliers as well.

If you give me a day or two I can cook up a program that will walk through the multipliers and do latency and bandwidth measurements at each point. Would require a floppy disk (ideally) but making a bootable CD would work too as long as you don't mind copying numbers off the screen to paper. Being pre-boot means that nothing funky can be happening with dual-core-ness or wierd OS stuff and will give very accurate numbers.

Otherwise, it doesn't take too long to change the multiplier and boot up memtest86 a few times, and I would be very interested in having solid proof that the divider they are using has been changed. At which point it becomes and interesting question of WHEN it was changed

QuietIce said:

With that in mind, we now have a setting of 166 in the BIOS. Starting with our baseline CPU of 246x11 we end up with a CPU/14 divider. This holds true whether we use 166 MHz or a 5:6 ratio (166.666666666666 ...). We should expect a result of about -21.4%:

246x11 @ 5:6 buffered .. 5245/5212 (- 21.6%/ -21.8%)
246x11 @ 5:6 unbuffered 4420/4411 (- 20.0%/ -20.7%)

Are we now in dispute over the resultant CPU divider with a 166 (5:6) setting or are we still blaming SiSandra for "sublinear" scaling ...?

Click to expand...

While the sublinear scaling comment still holds - it should not be possible to get a 9.2% decrease in bandwidth from a 8.4% decrease in memory speed - it's much more interesting to line the three things up side by side by ratio. First of all, if a 13 divisor was being used:
246.00 = 6691
208.15 = 6080
193.29 = 5245
And then if a 12 divisor was being used:
246.00 = 6691
225.50 = 6080
193.29 = 5245
The 11:12 ratio memory bandwidth sits somewhat in the middle (slightly closer to 1:1) of the other two, which fits the predicted speeds much better if a 12 divisor was being used.

That said, I'd still really love to see the multiplier-to-bandwidth measurements as these show any wierd stuff that's going on in the background. But at this point, it does look like AMD have, at some point, changed/fixed the divisor table for the 11:12 ratio. So if there's anyone else out there with an hour to kill, I'd be very interested to see bandwidth-vs-multiplier results for you as well (ideally with date codes and OPN steppings, though CPUID steppings would probably be good enough).

emboss said:

... (ideally with date codes and OPN steppings, though CPUID steppings would probably be good enough).

Click to expand...

OSA180DAA6CD
Fam:F Mod:3 Step:2
ExFam:F ExMod:23 Rev:JH9-E6
CCBWE 0541 RPMW