Jump to content

graysky

Members
  • Content count

    104
  • Joined

  • Last visited

Everything posted by graysky

  1. Finally narrowed down my next board purchase to a P5E or a Maximus Formula. My goal is to run a Q9450 or Q9550 (likely the 9450) @ 8x400 or 8x450. Anyway, I've read that the NB/SB temps on these boards can be quite high and wanted to solicit some feedback from you guys. 1) What board do you have? 2) What is your overclock setting and chip (q6600 running 8x400 for example)? 3) What is your idle/load motherboard temps (like NB/SB, etc.)? 4) Optional - what are your board voltage settings? Thanks all!
  2. Cool, version 25.x is better since it has native quad support.
  3. graysky

    x264 video encoding benchmark

    Did you read the first section of the FAQ, odds are it's one of those 3 things. Also, you'll need to give me a little more info as to what's going wrong.
  4. graysky

    x264 video encoding benchmark

    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.
  5. Anyone think this is worthy of a sticky?
  6. 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?
  7. 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
  8. Just updated the guide to version 1.3 which contains new info, fixes, clean-ups, etc. Enjoy!
  9. graysky

    x264 video encoding benchmark

    Got it, thanks for the data!
  10. 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
  11. graysky

    x264 video encoding benchmark

    Updated the Intel table. It now contains several Yorkfield ES chips including: Xeon E5330 (Dual board) Q9550 Q9350
  12. 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)
  13. graysky

    OCC UT3 Beta Server

    Which ports are you forwarding?
  14. graysky

    x264 video encoding benchmark

    Thanks for the data... don't melt your CPU
  15. graysky

    Q6600 owners... what is your VID?

    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.
  16. If you own a Q6600, please reply with your VID and the stepping of your chip. The VID can be found using coretemp. If you're using vista, coretemp will not display the stepping in some cases, so you can use CPU-Z (it's listed under "revision") to get the stepping. Here is a shot of mine for reference: If all else fails, look on the box your q6600 came in; the last 5 letters after the Q6600 in the production code will tell you the stepping. "SLACR" means it's a G0 while "SL9UM" means it's an older B3. Here an example shot taken by XtremeTiramisu to give you an idea: So, I have a B3 w/ a VID of 1.2875v EDIT: Here are the data as of 23-Sep-2007 at 7:30 AM based on people's replies to my VID thread here and elsewhere; just as a reminder, please do not post your VID from here on out as I won't be updating the data sets: *Histograms generated with SBHisto Total replies: 208 102 replies so far for B3 stepping Q6600s: (VID: # of replies) 1.1625: 3 1.2125: 1 1.2250: 1 1.2375: 1 1.2500: 5 1.2625: 2 1.2750: 13 1.2800: 1 1.2850: 1 1.2875: 12 1.3000: 14 1.3100: 1 1.3125: 15 1.3200: 1 1.3250: 31 158 replies so far for G0 stepping Q6600s: (VID: # of replies) 1.1125: 1 1.1520: 1 1.1625: 5 1.2000: 5 1.2125: 9 1.2150: 1 1.2200: 1 1.2250: 8 1.2375: 10 1.2500: 16 1.2525: 1 1.2600: 1 1.2625: 17 1.2650: 1 1.2700: 1 1.2750: 25 1.2850: 1 1.2875: 23 1.3000: 17 1.3125: 10 1.3250: 5
  17. graysky

    x264 video encoding benchmark

    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!
  18. graysky

    x264 video encoding benchmark

    It's real-world since most people use x264 to encode videos You planning to give it a whirl on your system?
  19. graysky

    x264 video encoding benchmark

    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!
  20. graysky

    x264 video encoding benchmark

    Thanks for the data dude. What is the code name of your chip (you can get it from CPU-Z). Is it a Toledo?
  21. graysky

    x264 video encoding benchmark

    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)
  22. graysky

    x264 video encoding benchmark

    @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)
  23. graysky

    Q6600 owners... what is your VID?

    Updated the first post of the thread with the data collected (208 replies now)...
  24. graysky

    Q6600 owners... what is your VID?

    Updated the first post of the thread with the data collected (182 replies now)... this has turned into a nice little thread
×