Printable View
Here is the 3.4 finale version: MemSet.exe
-Add support for Intel X38 chipsets.
-Add support for K10 DDR2 and DDR3.
-Replace Precharge to Precharge delay by Refresh period (tREF) timing,
and add Command Rate detection, on 965 and P35 chipsets.
-Add some timings for K8 DDR2.
Tell me if you find bug or problem...
And here is my new website: www.tweakers.fr
You can find update, some timings explications and others.
Note that it's a beginning, I'll improve it in time... :)
As usual, thank you Felix. :)
Yes, thanks a lot! :up:
Big THANKS Felix!!:up:
Felix: On MSI K9A2 Platinum (790FX) this new version doesn't pick up CPU speed/RAM speed correctly using an X2 or a Phenom. Everything else works fine. :)
-on A64 ddr2, memset read CPU speed and ram strap (theoricaly :D )
-on Phenom, NB strap and ram strap.
What is bad exactly?
NB strap and RAM strap only?
Basically it fails to pick up NB speed and RAM speed correctly.
So even when I bootup 1600MHz, 1700MHz, 1800MHz, 1900MHz, 2000MHz (etc) it will read 1800MHz NB speed and 800MHz DDR2 speed even if I bootup 1060MHz. :)
...one month later, :DQuote:
Originally Posted by KTE
a new version wich show CPU, RAM and NB reel frequency on Phenom: MemSet35beta.exe
Tell me if you find bug :)
I'll type it here quickly Felix.
You're picking up the RAM/NB speeds incorrectly because you're assuming a fixed 11.5x CPU divider on the 9600 BE. For 9500/9600 locked edition, I'm pretty sure this will work perfectly fine as long as you don't adjust multipliers (can do downwards) but for the unlocked edition, it doesn't once the multipliers are adjusted. So your app is always first looking to [CPU frequency/stock CPU divider = HT ref.] and then working out the RAM and NB speeds by multiplying by the multi's/dividers. :D
This is why at:
210 x 12.5 = 2625MHz CPU
210 x 9 = 1890MHz NB
210 3:8 = 560MHz RAM
..this beta gives:
CPU = 2622MHz (228 x 11.5)
NB = 2052MHz (228 x 9)
RAM = 608MHz (228/3 x 8)
HIH :)
You are probably right for 11.5 multi, I just send you an MP...
...a new version, using an other way for read frequency: memset35beta.exe
For Phenom on MSI RD790, it works perfectly Felix. :up:
I changed CPU FID, NB FID and HT ref. clocks here to show it.
http://img81.imageshack.us/img81/384...2000ts4.th.png
Thank you :)
http://www.abload.de/img/screenshotu9t.jpg
Works fine on the M3A with a 9500 and modified CPU/NB FID's ref HT and one core disabled.
I found that the reported frequencies jump up to ~3GHz and down to 1,7GHz if I run Memset on a system under load. Is this a know issue?
Check AOD, the frequencies are probably jumping around in that too if Memset picks it up. ;)Quote:
Originally Posted by justapost
Just verified it with cpu-z, aod and memset. If the load changes (starting stopping prime95) the frequency jumps down to 2GHz and up to 3GHz one or a few times then it goes back to normal reporting (2,3GHz +- 1MHz like CPU-Z).Quote:
Originally Posted by KTE
wow.. you have 3ghz spiking phenom.
I should try to bench it with Super Pi 16k :)Quote:
Originally Posted by tictac
yeah.. hopefully the multiplier limit will fused out. keep on hammering.. gl
Ahh nah I benchmark in cpu tristate no limit here.Quote:
Originally Posted by tictac
That is a screenshot of a 3,2GHz GP-9500 at stock volts.
http://www.abload.de/img/screenshot37kv.jpg
so in cpu p-state mode no multiplier limit? that is interesting finding. can we get a cpuz dump while it spiking high?
Uh, no i was just kidding. I think tristate is the undefined state when the p-state changes during whom all registers are updated.Quote:
Originally Posted by tictac
CPU-Z does not show those spikes, only memset does. Tried it with the M2A-VM and here the frequency fluctuates between 2,2GHz and 2,9GHz around each second.Quote:
Originally Posted by tictac
Huh? :confused:Quote:
Originally Posted by justapost
Wow. 586 1T. :wth:
That requires like 3.2VDIMM to even try at CAS5. You have massive spikes.
Do you get that right when opening the I/O app or idling as well?
My fluctuations have stopped. They only occur in masses if I open AOD, not at load->idle transitioning at all.
FELIX:
I admire the work you've put into Memset, but I do have one small comment that (AFAIK) applies to the controller of AM2 K8 CPUs exclusively:
I've noticed that in Memset 3.4 and 3.5, the Idle Cycle Limit is inaccessible whenever Dynamic Idle Cycle Counter is disabled. Through benchmark analysis and review of AMD's documents, I have found that relationship to be inconsistent with the way in which those two settings actually relate to each other.
While those settings really are related, disabling DICC does NOT make the controller ignore the ICL setting. The idle counters are still active and setting a different ICL number affects performance even when DICC is disabled, only, any given number would then be static (in other words, not modified based on other factors).
When DICC is enabled, the user selected ICL is loaded and then modified based on the Page Hit / Page Conflict history of a given address space.
Quote:
AMD publication # 32559, page 124
Dynamic Idle Cycle Counter Enable (DCC_EN)—Bit 5. When set to 1, indicates that each entry in
the page table dynamically adjusts the idle cycle limit based on Page Conflict/Page Miss (PC/PM) traffic.
Quote:
AMD publication # 32559, page 124
Idle Cycle Limit (ILD_lmt)—Bits 8–6. Specifies the number of MemCLKs before forcibly closing (precharging) an open page. If DCC_EN (Function 2, Offset A0h) has a value of 0, the static counters are loaded with the ILD_lmt and decremented each clock. If DCC_EN (Function 2, Offset 94h) has a value of 1, the dynamic counters are loaded with the ILD_lmt and modified as follows:
Increment—When a Page Miss (PM) page hits on an invalid entry in the Page Table. The presumption is that in the past, that page table entry was occupied by the very same page that has a Page Miss. Had the old page been kept open longer, it would have been a Page Hit. Increment the Idle Cycle Limit count to increase the probability of getting a future Page Hit.
Decrement—When a Page Conflict (PC) arrives and hits on an idle entry (obviously an open page). This Page Conflict can be avoided if the open page is closed earlier. Decrement the Idle Cycle Limit count to increase the probability of avoiding a future Page Conflict.
000b = 0 cycles
001b = 4 cycles
010b = 8 cycles
011b = 16 cycles
100b = 32 cycles
101b = 64 cycles
110b = 128 cycles
111b = 256 cycles
OK, you are right :)
I'll fix it today and update memset soon.
I probably mistake it for K10 datasheet, wich indicate: "This field is ignored if(dynPageCloseEn=0)"