Printable View
I have an Asus Commando + Windows XP64bit and the performance level setting doesn't seem to work! Default is 12, I set it to 6 and it doesn't make any difference in Everest Latency or Memory Read benchmark. Still stuck at ~8900MB and 59.3ns.
Any ideas? Running 490FSB 1:1 with 4x1GB sticks 4-4-4-15 timings.
Performance Level/Read Delay work with some P965 chipsets, but not all, and I don't know why. :confused:
Felix, are you trying to get Performance Level/Read Delay to work on P965 boards?
This is probly nothing, but noticed last night memset is reading mem speed differently to what it is. I don't notice this on XP, only on vista.
Minor error there.
Problem has been there for some time. But who cares :D
Hello,
I have a problem/question:
I am trying to tweak my memory timings, but I am not sure I understand why different text terms/labels are used in SPD section vs. the main section? It makes it hard to know which #s to tweak because for example Row to Row delay exist on SPD side but not in main window. Er, Im sure it exist but which one is it??
http://img299.imageshack.us/img299/7...8135552ye1.png
I am on a e6850, gigabyte p35 btw. vista 32.
It's cause I use name peculiar to each datasheet, so in spd documentation, is Row to Row Delay,
and in Intel doc. is Activate to Activate Delay;
-Write to Precharge delay = Cas# + 3 + Write Recovery time(spd)
-Write to Read (main) = Cas# + 3 + Write to Read(spd)
-Refresh Period (main) in clock = Refresh Rate(spd) in µs
->necron66: if you find a difference in memset reading frequency between cpu-z, cpu-z is right.
The best for know multiplier is to make a RDMSR, but my driver don't provide it.
Read what I said "its prolly nothing", and like I said I didn't notice it on XP, only since I use Vista, which is from hmmmm, the day I made that post.....Quote:
Originally Posted by Nosfer@tu
No worries mate :up:Quote:
Originally Posted by FELIX
felix, i'm currently looking into squeezing out my memory and found it interesting that on my ab9quadgt (p965) i get two different performance levels on the two dimms! for one dimm memset 3.5 beta reads 9 for the other it reads 10!Quote:
Originally Posted by FELIX
the only program i could get hold of by now, which allows me to check this settings is memtest. i modified the code to read all required timings off the mch!
anyway, as it's not clear to me from looking into the data sheet where to find some timings i ask you if you can help me here.
i'm looking for the following timings for the p965 chipset:
tPALL_RP (All Precharge to Activate): 252h [9:12]
Performance Level: 250h [2:5]
tWR (Write to Precharge Delay): 250h [6:10]
tRTP (Read to Precharge Delay): ???????
All Precharge to Refresh Delay: 25Bh [9:12]
Command Rate: ???????
this are the registers and bitpositions i used. could you pls check your code or documents to verify if my locations are correct?
thanks
tRTP (Read to Precharge Delay): 250h [5:2]
Performance Level: 248h [12-8]
Others is good.
For command rate, it's motherboard manufacturer dependent.
New beta version: MemSet35beta.exe
-Add support for NVidia NForce 650 Ultra & NForce 790 chipsets.
-Add some higher timings values for 965/P35/X38 chipsets.
Eventually, report me bugs... :)
eye am running 1T command rate & 3.5 beta says 2T
the last memset eye had 3.4 reported it correctly fyi
again thanks for the great tool FELIX !
Quote:
Originally Posted by FELIX
Is the Performance Level, register 248h, in any Intel documentation?
I've checked several and find no mention of register 248h....
Is there a dos version of a similar program?
FELIX - I'm trying to "translate" SPD, BIOS, and MemSet readings on a P35 as well. I fully understand why the terminology is used in MemSet and just wanted to make sure I understand a couple of items:Quote:
Originally Posted by LuckMan212I am trying to tweak my memory timings, but I am not sure I understand why different text terms/labels are used...
Quote:
Originally Posted by FELIX
Sorry if this is remedial or obvious, just like to be sure.
-Write to Precharge delay = tCL + 3 + tWR
-Write to Read Delayed = tCL + 3 + tWTR
Would that be accurate?
You mentioned (spd), but if tWR and tWTR is able to be set in BIOS that is still used instead of spd, correct?
MemSet
RAS# to CAS# Read Delay
RAS# to CAS# Write Delay
Both of these can typically be from a "RAS# to CAS# Delay (tRCD)" setting?
MemSet
Read to Write Delay (tRD_WR)
This is also referred to as tWR?
And tRC is not used at all as P35 MCH doesn't have or use it, correct?
Nice find :up:
No.Quote:
Originally Posted by JWilson
No.Quote:
Originally Posted by Spyrus
real equation is:Quote:
Originally Posted by Signal64
*Write to Precharge delay = WRITE Cas# Latency + (Burst Lengh / 2) + tWR
-Write# Cas Latency= Read Cas# Latency(tCL) - 1;
-Burst Lenght: Practicaly always = 8;
so:Write to Precharge delay = tCL - 1 + (8 / 2) + tWR = tCL + 3 + tWR
*Same for tWTR
these equation are indicate in Intel datasheet;Quote:
Originally Posted by Signal64
yes and no: some BIOS not show correctly these valuesQuote:
Originally Posted by Signal64
Yes.Quote:
Originally Posted by Signal64
No, but the best is you to read datasheet at page 135 and above... :)Quote:
Originally Posted by Signal64
Is there anyway to bypass that locked MCHBAR thingie without having to use that tool listed in first post as it's not too convenient to use as I don't understand addresses and such anyways to make it practical. Locked MCHBAR is the only thing that bothers me having switched to a Abit IP35 Pro. :rolleyes:
Compile the following ISA Option ROM source code using FASM. Inject the ISA Option ROM binary into your bios using cbrom182. Your MCHBAR will be unlocked at bootup unless you have a version of Windows that is locking it.
Code:use16 ; 16bit mode
ROM_SIZE_IN_BLOCK = 1 ; 1 means ROM size is 1 block (512 bytes)
ROM_SIZE_IN_BYTE = ROM_SIZE_IN_BLOCK * 512
ROMStart:
db 0x055, 0x0AA ; ROM Header 55,AA -> Bootable rom
db (ROMEnd - ROMStart)/512 ; ROM Size in 512byte
jmp MAIN ;<------------ jump to main (Bug Fixed)
db 0 ; checksum, to be filled in later
times (256)-($-$$) db 0
MAIN:
pushfd
push eax
push ecx
push dx
mov eax,080000048h ; (G)MCH Base Address Register
mov ebx,000000001h ; copy register data for MCHBAR Enable
mov dx,0CF8h ; set port address
out dx,eax ; send address through the port
mov dx,0CFCh ; set port data
in eax,dx ; fetch data
and eax,0FFFFFFF0h ; set data byte to zero
or eax,ebx ; increase data by new setting
out dx,eax ; send data through port data
pop dx
pop ecx
pop eax
popfd
retf ; return far to system bios routine
times (ROM_SIZE_IN_BYTE-$) db 0 ; use 00h as the padding bytes until we reach the ROM size
; The last byte (512th) will be the patch_byte for the checksum
; patch_byte is calculated and automagically inserted below
PREV_CHKSUM = 0
repeat $
load CHKSUM byte from %-1
CHKSUM = (PREV_CHKSUM + CHKSUM) mod 0x100
PREV_CHKSUM = CHKSUM
end repeat
store byte (0x100 - CHKSUM) at ($-1) ; store the patch_byte
ROMEnd:
...is it writing "MCHBAR Locked" on memset?Quote:
Originally Posted by RPGWiZaRD
If it is, your MCHBAR is locked in Bus 0 Dev 0 Fct 0 ,OffSet F4h, bit [0];
If bit[0]=1, your MCHBAR is locked, and is not possible to reset this bit under windows.
...Have you trying this code yourself?Quote:
Originally Posted by JWilson
I see that ,in this code,you enable the mchbar in Bus 0 Dev 0 Fct 0 OffSet 48h bit[0] but memset (or other soft wich need to access mchbar) always do it.
but on Abit IP35 Pro or some other board, MCHBAR is locked in write at OffSet F4h (read my post above about it). :)
It will be interesting to test your code with write 0 at OffSet F4h...
I use the code on Biostar P35D2-A7. The Intel P35 Data sheet shows register 48h, bit 0 as the MCHBAR enable bit. On the same page it does mention the F4h register, but executing the code from the bios, register 48h unlocks the MCHBAR on the Biostar P35 board. The F4h register may do the same thing after the bios code is finished executing.
http://www.lejabeach.com/pics4/P35-88.jpg
Bus 0 Dev 0 Fct 0 Offset 48h bit[0] Enable/Disable mchbar for Read and Write,
for all motherboard.
Bus 0 Dev 0 Fct 0 Offset F4h bit[0] Enable/Disable mchbar for Write only,
for some motherboard (IP35, foxcon...).
It's always possible to access Offset 48h bit[0] under Windows,
but it's not possible to write 0 (under Win) at Offset F4h after that it has been write at 1;
It's the reason that your code will be interesting...
Can we have a linux version?
Or the src code to compile it?