Jump to content

Nofew

Registered User
  • Posts

    71
  • Joined

  • Last visited

  • Days Won

    1

Nofew last won the day on April 15 2013

Nofew had the most liked content!

About Nofew

  • Birthday 08/05/1993

Nofew's Achievements

T|I Semi Advanced

T|I Semi Advanced (3/7)

49

Reputation

  1. Hello! Sorry for being away for so long! Life happens! I tend to get odd hardware bugs that nobody else on Planet Earth appears to get. I've been struggling with one issue for the past year and a half now, at least, and the last hope I had to fix it appears to have retired. I'll cut to the chase: I have three Titan Black cards by Asus, stock vbios. (I'd /love/ a custom one and that might fix the issue I'm having, but none appear to exist anywhere on T|I.) Currently I only have two in the case, but knowing that I have three at my disposal is important. I'll explain why shortly. Out of the blue one day, I couldn't get above a few hundred FPS when benchmarking with SLI turned on. At the surface, that's not too interesting. I get that. It gets downright *weird*, though. At all times during these events, I've only had two GPUs installed at the same time. The first thing I thought was that I had a bad SLI cable, so I ordered a new one and tried that. No dice. Tried swapping the position of the cards, no luck. Tried ordering a third GPU and trying every combination of two cards in case one was broken, but all of those combinations had the same result. Things got weirder when I started paying more attention to the numbers, reporting tools and did some math. When running at 2560:1440, I get about 300 FPS. It doesn't fluctuate; it hits a cap. The number is incredibly steady; even the decimal point only moves by .1 between frames and hangs within .1 of where it settles after 3Dmark gets going for more than a second or two. The scene's complexity doesn't matter -- I can be running Ice Storm at the most basic settings or Cloud Gate, and it'll still get stuck at that limit. Single GPU, Ice Storm hangs around 1,600-1,800 FPS depending on my CPU clock. My first thought was that the cards weren't using the SLI cable anymore and were using the motherboard instead, thus saturating the PCIe lanes. It turns out MSI Afterburner can measure them, and this indeed appears to be the situation SOMETIMES; PCIe bandwidth goes to 50% (I assume this is really 100%) during some benchmarks where it used to hang around 2-5%, but tests like Fire Strike don't saturate it. Upon seeing this of course the issue seems obvious, but there's one major inconsistency that might rule this out: Even in cases where the PCIe bus isn't saturated, two cards always perform worse than one card now. Even during Fire Strike Extreme, where I get maybe 30 FPS with one card, I used to get 60 FPS with two cards. Now it's around 26 with two, and the PCIe lanes aren't saturated. Seeing this, I decided to see if MSI Afterburner could tell me more. I've always had every reporting option turned on, and I usually know what they look like. One changed dramatically: "SLI Sync Limit". I don't know what this is and Googling it never turns up useful results, and there's not even any documentation I've found that explains what this is in any appreciable detail. All I know is, until things started going weird, it was always at 0. Never changed. Ever. Now, whenever I run anything in SLI except the Windows desktop, it goes to 1. It seems to be a binary indicator since I've never seen it go anywhere else. Seeing as PCIe saturation might be a factor here, I decided to try and reduce stress on the PCIe bus. One of my thoughts was that the cards were sending their framebuffers over PCIe rather than SLI, so I changed the resolution. Lo and behold, changing it from 2560:1440 to 1920:1080, which is roughly half the pixels if you do the math, brought the framerate cap up to about 600! Changing it to 720 brings it to around 1,200. I'm fairly convinced they are indeed sending their framebuffers over PCIe at this point, and that that's causing some pretty major issues. Now, I know nVidia used to support doing SLI without an SLI cable with a driver setting; head to the control panel, pick an option from a dropdown or something, apply, OK, all happy. It'd just make the cards talk via PCIe rather than SLI, and it worked. They eventually removed this option from the control panel, but after emailing nVidia about the issue it turns out that the feature still exists, but it's hidden from users. So, my first thought was that I somehow toggled the option in some fashion. I tried reinstalling windows, downloading fresh drivers, no overclocks, no nothing, and the same issue presented its self right off the bat. This is where I'm stumped. I've tried everything that I could think to get my hands on -- I've updated my motherboard's BIOS, I've done a microcode update for my CPU (i7-3930k), I've tried using different GPUS (the third Titan Black I mentioned, not other models), different screens, HDMI, DisplayPort, older drivers, newer drivers, beta drivers.. None of it works. Any useful help that I haven't already gone over would be appreciated! (Context: ) EDIT: Huh! Weird! I just got the idea to try running the benchmarks windowed! Weird stuff happened! With SLI off, fullscreen, I get about 1,400 FPS during Ice Storm. With it on, fullscreen, about 338. With it on, and windowed, about 1,200! PCIe still goes way up but SLI Sync doesn't trip. It's still worse than one card by its self (Which never used to be the case; I almost broke 2,000 once!), but there's something to running things fullscreen vs running it windowed! PS: It's not 3Dmark. This happens with every benchmark and game out there, with the same limit of 338. EDIT2: I found https://www.reddit.com/r/techsupport/comments/3lrjhy/sli_sync_limit_is_spiking_from_0_to_1/ . Appearntly SLI Sync Limit appears even on non-SLI setups! Seriously, what /is/ this thing?! EDIT3: It seems to be related to GPUBoost 2.0. I finally found a custom vbios over at http://www.overclock.net/t/1503215/titan-black-bios-and-tweaking and SLI Sync Limit doesn't trip anymore, but somehow the framerate is even worse now; I can only get about 177 FPS on Ice Storm at this point, and PCIe is still going nuts. What the heck!? Also, I apparently achieve a stable 1,150 mhz at 1.05 volts. From everything I've read I shouldn't be able to get that under 1.212 volts. Either I've got the most golden sample _ever_, or something's being reported inaccurately. I'm not sure if this is related.
  2. Yes, I've tried other ports, other cards, and other games. Also, bandwidth between the motherboard and card clearly isn't the issue; read my original post over again.
  3. The subject says mostly everything. I've already tried contacting nVidia support, got all the way up to Level 2, and they don't know what's going on. I'm hoping somebody here does! (Presumably relevant) system specs: i7-3930k at 4.4 ghz 32 gigs of RAM Asus Sabertooth-X79 motherboard Asus Titan Black (Two in SLI using ribbon connector, stock vbios) Below is an excerpt from the support log. I was particularly awake that night and I imagine it's more presentable than anything I can come up with at the moment. (...) The limit is only 172 while I run at 1440P. When I run at 1080p, I get limited to 300 FPS instead. 720p gets me 600. Changing the refresh rate does not change the framerate limit. All these limits are set in stone; regardless if I'm running the newest benchmarks or the oldest games, the framerate limit doesn't change. This is what lead me to believe that there's some sort of bandwidth issue somewhere. After turning every possible monitoring option on in MSI Afterburner, I found that PCIe Bandwidth was at 50% for each card (normally it's only at 10%), and the primary GPU was hitting "SLI Sync Limit". I can't find any information on what this means online because it's only mentioned tersely in a changelog in one place, but I figure it's relevant. Now, you may be wondering why this is important -- I mean, logically, I'm still getting frames up faster than my display can draw them, right? The problem is, in games where I legitimately /need/ SLI, the performance is worse than if I turned SLI off entirely. I get 52 FPS in Fire Strike with SLI, and 58 without. I used to get about 110 with SLI. I've made sure that the cards themselves aren't damaged. Before things broke, I remember running a benchmark on each card individually using software called "Cudahashcat". (I assure you, it was only to show people how fast short passwords can be broken in this day and age.) -- Each GPU got about 8 billion MD5 hashes per second. After things broke, I ran that again, and each card still pulls 8 billion. I tried ordering a new SLI cable and switching it out, but that didn't change anything. I'm not sure if the SLI connectors on the cards are okay. That's my only guess if it's something hardware related. I'm hoping it's something software-related though, obviously! A few other things I've tried: * Rebooting * Clean install of the newest nVidia drivers (344.something -- I've updated since then to 344.65, but without clean installs) * Different monitors * Different connections (Tried DisplayPort and HDMI) * Using Alternative Frame Rendering 2 rather than AFR1 (No change in framerate at all) * Underclocking the CPU (No change. Note, I am only overclocking using the CPU multiplier, not BCLK) * Toggling PCIe Spread Spectrum (No change, on or off) * Leaving the computer off and unplugged until the capacitors ran out of power (Had to wait about two minutes until the LEDs on the motherboard went off) * Blowing compressed air into the exhaust of both GPU's to remove dust (Not that either GPU gets excessively hot, but I was running out of ideas.) * Different refresh rates (60, 85, 100, 110, 120, 144, G-sync on and off) * Prayer. (Also prayed for my mother to get through surgery. That happened! Good thing God didn't choose to switch His answers!) *EOF* Does anyone even know what "SLI Sync Limit" even means, apart from something to with SLI and syncing?
  4. Yes, but do monitor temperatures and don't run with a heavy overclock 24/7. At maximum load with a factory-attainable overclock, the reference cooler already hovers around 65-70C. Most people have to go lower since GPU Boost 2.0 is enabled and causes instability. Without that, you can go higher, and I figure temperatures will hit about 75C tops. This is all assuming your room's around 20C, though. I'd be able to give you more accurate numbers if I had a vbios for a TItan Black. (Hey, @svl7, read http://forum.techinferno.com/nvidia-video-cards/3454-nvidia-gtx-titan-modified-vbios-more-control-better-overclocking-46.html#post95654 for my adventures on that!)
  5. I'll just leave this here.. (Hint, check the gigaflops column.) List of Nvidia graphics processing units - Wikipedia, the free encyclopedia Okay, fine, and List of AMD graphics processing units - Wikipedia, the free encyclopedia for completeness. Go with nVidia anyway. In my experience, ATI is riddled with bugs in games and has major issues running some demoart. (Not that you'd be able to run much of that stuff on a budget GPU, but still.)
  6. Whelp, now I've got two Titan Black's and I'm about 400 points away from breaking 10,000 on Fire Strike Extreme and this is maddening beyond all words. o_o... @svl7, before I do something horrendously stupid, is it possible to perform a not-so-blind-flash if I've got two GPU's? Or should I not even mess around if it's still giving me "PCI Block corrupted" when I try to use your vbios? I vaguely remember some mention of needing to use a special switch in nvflash to get past that error, but I'm not sure if I'm remembering it correctly or confusing it with -6..
  7. Well, it took me a while to work up the guts to try it, but I did it! I should note that DOS refuses to boot on my system, so any "easy" recovery kinda went out the window. Anyway! The modded vbios doesn't flash, but it doesn't appear to corrupt the card either. Attached are two screenshots of the command prompt, showing that the flash with the modded vbios fails but does not change the firmware on the GPU, and that restoring the original firmware happens flawlessly. Also attached is an NFO and DxDiag of my system. I don't know if there's some weird hardware configuration preventing things from working properly, so there they are. Considering I can't get into DOS on this system, that might be the case. (It gets into DOS fine with the same thumbdrive on other systems. On this one, it just shows a blinking cursor forever. It won't let me type and ctrl-alt-delete won't reboot.) Finally, just for completeness, my original vbios is attached. All files are in the single .zip archive. EDIT: Nothing seems broken after fully powering the system off and on, and I forgot to mention that I'm running 337.88. Sorry about that! Asus-Titan-Black_80.80.4E.01.01.zip
  8. Kuffs: "Really doubt"? Er, basically every PCB is custom in a mobile system. It more or less has to be since you're trying to cram it into such tight confines. Not only is the motherboard unique and unswappable between different cases (even by the same manufacturer), but the GPU is customized as well to a smaller degree. Rather than having a configuration file, it's cheaper and increases performance (Slightly, but it's there) to have everything hard-coded. It's safer too; if something goes wrong and data gets corrupted, the GPU won't boot since it's very likely the code explaining how to boot got corrupted with it. If it continued to boot and then read bad numbers, it might ask for some obscenely large amount of power or something and potentially ruin other parts of the laptop. Generally what happens is there's a base image given to them by nVidia, and then they have a program that lets them tweak it to suit their needs. (How else do you think NiBitor used to work?) -- These days though, companies generally have their leaks covered. That's why we got people like svl7! Disclaimer: The above text just sounds like common sense. I could be totally wrong, but I'm pretty sure it's accurate.
  9. Kuffs: No, almost every vbios is different, even between different manufacturers. That's why he has ones for the 680m for both Clevo and Dell cards and such. He does actually need one in his possession (or a willing test subject, if you feel like volunteering) to see if stuff works.
  10. Well, version 5B is weird, then. Kuffs: Yes, it's called a "hex editor", but that probably doesn't help you much. See this post and the one after it. If you want to speed the process up, you can buy svl7 a K4000M.
  11. italy2200: FPS cap? Are you sure you just don't have a bad card? Some cards are overvolted from the factory since they can't handle even stock speeds at 1 volt. The 5B version brings the voltage up (or down) to 1 volt, so yeah. If you load your backup and check the voltage while running under maximum load that should shed some light on things.
  12. Kay! So I don't know if I should be making a new thread for this, but I figured I'd post it here. svl7's vbios disabled my GPU's automatic "switch to P8 whenever the power cable comes out" magic and has ran my battery down pretty fast when I forgot to switch manually. I wanted this feature back so I wrote a program that handles doing it for me that I'm chucking on here. It checks if the power is plugged in once a second. If it is it'll use nVidia Inspector to switch the GPU to P8, and if it's not it'll switch back to P0. The actual command is only sent once per change in system power, so if you want to override its decision you can just go ahead and switch pstates like you normally would without any issues. In order for it to work you need to copy nvididaInspector.exe to somewhere in your system Path. If you don't know what this means, just go copy nvidiaInspector.exe into C:\Windows\system32 and be happy. The program only takes up a megabyte of memory (Seriously? A whole meg for this? What the freak, Windows.h? Normally I program stuff that only takes a few KB when I'm lazy. This feels embarrassing..) so it shouldn't interfere much with gaming. I would turn it off for benchmarking just in case, though. To do that you'll need to hit ctrl alt delete, go to the task manager, find it and kill the process. To get it to run at boot just right click it, make a shortcut, then drag and drop it into the "Startup" folder in your Start Menu. Source code's included in the attachment. It's dead simple since I'm using system() calls but if someone can figure out how to switch P-states without the aid of Inspector I'd happily jump on that. NVBattSwitch.zip
  13. paladinjake: All 680m's throttle at 90C. The absolute limit is 95C, and the temperature probe isn't 100% accurate. If you disable the throttling then there's a very good chance your card's going to die. As for why it's so hot even at stock speeds.. Sager's kind of ridiculous. They have the part of the copper cooling pipe that contacts the card bent so that it doesn't conduct heat as well. To correct this, you need to take the cooling unit out and actually sand it down until it's flat. You may want to apply better thermal paste while you're at it (though I dunno what Sager uses; it might be fine). svl7: Do you think it's possible to write a vbios (for a Dell 680m, but preferably all of them) where the P5 clock is at 757 mhz? I just had a stroke of genius -- Being constantly overvolted might be dangerous, but the 680m doesn't allow us to change the voltage without a reflash. So, set P8 to be 135 mhz (or however low it's supposted to be), and then set P5 to be 757 mhz (or whichever the stock value is for that particular model). That way, you can run at P5 all the time if you want stock speeds and close to stock voltage, and when you set it back to auto it'll run at your maximum overclock with the overvolt!... In theory, anyway. This does appear safe from my standpoint -- There's /another/ clock entirely for the rate it's set at boot (I have no idea what P-level it is, but it doesn't seem possible to tweak it. On my system it's accessed by doing -forcepstate:0,0.), so after the mod the system should still boot up at roughly 400 mhz without placing too much draw on the battery. The only drawback is the fact that only P0 automatically switches to a low-power state during idle, but it should be possible to write a program that reads how much use the GPU is getting (MSI Afterburner does that, after all) and switch from P8 to P5 to PBoot (to emulate the old P5) and back again as if it were in P0.
  14. Rajat Roger Nag: Okay, did some research and found out that .5B has support for Secure Boot and Fast Boot while .33 doesn't. I don't really know why a GPU would affect those things, but that seems to be the case. Do you know if your BIOS even has an UEFI option? You can check under the "boot" page and see if there's a toggle option between "UEFI" and "Legacy". I'm thinking about flashing .33 onto my card, but I know Secure Boot and Fast Boot are both UEFI things and I don't have much experience there.
  15. Rajar Roger Nag: I don't know the differences between them, but so far I think the 5B version may be meant for laptops with 3D screens. Thise are wired different and require that Optimus be disabled. I could use some help researching this. Is your screen 3D-capable, and what version is your stock vbios? The limit set by nVidia is 95 C. Don't hit that. 90 C is the highest you should probably be going while supervising it. For regular use you'll wanna run less. I don't hit 90 even while running OCCT with a +240 overclock, so if you're running hotter at lower speeds something's probably wrong. How hot is your room?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.