Jump to content

graysky

Members
  • Content Count

    104
  • Joined

  • Last visited

Everything posted by graysky

  1. Updated the tables with another 45 nm chip: the QX9650 -- both at stock levels and @ overclocked to 4.2 GHz! With it, and the others (Xeon E5330 (Dual board), Q9550, and Q9350) there is now data on 4 different 45 nm chips. One thing that I found striking about these new chips is that they are only marginally faster than their 65 nm counterparts when encoding x264 (about 5-6 % faster with all other factors being equal or close to equal). Have a look at the general trends table for the Kentsfield vs. Yorkfield comparison at the official host.
  2. Temp1: 39 Temp2: 15 Temp3: -2 HD0: 31 Core0: 23 Core1: 24 Looks good to me... I would just switch off Temp2 and Temp3. I'm assuming that Temp1 is your NB temp. BTW, you can rename them in the software, e.g. Temp1 rename to NB Temp. What does CT 0.95.4 report?
  3. Thanks for kind words. You might wanna try speedfan also (I'd recommend using the latest beta which has MANY temp/CPU detection problems fixed) to see how it compares to the coretemp readings. Also try posting a screenshot of 0.95.4 at the coretemp forums to see what the folks over there have to say about your temps. Although when I tried this, I saw no difference, try switching the state of your PECI in your BIOS and see if that has an effect... Do let us know
  4. Just updated the guide to version 1.3 which contains new info, fixes, clean-ups, etc. Enjoy!
  5. Updated the Intel table. It now contains several Yorkfield ES chips including: Xeon E5330 (Dual board) Q9550 Q9350
  6. Common sense tell you that higher memory bandwidth should mean faster results, right? I set out to put this thought to the test looking at just two different memory dividers on my o/c'ed Q6600 system. At a FSB of 333 MHz, the slowest and fastest dividers I could run are: 1:1 a.k.a. PC5300 (667 MHz) 3:5 a.k.a. PC8888 (1,111 MHz) Just for reference, as they relate to DDR2 memory: PC4300=533 MHz PC5300=667 MHz PC6400=800 MHz PC7100=900 MHz PC8000=1,000 MHz PC8500=1,066 MHz PC8888=1,111 MHz PC10600=1,333 MHz The highest divider is 1:2 aka PC10600 (1,333 MHz) and it just wasn't stable with my hardware @ 333 MHz. All other BIOS settings were held constant: FSB = 333.34 MHz and multiplier = 9.0 which gives an overall core rate of 3.0 GHz. DRAM voltage was 2.25V and timings were 5-5-5-15-4-30-10-10-10-11. You can think of memory bandwidth as the diameter (size) of your memory's pipe. Quite often, the pipe's diameter isn't the bottle neck for a modern Intel-based system; it is usually much larger than the information flow to/from the processor. Think of it this way, if you can only flush your toilet twice per minute, it doesn't matter if the drain pipe connecting your home to the sewer is 3 inches around, or 8 inches around, or 18 inches around: the rate limiting step in removing water from your home is the toilet flushing/recycling and the pull of gravity, not the size of your drain line. The same is true for memory bandwidth. After seeing the data I generated on a quad core @ 3.0 GHz, I concluded that this toilet analogy is pretty true: the higher memory bandwidth gave more or less no appreciable difference for real world applications. Shocked? I was. Further, I should point out that in order for my system to run stable in PC8888 mode @ a FSB of 333, I had to boost my NB vcore two notches and raise my ICH to the max (both of which the BIOS colored red meaning "high risk.") The increased voltage means more heat production, and greater power consumption -- not worth it for small gains realized in my opinion. Anyway, the test details and results are below if you want to read on. Relevant test hardware: Motherboard: Asus P5B-Deluxe (BIOS 1215) CPU: Intel C2Q - Q6600 (B3 revision) Memory: Ballistix DDR2-1066 (PC2-8500) "Real-World" Application Based Tests I chose the following apps: lameenc, x264, winrar, and the trial version of Photohop CS3. I ran these tests on a freshly installed Windows XP Pro SP2 machine. Lame version 3.97
  7. I just bought a pair of BL2KIT12864AA1065 and they will work in any mode except the fastest two. These work fine: 1:1 (533 MHz), 4:5 (667 MHz), and 2:3 (800 MHz). If I boot them in in 3:5 (889 MHz) or 1:2 (1,066 MHz) windows will not start. If I boot into Memtest86+ V1.70, they give TONS of errors in the faster two modes, but are just fine in the lower 3 modes... I've tried manually setting the timings/voltage and also letting the board do it with no luck either case. I'm using 5-5-5-15-4-30-10-10-10-11 @ 2.25 v initially. I have a P5B-Deluxe running BIOS 1215. Anyone else out there have this board with these sticks? I'm thinking since I get errors at the higher modes, it's my board, not the memory. Opinions are welcome. Thanks! Additional info: q6600, x1950 pro 512 meg. I normally run the system @ 9x333 @ 1.2625vcore with my old memory (DDR2-800 ballistix @ 1:1 with these timings: 4-4-4-12-4-20-10-10-10-11)
  8. Which ports are you forwarding?
  9. Thanks for the data... don't melt your CPU
  10. Okay all, this will be the final update; please don't post new VID data. I'm not totally sure the integrity of the data collected is that high. What I mean by that is I have read several reports of different reported VIDs for the same chip on different boards. I have also read about the VID changing based on the speedstep state and other factors. I started this thread hoping to see some sort of correlation between VID magnitude and vcore @ a given o/c level. I have received mixed reports on this front as well. I think the bottom line is there isn't a correlation between VID and overclockibility. Since you guys took the time to reply to the post, the least I can do is update the data for the last time: Replies for B3: 102 Replies for G0: 158 Total replies: 260 (a great response!) I updated the first post of the thread with the new histograms. Thanks to all who replied.
  11. As of 20-Sep-2007, we have data on over 100 Intel-based systems and on over 40 AMD-based systems. There are a few trends I picked-up on while browsing through the database. I put them into a single table and color coded them to make them easier to see. If you see a trend I missed, lemme know and I'll add it to the table. Request: we don't have a single example of a machine that has both WinXP and WinVista on it. If you have a dual-boot setup, it would be cool to see the difference the O/S makes. Another missing trend is a 32-bit O/S vs. the same O/S that's 64-bit. On to the table: Yellow: Nearly 1:1 increase by adding an additional processor to a dual-chip MB Orange: Some operating systems seem to handle x264 more efficiently than others Red: Insignificant gain by upping the DRAM speed by 50 % Blue: For the most part, these chips scale in a pretty linear fashion Green: Tighter/looser memory timings have a pretty insignificant effect Purple: Keeping the same over-all clock speed using a different combo of multiplier and FSB can give pretty insignificant gains Again, I only gave this a once-over look; please point out any trends you see that I missed and also don't forgot about the O/S request! Thanks again to all who contributed!
  12. It's real-world since most people use x264 to encode videos You planning to give it a whirl on your system?
  13. Thanks for the result, hardnrg. I toyed with the idea of using ISS or NIS but I wanted people to see that the benchmark, although based on a batch file, wasn't a virus/dangerous etc. I think making people manually copy a file is as transparent as I can be!
  14. Thanks for the data dude. What is the code name of your chip (you can get it from CPU-Z). Is it a Toledo?
  15. Wow dude. No virus here. Have a look at the batch file before you run it. No, it has been tested on 64-bit windows. I'm guessing you didn't copy over the DGDecode.dll to your avisynth/plugins dir? If you drag-and-drop the avs file into your mediaplayer, I'm guessing it'll error out: script error: there is no function named "DGDecode_mpeg2source" c:\work2\test\test-480p.avs, line 1) Can you confirm this? (start menu>run... type mplayer2 and hit OK. then drag-and-drop the avs into it)
  16. @andrew05 - cool man, just lemme know what your mainboard's chipset is running. You can find it in CPU-Z under the mainboard tab (northbridge)
  17. I put together a self-contained x264 video encoding benchmark. Techarp kindly agreed to host the file and results at this URL. Basically, you run the test encode and it will report back frames-per-second values for your machine @ it's clock/overclock level. You can run it at your stock settings and at your overclock settings to see how your machine compares to others in the database. The database is small right now (as of 08-sep), but as you guys report in results, I will populate it. My goal is to have a representative set of data for many different chips and chipsets. Hopefully, we'll get some Penryn and Phenom data when they become available. Also, if anyone out here has some of the high end AMD chips, please contribute. Instructions and the file are at that url. Also, please report your results here in this thread. I will keep the data at that url to keep things simple. Thanks all.
  18. Updated the first post of the thread with the data collected (208 replies now)...
  19. Updated the first post of the thread with the data collected (182 replies now)... this has turned into a nice little thread
  20. It'll only make a difference if you want to use a ratio that's NOT 1:1... in that case, you'll probably want RAM that's faster than 800.
  21. Okay guys, I updated the guide (now version v1.2). It has been streamlined, dead/bad links removed, etc.
  22. Topic says it all. I'm only interested in your vcore @ 9x333 if you own a g0 Q6600 and you minimized the vcore and if it's stable to 2x orthos or prime95 v25.3 for over say 4 hours. It would also be cool to see your VID as reported in coretemp. So I guess I'd like to see two things: 1) Your minimized vcore @ 9x333 (g0 q6600) 2) A screenshot of Coretemp under load to see your VID and temps Thanks in advance!
×
×
  • Create New...