• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Anybody see new Rev E specific dividers?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

Super Nade

† SU(3) Moderator  †
Joined
Aug 30, 2004
Location
Santa Barbara, CA
Hello Folks!
Good to be back after a long hiatus :).

I was reading THIS
article on xbitlabs. They mentioned the Rev E supporting two new up counting dividers viz.,7/6 and 5/4. Have any of you taken advantage of it? Is the BIOS support there?

How come nobody is interested in this? I would be curious to know if there is an improvement in stability (the linked article makes no mention of stability and has a lot of fluff one has to wade through).
 
BACK

From what I have seen these seems to be worse when it comes to OC'ing, that's why I didn't buy one since they stopped selling 5/16&5/17's. But I think that there are couple of people that posted on the forums that got these latest revisions and it wasn't anything special :shrug:
 
Mate,
Thanks for the welcome :)

I was under the impression that all Rev E cores had up-counting dividers programmed into them. The ball is in the Mobo makers court, right? AFAIK, none of the DFI-NF4 BIOSes support these new dividers. Why is that?
 
Super Nade said:
Mate,
Thanks for the welcome :)

I was under the impression that all Rev E cores had up-counting dividers programmed into them. The ball is in the Mobo makers court, right? AFAIK, none of the DFI-NF4 BIOSes support these new dividers. Why is that?

Are you referring to DFI official (6/18 latest) cause I'm sure that there are BETA's out there that support them but I didn't have time to fish for them myself.
 
What is surprising is that I have heard no chatter about this? I don't think OPB's or Hellfire's BIOS'es support that.
 
I updated the memory divider table in the following post a while back to account for the 4/3, 5/4, 7/6, 13/12 memory_HTT_ratio for some of the new bioses.

memory_HTT_ratio 4/3, aka max_memory_clock 266 MHz wrt to 200 MHz
memory_HTT_ratio 5/4, aka max_memory_clock 250 MHz wrt to 200 MHz
memory_HTT_ratio 7/6, aka max_memory_clock 233 MHz wrt to 200 MHz
memory_HTT_ratio 13/12, aka max_memory_clock 217 MHz wrt to 200 MHz

Overclocking setting for various bus frequencies (post 8)
 
Last edited:
I've noticed my board in the latest bios update gets some wierdo dividers

233 and 250?
 
Are you sure you're using a Rev E CPU?

The latest BIOS supports the new dividers for the Rev E A64s such that you can keep your CPU at stock and run higher DDR speeds like DDR500 (the 250 setting) if you feel like it.
 
I know 7/2 bios supports it. I don't remember whether they are on the 6/23. From what I remember there was no difference/loss in performance using the dividers.
 
HousERaT said:
I know 7/2 bios supports it. I don't remember whether they are on the 6/23. From what I remember there was no difference/loss in performance using the dividers.

I'm not going to be using any 7-x BIOS! I think deception's CPU was killed by the VCore bug.

hitech, I saw your updated post. I was just wondering if any BIOS supports it and if so what are the consequences in the relam of stability,VCore required etc..
 
Super Nade, welcome back.

I flashed the 7/2 BIOS a minute ago - I just finished getting the board back into a functional state (These DFI NF4 boards love to "roll over", and "play dead" after a simple BIOS flash). The results are interesting.

DFI quality again...

The 233 MHz and 250 MHz "dividers" (or ratios, whatever you want to call them) are in this BIOS, as selectable options. However, neither works (for me). I have a Revision 'E' die processor, a San Diego 3700+.

The 233 MHz ratio behaves exactly as the 200 MHz (1:1) ratio does - memory speed and HTT are synchronised. The 250 MHz ratio put my memory to 133 MHz, with the HTT set to 200 MHz.

EDIT: CPU-Z, memtest86, and A64-info all seem to incorrectly detect memory frequency, when operating with the 7:6 or 5:4 ratios - while CPU-Z/memtest86/A64-info detects a 200 MHz/133 MHz frequency, it is not neccessarily correct, or anywhere near accurate


Neither ratio sets my memory to a higher frequency than my HTT. Perhaps memtest86+/CPU-Z do not correctly detect these ratios? Either that, or they are bogus BIOS options. It would be interesting to see if the 233 MHz ratio (which behaves as the 200 MHz 1:1 ratio) behaves differently from a stability standpoint, that the 200 MHz 1:1 ratio we already have.

Here's a CPU-Z shot running with the 250 MHz ratio, with my HTT set to 200MHz - it says CPU/15 for some reason.
 

Attachments

  • 250MHzratio.JPG
    250MHzratio.JPG
    37.6 KB · Views: 448
Last edited:
felinusz said:
Super Nade, welcome back.

I flashed the 7/2 BIOS a minute ago - I just finished getting the board back into a functional state (These DFI NF4 boards love to "roll over", and "play dead" after a simple BIOS flash - it's really cute). The results are interesting.



The 233 MHz and 250 MHz "dividers" (or ratios, whatever you want to call them) are in this BIOS, as selectable options. However, neither works (for me). I have a Revision 'E' die processor, a San Diego 3700+.

The 233 MHz ratio behaves exactly as the 200 MHz (1:1) ratio does - memory speed and HTT are synchronised. The 250 MHz ratio put my memory to 133 MHz, with the HTT set to 200 MHz.

Neither ratio sets my memory to a higher frequency than my HTT. Perhaps memtest86+/CPU-Z do not correctly detect these ratios? Either that, or they are bogus BIOS options. It would be interesting to see if the 233 MHz ratio (which behaves as the 200 MHz 1:1 ratio) behaves differently from a stability standpoint, that the 200 MHz 1:1 ratio we already have.

Here's a CPU-Z shot running with the 250 MHz ratio, with my HTT set to 200MHz - it says CPU/15 for some reason.

Thanks for the welcome :)

You better be careful, chief. I've seen a few complaints regarding 7-x BIOS'es. The VCore bug is still very much present. You may end up with a dead CPU. deception killed his 3000+ Venice.

Curiously, I'm not having any problems with my BIOS or board. I spend a good 30 mins flashing the CMOS. However, I suspect the CMOS chip may be flaky. I have noticed that if I change RAM modules or go back 512 x 2 from 512 x 4 (exact same PDP modules), I HAVE TO reset the CMOS for atleast 30 min. Otherwise, I can't OC at all!

Maybe bandwidth benchies would give us an idea. Looks like CPUz spits out garbage when it encounters unknown parameters.
 
O.K., this is very interesting.

Speculation here, but I see a few possiblities:

~ The 7/6 and 5/4 ratios are bogus BIOS settings (yet, like CAS 1.5 and reserved tRAS values, they do change *something* as seen in the results below)
~ The 7/6 and 5/4 ratios work, but are highly innefficient
~ The 7/6 and 5/4 ratios don't change memory speed, but alter some other paramater, which affects performance drastically?


At this point, we can be fairly sure that CPU-Z, memtest86+, and Sandra are all detecting incorrect speeds and efficiencies.

With the 233MHz/7:6 ratio, memtest86 detects memory speed as it should be with the 200MHz/1:1 ratio, and CPU-Z gives no values. With the 250MHz/5:4 ratio, memtest86 detects memory speed as it should be with the 133 MHz ratio, and CPU-Z does the same.


Anyhow, I ran some quick bandwidth tests at a few settings. What turned up was very peculiar, and very interesting.

"Ratio" used, HTT x CPUX, actual HTT and memory frequencies - Sandra INT/FLOAT (MB/s)

200 MHz/1:1, 200x10, HTT=200, Memory=200 - 5329/5261
233 MHz/7:6, 200x10, HTT=200, Memory=233? - 5552/5474
250 MHz/5:4, 200x10, HTT=200, Memory=250? - 5607/5534
200 MHz/1:1, 233x10, HTT=233, Memory=233 - 6217/6137
200 MHz/1:1, 250x10, HTT-250, Memory=250 - 6683/6589

As you can see, these ratios are either horribly innefficient, or aren't actually setting memory frequency as they should be. The results with a "real" 233 MHz or 250 MHz memory frequency are far and above better than the results achieved with the ratios.


To summarize:

Cool. Something peculiar is going on here.

This is of further interest:
http://www.xtremesystems.org/forums/showthread.php?t=67045&highlight=7/6
http://www.xtremesystems.org/forums/showpost.php?p=919612&postcount=437


Here are pictures of all the results, with footnotes explaining points of importance. This is an easy "do-it-at-home" experiment, anyone with a DFI nFarce4 board, a Rev 'E' die chip, and a newer (7/x) BIOS should be able to replicate these results.

The 7/x BIOS is completely safe so long as you do not use the VIDx123% (or higher) option, and so long as you do not change the CPUVID and VID%+ values at the same time (instead, change one, restart, then change the other). Rather serious BIOS bug really.
 

Attachments

  • 200X10-20011.JPG
    200X10-20011.JPG
    61.5 KB · Views: 234
  • 200X10-23376.JPG
    200X10-23376.JPG
    84.8 KB · Views: 246
  • 200X10-25054.JPG
    200X10-25054.JPG
    88.1 KB · Views: 230
  • 233X10-20011.JPG
    233X10-20011.JPG
    85 KB · Views: 242
  • 250X10-20011.JPG
    250X10-20011.JPG
    88.4 KB · Views: 243
Last edited:
astaris, HERE

DDR 433 -> Ram_Ratio = 13/12
DDR 466 -> Ram_Ratio = 7/6
DDR 500 -> Ram_Ratio = 5/4
DDR 533 -> Ram_Ratio = 4/3

Ram_Frequency=HTT_Clock*CPU_Multiplier/(ceil(CPU_Multiplier/Ram_Ratio ))

The next table shows the real memory frequency with HTT_Clock=200 Mhz.
Cpu_Multi---------DDR433----------DDR466---------DDR500---------DDR533

9------------------200--------------225--------------225-----------257
9,5----------------211--------------211--------------237-----------237
10-----------------200--------------222--------------250-----------250
10,5---------------210--------------233--------------233-----------262
11-----------------200--------------220--------------244-----------244
11,5---------------209--------------230--------------230-----------255
12-----------------200--------------218--------------240-----------266
12,5---------------208--------------227--------------250-----------250
13-----------------216--------------216--------------236-----------260
13,5---------------207--------------225--------------245-----------245
14-----------------215--------------233--------------233-----------254
14,5---------------207--------------223--------------241-----------263
15-----------------214--------------230--------------250-----------250
15,5---------------206--------------221--------------238-----------258
16-----------------213--------------228--------------246-----------266
astaris, HERE

In Athlon 64 a XXX Ram divider set the memory controller divider to an integer value that ensures that the RAM Frequency is lower than the XXX value when HTT_Clock = 200 Mhz. This behaviour produces, for some values of the cpu-multi and of the Ram divider (the one you set in the bios), real memory frequency that can be substantially lower than the Ram frequency you entered in bios.

astaris, HERE

Ceil is a math function that returns the next highest integer value, i.e. ceil (8.7) =9.
I think that CPU-Z would not report the real memory speed because the 433 and lower dividers are reserved values for MemClock register field of the Athlon 64.

Related? Someone care to cross-check this information against AMD's tech docs?
 
Last edited:
felinusz said:
O.K., this is very interesting.

Speculation here, but I see a few possiblities:

~ The 7/6 and 5/4 ratios are bogus BIOS settings (yet, like CAS 1.5 and reserved tRAS values, they do change *something* as seen in the results below)
~ The 7/6 and 5/4 ratios work, but are highly innefficient
~ The 7/6 and 5/4 ratios don't change memory speed, but alter some other paramater, which affects performance drastically?


CPU-Z, memtest86+, and Sandra are all detecting incorrect speeds and efficiencies - it is impossible for us to deduce which of the above is the case.

With the 233MHz/7:6 ratio, memtest86 detects memory speed as it should be with the 200MHz/1:1 ratio, and CPU-Z gives no values. With the 250MHz/5:4 ratio, memtest86 detects memory speed as it should be with the 133 MHz ratio, and CPU-Z does the same.


Anyhow, I ran some quick bandwidth tests at a few settings. What turned up was very peculiar, and very interesting.

"Ratio" used, HTT x CPUX, actual HTT and memory frequencies - Sandra INT/FLOAT (MB/s)

200 MHz/1:1, 200x10, HTT=200, Memory=200 - 5329/5261
233 MHz/7:6, 200x10, HTT=200, Memory=233? - 5552/5474
250 MHz/5:4, 200x10, HTT=200, Memory=250? - 5607/5534
200 MHz/1:1, 233x10, HTT=233, Memory=233 - 6217/6137
200 MHz/1:1, 250x10, HTT-250, Memory=250 - 6683/6589

As you can see, these ratios are either horribly innefficient, or aren't actually setting memory frequency as they should be. The results with a "real" 233 MHz or 250 MHz memory frequency are far and above better than the results achieved with the ratios.
Yes, the ratios are inefficient, but since neither diagnostic bench detects the right DRAM frequency, how accurate are these results? What would a SuperPi time test (say 1M) yeild? If I'm right, these diagnostic benchmarks make explicit use of the detected/calculated DRAM frequencies along with the R/W timings. SuperPi does not make explicit use of the DRAM Freq, right? Could you run a 1M test followed by a 32M to check for stability variations?
I cannot use the 7-x BIOS because my CPU's sweet spot includes the buggy VID value.

To summarize:

Cool. Something peculiar is going on here.
:)

Mate,

Sorry for the delayed response. I was pouring over the AMD tech docs to see if there is an explicit mention of the new dividers. The updated document here (Pg 177 of 394):http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
clearly states that the maximum DRAM speed officially supported is DDR400. There is no mention of DDR533 etc. So this could be an undocumented feature. xbitlabs make no mention of how they obtained their results. No diagnostic software was mentioned, nor did they tell us how they arrived with those bandwidth numbers.

On page 113, the DRAM Memclk Frequency (Memclk) bits have been mentioned. It says
AMD Tech Docs Pg 113 said:
DRAM MEMCLK Frequency (MemClk)—Bits 22–20:
Specifies the DRAM MEMCLK frequency in MHz. It is possible to program this field for a higher frequency than the maximum allowed by the processor. Refer to the processor data sheet for the maximum operating frequency allowed for a given processor implementation.
000b = 100 MHz
001b = reserved
010b = 133 MHz
011b = reserved
100b = reserved

101b = 166 MHz
110b = reserved
111b = 200 MHz

Do the reserved values have to take numbers < 200MHz or can they be anything? If they can be anything, the answer could be, CPUz etc are confused by utilization of these reserved values.


Check this out on page 164 under Northbridge Capabilities Register:
Maximum DRAM Frequency (DramFreq)—Bits 6–5. Indicates the maximum DRAM frequency
supported.
00b = No limit
01b = 166 MHz
10b = 133 MHz
11b = 100 MHz

What does the 00b bit mean? Does it mean that in theory, one can clock as high as the RAM would go? This may have something to do wit the problem at hand.

Forgive my rather incoherent post, I'm struggling to explain this :)

**
I will reply to the second post after scouring the tech docs :)
 
Last edited:
Back