Sure Randy, where do you need it dropped? Want them SAS arrays too? You might need that extra storage speed, you know. Just drop me a word when you've done with them
|
|
|
...which is precisely why I said that might mean he botched the TIM application somehow and that he needn't have messed with the card. That's pretty consistent with what you wrote in your first reply, isn't it?
Roadhog, I'll just call it a night, ok? We're going way OT with this conversation and there's precious little to be added.
|
|
|
People do use paste on the memory modules and vrms depending on what waterblocks they use too.
I don't see how that is pertinent to OP's issue? +10°C may suggest OP botched the application somehow but we'll only know for sure when the TIM has fully cured. OP asked a question whether he should let the TIM cure. I addressed this question directly by linking to manufacturer's recommendations. He probably needn't have touched the heatsink in the first place but that's another sack of ferrets.
|
|
|
Guess you didn't read my link. If you did you would see that with a great contact mount(which is rare), it actually does rather well.
Guess Skinneelabs didn't read Arctic Silver's manual. That TIM requires up to 200 hours of curing which they never bothered with. A shame really as it blows the objectivity of their tests out of the water. I don't recommend it for use on GPUs mainly because its a capacitive paste and shouldn't be used anywhere near traces or SMD's.
Never have I managed to use quantities excessive enough for the goop to squeeze out from where it belongs and onto the surrounding components. Therefore, I can hardly accept that as a valid argument against that paste. That having been said, it's a valid data point. Remember, we're trying to help OP, not argue about world's best TIM
|
|
|
This is almost too rich - except OP is admittedly broke
|
|
|
Actually, there is no surefire way except for setting the GPU core speeds to something like "200,400,600,800" in the config file and looking at the actual hash rates and temperatures. Another route would be setting one of the fans, say at GPU0, to 100% and observing which card is hyperventilating
|
|
|
Luckily, the percentage of hash rate that can currently be rented at any given time is insignificant but should it grow, we will get uncomfortable faster than most individuals imagine.
Any attacker has a chance of briefly becoming the longest chain by sheer luck (mining a few short blocks) but of they are <50% they will eventually be subverted by the legit network's superior hash rate. Over 50% of the hash rate is where the attackers can expect their chain to remain dominant indefinitely.
Two most prominent attacks are: (1) massive double spend attacks, any entity resourceful enough to mount a successful 51% attack can be expected to have access to a whole damned lot of bitcoins to double-spend, and (2) network stoppage: were the attackers to only process their own transactions, Bitcoin would come to a screeching halt.
It is widely known that network growth guarantees Bitcoin's security but not everyone considered the possibility of significant portions of that strength ending up in attackers' hands via various meta-pools and ">100% projects for hire", thus being applied against it.
Until recently, the (simplified) attack model looked a lot like that: Let X be the network hash rate, measured in TeraHashes/s. Let S be the actual network strength. If the adversary is able to perform a denial-of-service attack nullifying a subset of X (let that subset be Y), then S is, obviously, X - Y. The adversary needs to be a large pool operator (or a cabal of those) to succeed. Creating and maintaining a large pool is a resource- and labor-intensive task. With just a few percent pool fees, a potential adversary might in fact be better off playing by the book and just running a large pool. With the advent of for-hire projects, another variable is added to the equation: Let Z be the amount of hash rate available for hire, even for relatively short periods of time. Z further undermines the actual strength, S = X - Y - Z. Z being large enough, the adversary does no longer have to be one of the big dogs (that is, the largest pool operators) to mount a crippling attack.
In both cases, the adversary wants to reach S/2 as fast and as inexpensively as possible, it is therefore desirable to subtract from X as much as possible. Having access to singificant Z is a very cost-effective way to do that.
|
|
|
It' should always raise a red flag when questions are met with excessive vagueness, half-truths and outright lies, or just killed off entirely by invoking "trade secrets". I'm not setting foot at Eligius or ABCPool ever again, nor am I going to touch any >100% project with a ten foot pole unless detailed and sensible explanation is provided.
We really need more of those next-gen miner-smart pools yesterday. By miner-smart I mean pools where each miner runs their own bitcoind, does their own block verification, and merely shares the rewards with the pool members without blindly trusting and relying on the centralized pool software. P2Pool is an outstanding example of this approach guaranteeing that each miner retains full control over how their hashing power is being used.
|
|
|
so you believe that goat is ( and others) knowingly using his power for "shady" purposes?
Fixed
|
|
|
I vote to BAN all Solidcoin related topics. I'm tired of this shit.
I'm with you on that.
|
|
|
BAN ALL SOLIDCOIN RELATED TOPICS!! Including CH! That's enough.
Righto.
|
|
|
Is that bothering you?
|
|
|
Just to clarify, on linux, we never saw the GPU reordering, correct?
Wrong. Proof by counterexample: 2.2.0 did reorder some of my GPUs. 2.2.1 does not do any reordering unless explicitly asked to, you should be ok if you just skip 2.2.0 Con, git c0e8819 been running fine for 6 hours. PS. Now we're talking: root@haerdalis::/home/jake# cat /opt/bcm/cgminer-testing/version.info cgminer-git-c0e8819
|
|
|
NP Cypherdoc. Remember that the flashing utility will require admin rights and be sure to start with creating a backup of your old bios. Best of luck.
|
|
|
Some 6950 are unlockable PERIOD. The amount of system memory has nothing to do with unlockability. Unlockability depends solely on the GPU chip. 100% 6950 chips used to be unlockable early on but not all of those were defect-free. In 2011 AMD changed the rules, however, and newer chips are having their shaders laser cut at the factory specifically so that they can not be unlocked. It's a total crapshoot and the only thing you can count on is that the newer revisions won't unlock.
If you have any choice, aim for the card revisions from 2011Q1-2011Q2. Those are more likely to unlock.
|
|
|
Funny you should mention that DAT. I've had an open-source wallet decrypter/converter/key extractor somewhere on my todo list for quite awhile. Seems I just can't get there
|
|
|
Nice, P4, but do mind that usb+linux miners are - alas! - not the majority. While there's nothing preventing one from using Windows the same way, all that background housekeeping stuff would kill a usb drive fast. My criticism still stands, hard drives or no hard drives.
|
|
|
|