havli

Just to be clear - the original plan was ~ 800 hours. Just after loop 17 I figured it may not be good enough, so I decided to slow down even more. That is the reason for much slower final three loops.

Congrats, very strong score. I had no idea AM2NF3-VSTA works this good with Voodoo5 PCI. I did some testing with V5 PCI + Core2 Duo + PCI-X board... but could not get better score than V5 AGP + KT333 + Barton.

Thank you, I used my best Barton and 3.3V AGP compatible MB for this. Too bad I didn't finish the 128MB mod for Voodoo5, it would have been much closer to first place of this competition. The primary VSA-100 turned out to be defective (I originally thought memory is bad, so replacing it would fix the V5). Maybe if I can buy replacement VSA chip and have it resoldered...

No disrespect, but are you really sure this TNT2 is only 8MB part? The sticker suggests 16MB... and although 8MB consisting of 4 SGRAM modules is possible, these particular ones looks identical to those used on Voodoo3 PCI http://hw-museum.cz/data/vga/pic/big/3dfx_Voodoo3_2000_PCI_SGR_F.jpg So 4*4 MB = 16 in total (and 128bit too). Even Everest can be wrong sometimes - my Voodoo4 4500 PCI is detected as 64MB, which is wrong obviously. Or another possibility - BIOS of this particular TNT2 is somehow broken and only 8MB is active (although it seems physically 16MB is present in total). I saw this once, long time ago, on GF2 Ti - which was working only as 32MB / 64bit.... although it was 64MB / 128bit physically. There is a way to know for sure what amount of VRAM is there. Try what maximum resolution it can run (in 3D mode). Lets say Quake 3 Arena - 1024x768x32 should be impossible to run on 8MB videocard and still should work on 16MB.

Jar is no longer available in v1.2.0, only exe remains. And it is configured to use only the built-in java to avoid possible incompatibility with various java versions. HW/SW detection relies on cpu-z, so WMI shouldn't be an issue. When the splash screen is displayed, the benchmark is starting in the background... there are two things that could cause crash. 1. Artificial CPU load is launched on n-1 cores/threads (7 in case of FX-8350) to determine correct frequency for full load. 2. When the load is active, cpu-z is launched to generate HW & SW report. I guess the artificial CPU load part really shouldn't crash your PC. And if it does, it wouldn't be able to complete the benchmark anyway, as the x265 encoder is much more demanding. So maybe some sort of cpu-z incopatibility? You could try to use older version (1.72), maybe it will fix the problem. Just replace cpuz_x32.exe in the x265 directory.

I'm curious how the 8MB m64 looks like. So far I have never seen one... Just for a reference - Vanta LT 8MB looks like this: http://hw-museum.cz/view-vga.php?vgaID=182 And regular Vanta 16MB http://hw-museum.cz/view-vga.php?vgaID=181

946 hours = 25 days? Looks weird...

From now on only version 1.2.0 is allowed. I made two submissions using v1.2.0 and all seems to be working well. If you find some bug, please report it here. http://hwbot.org/submission/2976861_ http://hwbot.org/submission/2976863_

Yes, both are allowed.

Now that's some serious cooling for a 486

Hmm, maybe it is a long shot... did you try ISA video card? Perhaps it could work in extreme conditions such as this. Not sure about winXP compatibility though. All I can say is that Trident 8900 1MB was working fine on my 486 board using Windows NT 4.0 and 1024x768 8bit color.

Is some anti-sandbagging system in place for SC4 or the stage is open for everyone to the end (September 30)? I'm planing my GPUPI run, so I need to be sure when the deadline is.

Just a little heads up. Version 1.2.0 is ready. There are some security measures implemented as well a couple of improvements and bugfixes. http://hw-museum.cz/hwbot_x265_benchmark.php This version will be mandatory for submissions as of Monday 14th of September (a week from now). Until then v1.1.1 is still valid. Unfortunately it is not possible to use both versions simultaneously. I must switch them manually - which will happen next Monday. Old saved data files will become invalid.

More than ~3500 should be possible with V5 PCI and right MB/OS/driver combination. Not easy to put all four together and score that high though. Thats why i went the easy way, at least for start. I like plexi cases very much, but they were (maybe still are) almost impossible to buy. So I decided to build my own. Very time consuming... which wasn't an issue for me back in 2008. Wish I had so much free time now. Detailed specs and more photos here: http://www.vogons.org/viewtopic.php?f=25&t=41337&p=388533#p388533

All built-in tweaks are allowed. Feel free to use them.

Yes, Windows 7 Pro CZ I never had problem benchmarking GPUPI on CZ windows. The xeon system is now disassembled, but the very same install of win7 (just connected HDD to another PC) worked fine on socket 1366 Xeon next day. I guess the data file just got corrupted somehow. Maybe a solar flare or something.

Thank you. 4 points and two gold cups are no big deal... still I'm curious what the problem is. Yesterday I put the HDD to Nehalem Xeon PC (no reinstall) and suddenly GPUPI submit is working again. Really strange, must be some kind of obscure incompatibility.

Clock and RAM timing are tied together. 155 - 166 MHz = 6ns RAM, 183 MHz = 5.5ns RAM. Check this: Radeon DDR -> http://kwaz.cz/index.php?strana=grafika&idg=200&pocetvyrobcegpu=ATi - 166 MHz, 6ns DDR Radeon DDR VIVO -> http://kwaz.cz/index.php?strana=grafika&idg=186&pocetvyrobcegpu=ATi - 183 MHz, 5.5ns DDR GF2 MX400 is a different case - clock and memory type varies... but name remains the same. So only one category for this one. Radeon R100 exists in 5 different versions (official by ATi) and they have (had) different name.

Well, the Radeon R100 situation is a bit more complicated. In reality there are following cards based on the R100 GPU: Radeon SDR - 32 MB SDRAM, 160/160 MHz Radeon 7200 - 64 MB SDRAM, 155/155 MHz Radeon LE - 32 MB DDR, 148/148 MHz + disabled Hyper-Z Radeon DDR - 32/64 MB DDR - 166/166 MHz (some of them are AIW) Radeon DDR VIVO - 64 MB DDR - 183/183 MHz On HWBOT we currently have: All-In-Wonder Radeon DDR Radeon 7200 DDR Radeon 7200 SDR At some point ATi decided to rename all R100 Radeons to simple "Radeon 7200 Series". So it is difficult to determine what type exactly you have. I guess because of that we have only two categories - R7200 SDR and DDR. Plus the All-In-Wonder Radeon DDR which was added on my request some time ago. Not because of the TV Tuner and Video IN... these have no impact on overclocking. I asked to add it because it is a different videocard with lower default clock. Same as for example GF4 MX 440 and MX 460. ------------ I agree AIW variants should be merged - if they are 100% identical to existing variant of given VGA (apart of the TV tuner of course). From the top of my head - Rage 128 Pro / Rage 128 Pro AIW or Radeon 9000 / Radeon 9000 AIW. For example these have identical memory and stock frequency.

Update: Single CPU on the 771 platform now results in the same error. Weird, it was working fine two days ago... and I'm not aware of any changes in OS, drivers or other SW. Another PC using Pentium D 945 + windows 7 x64 works just fine. Well, the OpenCL driver is older and I'm running legacy version of GPUPI because of that... still, the "Unable to parse the datafile" error sounds completely unrelated to this.

Strange thing is single CPU setup didn't suffer from this problem. http://hwbot.org/submission/2959283_havli_gpupi_for_cpu___100m_xeon_5050_4min_21sec_356ms http://hwbot.org/submission/2959280_havli_gpupi_for_cpu___1b_xeon_5050_56min_40sec_31ms I will try to remove the second CPU to check if GPUPI submit works again.

mat, can you please take a look at this data file? Suddenly I'm unable to submit my results - Invalid data file: Unable to parse the datafile. Similar error shows up when uploading directly from GPUPI. Testing system is: 2x Xeon 5050 (stock, not overclocked) 8GB RAM Windows 7 x64, HPET on GPUPI 2.1.2 or 2.2 (both 64bit) http://hw-museum.cz/data/temp/2x_xeon_5050_GPUPI_for%20CPU_100M_02m-14.666s.result Thanks

I'll see what I can do about the DPI scaling. If all goes good, it might get implemented after v1.2 Time labels are in place and working quite good. Of course the remaining time is not very accurate - encoding speed is not linear, so time sometimes go backwards, depending on current scene. CLI: Oh, I understand now. I'm testing processors for web magazine too (retro hardware), unfortunately my methodology forces me to keep the benchmarking sequence running in person. It should be possible to implement batch run - using command line to start the benchmark and save results automatically... in theory at least. This will take some work, so no ETA on this one. Currently the code is not designed for operation like this. 8k: The download is big enough as it is (almost 500 MB). Adding another big video... uh, that would be too much IHMO. Also RAM capacity might become a limiting factor. 1080p ffmpeg + x265 needs at least 512 MB (no problem here), 4k = 1,5GB, 8k = who knows, I bet it would be a lot. Also when running "overkill mode" (aka multiple instances of encoder at the same time), RAM requirements grows very fast. L4 cache can indeed make a huge difference in some applications, mostly games. I saw the Broadwell reviews. Huge Haswell-EP Xeons with large L3 cache (>20 MB) sometimes can pack similar boost. Apparently when performance critical part of the application can fit in L3 or L4 cache, performance increase is massive.

trodas: Thank you, I'll update the RAM requirements section. P4 Celeron is really slow by the way borandi: I'm aware of the scaling issue. Java Swing doesn't work well with non-default DPI, so I disabled the scaling completely to avoid weird looking and broken GUI layout. In the current version (1.1.1), screenshot is captured as a png. I realise now the size of lossless png is too big, especially for large screens. So I'm going to use jpg instead to keep the size reasonable in the next update. Total time and ETA to finish should be possible to add if I find a free spot for it in the GUI. Command line interface - I don't think this is a good idea, there ale enough options to to get the best score possible as it is. And most people are running default settings anyway. Actually, the x265 console output is written to text file after each run even now. It looks like this: yuv [info]: 3840x2060 fps 23976/1000 i420p8 unknown frame count raw [info]: output file: run0-2160p.hevc x265 [info]: HEVC encoder version 1.7+374-b015514a93868e2d x265 [info]: build info [Windows][GCC 5.2.0][64 bit] 8bit x265 [info]: Compiling by KG7x [x265.ru] x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX x265 [info]: Main profile, Level-5 (Main tier) x265 [info]: Thread pool created using 4 threads x265 [info]: frame threads / pool features : 2 / wpp(33 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2 x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 2 / 0 / 0 x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1 x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60 x265 [info]: tools: rd=2 psy-rd=0.30 signhide tmvp fast-intra x265 [info]: tools: strong-intra-smoothing deblock sao 1 frames: 0.44 fps, 314.64 kb/s 2 frames: 0.74 fps, 2176.72 kb/s 3 frames: 1.02 fps, 3028.76 kb/s 5 frames: 1.52 fps, 2940.84 kb/s 6 frames: 1.47 fps, 2705.78 kb/s 8 frames: 1.83 fps, 2589.36 kb/s 9 frames: 1.94 fps, 2566.13 kb/s 11 frames: 2.00 fps, 2455.78 kb/s 13 frames: 2.23 fps, 2517.81 kb/s 14 frames: 2.30 fps, 2522.64 kb/s 16 frames: 2.34 fps, 2439.85 kb/s 18 frames: 2.53 fps, 2796.70 kb/s 19 frames: 2.57 fps, 2788.14 kb/s 21 frames: 2.57 fps, 2933.98 kb/s 23 frames: 2.71 fps, 3159.12 kb/s 25 frames: 2.82 fps, 3180.12 kb/s 26 frames: 2.72 fps, 3174.97 kb/s 28 frames: 2.84 fps, 3494.32 kb/s 29 frames: 2.81 fps, 3524.84 kb/s 31 frames: 2.76 fps, 3747.71 kb/s 34 frames: 2.91 fps, 4068.00 kb/s 36 frames: 2.92 fps, 4213.74 kb/s 38 frames: 2.82 fps, 4158.86 kb/s 39 frames: 2.80 fps, 4177.12 kb/s 41 frames: 2.87 fps, 4248.72 kb/s 42 frames: 2.89 fps, 4270.79 kb/s . . . . . 8k - when quantum computers are ready. No, I didn't speak to them. I just saw this http://x265.ru/en/x265-hd-benchmark/ , did some testing on various hardware and realized the x265 is very good for benchmarking both latest CPUs and legacy hardware as well. I thought - the encoder is opensource... so why not create my own GUI for it and use it on HWBOT.

Please add: Asus PCH-DL http://hwbot.org/submission/2957756_havli_black_hole_benchmark_xeon_3.2ghz_%282mb_l3%29_3604_marks thx.