So you're just incompetent then? You get a scrypt miner working and then just give up after no more effort? Then go around telling people that it's unfeasible on GPU due to your few hour effort attempting to see if it was possible?
Incompetent, or maybe not paid enough to really give a damn. Not to mention I said from the start that CPU coins are a fucking stupid idea because even a tiny botnet can trivially 51% em. mrtlt did it in 4 hours.
So... *what* is that "trivial" bug, and how the fuck do you work around it? Oh right... "seekrit! neener neener!" So you're either incompetent or holding back the truth about how much GPU mining you have been doing. Seeing as you were passing around hidden SolidCoin GPU miners prior to mtrlt releasing one publicly I think your past speaks for itself, including Bitcoin GPU mining. It's hardly a conspiracy when your past is full of this exact thing, it's a logical deduction.
Getting tired of calling me incompetent yet? No? Okay. keep on then... So wait, I'm supposed to release a SC2 GPU miner to the public out of the goodness of my heart when you fuckwads publically spread defamatory comments about me? Kindly go fuck yourself. As for how much GPU mining I have been doing, I had 24 5970s up until about late summer '11... then sold em, because at 0.22EUR/kWh keeping a mining farm after that would be kinda ... stupid, no? And as for me publically admitting I gave away a SC2 GPU miner? well, did I ever claim otherwise? ... Wait, nobody ever asked! Just LOL ARTFORZ IS DICKMINER trolling from you, which I can honestly claim is false. Now if you said LOL ARTFORZ WROTE A SC2 MINER BY REING SC2 BETA AND GIVES IT TO WHOEVER ASKS... that'd be different. But no one ever came close to that. So, let's play that game in reverse... why didn't any of your guys come up with the trivial optimization of turning the (really expensive on a GPU) 64 bit modulos in SC2s algo into (cheap) 32 bit sum-and-mod with carry? In months? Waaait, let me guess, they're all incompetent ... or they did. But hey, no reason to let those "parasite" miners outside of your inner circle have it, right? |
|
|
|
|
Well, from talking with Ahimoth on btc-e, sounds like mtrlt managed to find a workaround for the issues I was having with scrypt miner kernels on GPU.
Short version... any of my kernels that got speeds like that also got 100% invalids. Yet the same kernel worked fine on CPU or if I dropped global and/or local worksizes to silly small levels... which of course made it dog slow again...
And of course RS turning the whole thing into "OMG CONSPIRACY!!1one"... duh, it's RS.
|
|
|
|
|
What previous posters have said, SuperFlower 80+ gold/platinum platform (which this is...) == kickass
Oh, and WTF is CoolerMaster doing on that list? They have PLENTY of crap in their low-mid range, had a GX750 burn up running 2 5970s...
|
|
|
|
I never detected a 75W surge. I think the "it pulls 75W nonsense" comes from the fact that the spec allows UP TO 75W. Some cards might pull 75W (probably ones with either supplemental power connector) but the 5970 doesn't. The max I got was ~30W and that only occured a few seconds after mining started. I measured it for about a minute or so and it remained in the 27W-30W range.
Actually at startup it only pulled about 12W from the slot. By the PCIe spec only PCIe 16x devices can pull >25W only once they have been identified (via bus interrogation) as high current device. No device is allowed to pull >10W until identified. I guess the card with 12W @ the slot @ startup was slightly over spec.
True for mining. Now measure slot 12V current while actually doing something that gives the memory a workout, you'll be surprised  |
|
|
|
The problem comes from manufactures no following the specs. A 20 pin mobo connecter should be able to supply 75w total to all the PCIe slots, 24 pin is 150w total. Reference GPU cards are designed to pull no more than 25w from the PCIe slot.
What  I thought they pulled 75W from the slot. They aren't "supposed" to. But some do. And one reason why you get burned up mobo connections. Most common cause is a loose connection though. That causes a reduction in the cross section available to the current, causing overheating, and in worst case senarios, arcing, sparking, and fires.  Says who? Check PCIe CEM spec section 4.2.4, then claim that again. |
|
|
|
|
So far haven't heard of problems with < 4 single GPU or 3 dual GPU cards, and considering 2 single cards is a normal SLI/Xfire setup, I'd think we'd see plenty complaining in gamer forums if it'd cause problems.
|
|
|
|
So, the algorithm is fine as it is. If you increase the amount of memory required, you end up with a GPU-favoured implementation of scrypt.
I don't understand this line but the rest of your post is a welcomed commentary that I do intend to provide counter-arguments for. I would assume that the more memory required the *less* feasible GPU mining became. For instance you could (if artforz released the code) mine scrypt coins with a GPU but it would be so inefficient that you might as well just mine them with the CPU. My understanding is that increasing the amount of memory required further would make GPUs even more pitiful. If you kept increasing the memory required CPU's would decrease in hash power. Some CPU's with smaller and or slower amounts of cache (or inefficient cache usage) would fail to keep up. This would push innovation to improve memory management in CPU's as people try to design ways to make CPU's address large cache sizes faster or make more efficient use of L2 and L3 cache. We would first see more efficient mining software just as people keep improving the existing scrypt miners but ultimately we would be pushing for CPU's that are continuously improving at memory hard math. Although you argue it is difficult to make large amounts of cache easy to address there is room for competition and innovation in this area as people push the boundaries on what is possible with the CPU. Yes it sounds like a lot of very difficult work I agree but that's the whole idea. It is a speculation market for emerging CPU technology. Short version: compared to (1024,1,1) increasing N and r actually helps GPUs and hurts CPUs. Longer version: While things are small enough to fit in L2, each CPU core can act mostly independently and has pretty large read/write BW, make it big enough to hit external memory and you've got ~15GB/s shared between all cores. Meanwhile, GPU caches are too small to be of much use, so... with random reads at 128B/item a 256 bit GDDR5 bus ends up well < 20% peak BW, at 1024B/item that % increases very significantly. end result, a 5870 ends up about 6 times as fast as a PhenomII for scrypt(8192,8,1). (without really trying to optimize either side, so ymmv). The only way to make scrypt win on CPU-vs-GPU again would be to go WAAAY bigger, think > 128MB V array so you don't have enough RAM on GPUs to run enough parallel instances to mask latencies... but that also means it's REALLY slow (hash/sec? sec/hash!) and you need the same amount of memory to check results... Now who wants a *coin where a normal node needs several seconds and 100s of megs to gigs of ram just to check a block PoW for validity? |
|
|
|
My early LX150 miner prototypes had a 60A switcher for vccint for 8 chips -> 7.5A each... and that later turned out to be not enough.
So, how come the German guy (Stefan) of ZTEX gets by with a [very compact] 8 Amp converter for VCCINT? His dynamic clocking now achieves > 200 MH/s on a -3 device. Impressive. (Even more impressive considering the fact that he has less than half of the Xilinx-mandated amount of bypass capacitors surrounding the Spartan-6.) Btw, one thing that made me go WTF when looking at interior pics of copacobana a few years ago... a single massive AC->1.2V converter for vccint and really heavy cables + busbars to route it around...
Here's a picture: http://www.copacobana.org/photos/photo_b4.jpgWell, 7.5A/core was ok for a 192-205MHz 122-round 2-stage-per-round pipeline design. Just my later designs needed more power. Also, unless I misremember, he uses ultra-low-esl 0306 caps for vccint, xilinx recommended #s are for caps with ESL values similar to 0402s... so... prolly fine. Yep, that's the picture... Still don't get why on earth they did it that way. A AC->12V PSU and half a dozen or so point-of-load converters would've saved a whole lot of copper (and prevent accidentally welding holes in your chassis...) |
|
|
|
Yeah. Considering that FPGA are less likely to die than your GPUs and you got a clear winner. FPGA FTW !
Highly unlikely. GPUs are extremely reliable. They have several temperature monitors and will down-clock when they detect overheating. FPGAs? Nada. If you have any cooling issues (fan stops, etc) with an FPGA it'll fry itself before you know it. FPGA also are less tolerent of thermal stress (heat). You can get away with a GPU hitting 110C+ for a short period of time. I wouldn't recommend it but it is unlikely you will kill it. An FPGA hitting same temps is toast. FPGA are precision equipment generally used in industrial or scientific applications by qualified personnel. GPU are used by complete idiots. GPU are engineered to be as idiot proof as technology will allow. LOL. Priceless. |
|
|
|
First one has a shared 10A reg for 2 LX150s -> max of 5A vccint each. Second has a 12A for 4 LX150s -> 3A each My early LX150 miner prototypes had a 60A switcher for vccint for 8 chips -> 7.5A each... and that later turned out to be not enough. Btw, one thing that made me go WTF when looking at interior pics of copacobana a few years ago... a single massive AC->1.2V converter for vccint and really heavy cables + busbars to route it around... |
|
|
|
with diablo miner im getting 880mh/sec from same cards same speeds
but 388watts at wall I think that's a new record! Sorry if that wasnt clear, but my MSI 7970 runs way to hot to overclock it, even undervolted at stock speeds it sits at 79C my 5870 sits at 67C (though I had to replace thermal paste to achieve this). Unless there is some way to get my 5870 to use SDK and my 7970 to run on SDK 2.6 at the same time, my 5870 isnt running at optimal speed. Currently im pulling 968mh/sec 415 watts total. 6550@650mhz 5870@885mhz and 7970@925mhz You either got a bad card or some seriously bad case airflow there... 0. SI TAHITI XT (:0.0) engine clock 1170MHz, memory clock 1070MHz, core voltage 1.17VDC, performance level 2, utilization 99% fan speed 43% (2408 RPM) (default) temperature 72 C Powertune 10% |
|
|
|
|
Okay, let me explain it again in SMALL WORDS.
VDDCI is memory controller voltage. Not memory voltage.
Memory voltage (MVDDC/MVDDQ) is from the 2 non-software-controllable VT243s (VT237s on 5970s).
Non-software-controllable. As in "needs hardmod to change".
now, on to VDDCI, which *is* software controllable on reference 5870s and 5970s.
It's already possible to play with it in linux with a trivial modification to radeonvolt as it's a vt1165 like VDDC, just at i2c addr 0x71 instead of 0x70.
So... how much power can you save lowering it? on a 5970 mining @ 300 memclock, reducing it from 1.05 to 0.90 drops total power/card by ~ 1W...
Yeah.
|
|
|
|
on ref 5870 that VRM slave with a missing brother in the top left is the VDDCI, its vt1165 controller is in the extreme top left corner. memory VDD is the 2 above the missing 5th VDDC phase on the right (looks like those 2 are actually set up to run as a 2-phase... hard to tell from tiny pics) on nonrefs... well, anything can be anywhere edit: nope, those 2 are 2 single vt243s, most likely memory VDDC and VDDQ Yes I am interested in this VRM. What does it do exactly ? It's the VDDCI VRM. it does VDDCI  Seriously, VDDCI = "uncore" ... as far as I can tell it's PCIe and memory controller core voltage. |
|
|
|
with diablo miner im getting 880mh/sec from same cards same speeds
but 388watts at wall I think that's a new record! Oh man. Thats over twice as fast as my 5850 at 960. Read carefully, that's a 5870 *and* a 7970... 880Mh is awful. 7970 is ~550Mh/s stock 5870 is ~380Mh/s stock so that's > 5% slower than what they should be doing... |
|
|
|
on ref 5870 that VRM slave with a missing brother in the top left is the VDDCI, its vt1165 controller is in the extreme top left corner. memory VDD is the 2 above the missing 5th VDDC phase on the right (looks like those 2 are actually set up to run as a 2-phase... hard to tell from tiny pics) on nonrefs... well, anything can be anywhere edit: nope, those 2 are 2 single vt243s, most likely memory VDDC and VDDQ |
|
|
|
A little more VRM pr0n.  If you look closely, you'll find several more VRMs on the 5970 first the obvious ones: VRM1 area = VT1165 + 3 slaves, GPU1 VDDC (i2c slave addr 0x70 on gpu1) VRM2 area = VT1165 + 3 slaves, GPU2 VDDC (i2c slave addr 0x70 on gpu2) the square chip at the top/right of vrm2 area = another vt1165 controller, belongs to the 2 slaves above the VRM2 slaves, it's a 2-phase providing both GPUs VDDCI (i2c slave addr 0x71 on gpu1) now, there's avolterra integrated controller (vt237) top/right of the 1 of "VRM1" and another vt237 under the R of "VRM2" I suspect those 2 guys are our memory VCC (one for each GPUs memory?). now on to the non-volterra stuff a AOZ1024D above the VDDCI inductors and output caps... no clue. the 2 FETs below the GPU2 memory chips/left of the suspected GPU2 memory VRM, controller is a uP6101 on the backside ... again, random aux supply. that should be it for major switchers, there's probably another 3 or 4 linear regs strewn about... |
|
|
|
More SolidCoin monetary policy... nice! Horray for early adopters! Wasn't SolidCoin supposed to NOT award early adopters?
No, it's always been at war with Eurasia. |
|
|
|
...
So, basically it is safe to say the 7970 is solidly more efficient, but not a quantum leap. Fair?
Well a quantum leap is the smallest possible change, so... it's a quantum leap Honestly, for mining I'd prefer 5970s. At least until we get 7990s. What's somewhat surprising is what a power hog a idle 5970 is, didn't quite expect it to be *that* bad. |
|
|
|
|
all on the same rig
PhenomII @ 1GHz, PSU is the same SF 80+ gold as used before
5970, linux amd64, cat 11.12, sdk2.5
idle @ 0.95V/157/1000, 182W
idle @ 0.95V/157/300, 152W
idle @ 0.95V/157/150, 149W
cgminer @ 1.05V/820/300, 377W, 761Mh/s
cgminer @ 1.05V/600/150, 308W, 542Mh/s
cgminer @ 1.00V/600/150, 291W, 542Mh/s
cgminer @ 0.95V/600/150, 273W, 542Mh/s
7970, linux amd64, cat 11.12, sdk2.6
idle @ 0.85V/300/150, 115W
idle @ 1.175V/300/150, 132W
idle @ 1.175V/1150/1070, 168W
phoenix @ 1.175V/1150/1070, 363W, 676Mh/s
phoenix @ 1.175V/1150/1375, 370W, 676Mh/s
phoenix @ 0.85V/300/200, 154W, 178Mh/s
7970, windows 7, cat 11.12 7970 edition, sdk 2.6
screen off for a bit,102W
idle @ 0.85V/300/150, 114W
idle @ 1.175V/925/150, 142W
idle @ 1.0V/925/150, 128W
phoenix @ 1.0V/925/150, 235W, 535Mh/s
phoenix @ 0.95V/925/150, 222W, 535Mh/s
phoenix @ 0.92V/925/150, 217W, 535Mh/s
phoenix @ 1.175V/1150/150, 328W, 659Mh/s
phoenix @ 1.175V/1150/300, 339W, 666Mh/s
phoenix @ 1.175V/1150/1070, 368W, 674Mh/s
2MB PCI S3 VGA card, linux
idle 101W
so let's run some numbers, using 0.95V as undervolt for 7970...
whole system:
max OC @ stock V: 5970 2.02Mh/J, 7970 2.01
undervolted: 5970 1.99Mh/J, 7970 2.41
assuming system is 100W (well, more or less...)
max OC @ stock V: 5970 2.75Mh/J, 7970 2.89
undervolted: 5970 3.13Mh/J, 7970 4.39
bullshit calc (aka simple load - idle)
max OC @ stock V: 5970 3.38Mh/J, 7970 3.07
undervolted: 5970 4.37Mh/J, 7970 4.95
|
|
|
|
Im talking total power draw measured using a kill-a-watt. You figure in the ineffeciency of the PSU, HDD, and the mobo, you will see around 50 watts.
PSU? What else are you going to run your FPGAs off of? A few dozen <75% efficient chinese wall warts? HDD? USB stick or CF card in PATA adapter. Even a 7.2k 2.5" is <1W spinning. Mobo? I give you that, 3.5W vs. 20W peak ... So we're talking about 430 vs 450W for 10Gh with S6s, 23.3 vs. 22.2 Mh/J ... not exactly a massive deal. For something with efficiency similar to BFLs vaporboards, it's even less of a difference, 2-3% max. Now, what something like a pi does have going for it is power (see above, not *that* big of an issue), cost and size. = A lot cheaper, and way easier to tuck into a corner somewhere. Benefits of a generic x86 ... can install any random OS, way easier to set up a full dev toolchain without having to fiiddle with crosscompiling, > 256MB RAM. Also potentially a lot faster and has GigE (somewhat pointless here...). So yeah, if I wanted to build a few dozen 10Gh rigs something like the pi as a controller would make sense... for a one-off... too much work, just slap a x86 in. |
|
|
|
|
Show Posts
