7970 - ~300w @ (lets say) 600 mh/s.
Huh? I have a single 7970 "space heater" running at 620MHs and drawing 275W at the wall for the entire system. Admittedly the other components are efficient (Sandy Bridge i5, SSD, 80 Plus platinum PS), but still ... Welcome to the world of people tweaking numbers in order to save face in an online argument... No. We used maximum draw per ATI for both cards. Stock no tweaking the 7970 pulls down ~560. You are still wrong. Because the official TDP of the 7970 is 250W. So even when looking at stock numbers, the 7970 is more efficient by ~21%: - 7970: 560 Mhash/s at 250W = 2.24 Mhash/Joule - 5770: 200 Mhash/s at 108W = 1.85 Mhash/Joule If you move the argument to undervolted/fine-tuned settings, or to actual measured power, then the 7970 increases or keeps its lead because, as I pointed out, it doesn't even use close to 250W when mining (only ~200W). |
|
|
|
7970 - ~300w @ (lets say) 600 mh/s.
Huh? I have a single 7970 "space heater" running at 620MHs and drawing 275W at the wall for the entire system. Admittedly the other components are efficient (Sandy Bridge i5, SSD, 80 Plus platinum PS), but still ... Welcome to the world of people tweaking numbers in order to save face in an online argument... |
|
|
|
Yes, me and many people get 650-700 Mhash/s per 7970.
7970 is 32nm. 5770 is 40nm. The 32nm chip is naturally more power efficient.
Also you made the exact mistake I predicted: incorrectly assuming the 5770 draws 0W at idle therefore you think mining only takes 42W. The 5770 actually draws 18W at idle per its specs. That means your card as a whole is closer to ~60W when mining.
Taking into account this 18W baseline load is important when comparing different cards. Or else, imagine if a card was so inefficient that it would draw 100W when idle and 105W when under load. People would be claiming that mining only takes 5W, therefore making it the most efficient card of all!
Argue it anyway you like - you're still incorrect. Measuring at the wall with 3x 5770 and then measuring the same machine with a 7970 instead... will clearly show which is ahead. per specs maximum draw for a 5570 is 108W. Lets use that number. My cards (which are drawing ~75 are getting over 200mh/s). 5770 - 108w @ 200 mh/s. 7970 - ~300w @ (lets say) 600 mh/s. These numbers show I was correct! - the 7970 is more power efficient (in fact a lot more because your numbers are out of whack... at 600 Mhash/s the 7970 draws ~200W -- I measured mine at 193W with a clamp meter). Not sure why you say I was "incorrect"  The difference between the idle draw on the 5770 and the 7970 is 3 watts.
Yes but when you ignore the 18W at idle for the 5770, you ignore 17% of its total power draw, and when you ignore the 15W at idle for the 7970, you ignore 6% of its total power draw. See the difference? 6% vs 17%? This is the significance I am talking about. |
|
|
|
I for example run some fpgas, and a bunch of 5770 (most power friendly mining card there is if you configure it correctly).
Hum, no. A 7970 beats the 5770 any day in terms of Mhash/Joule. It does 3.1 out of the box. 4+ when undervolted/underclocked. If you think your 5770 beats that, you must be incorrectly measuring its power consumption (eg. you measure at the wall and only measure the difference between idle and load, and incorrectly assume the card draws 0W at idle). It's possible I screwed the the math. I'm showing a difference of 42 watts between idle and loaded - with a single 5770. The cards limited to 75w (per ATI). A 7970 is ~200 watts difference between idle and load. (and limited to 250 per ATI). Are you getting 600 mh/s out a 7970? If not then my 5770s are out preforming you and using less power. Yes, me and many people get 650-700 Mhash/s per 7970. 7970 is 32nm. 5770 is 40nm. The 32nm chip is naturally more power efficient. Also you made the exact mistake I predicted: incorrectly assuming the 5770 draws 0W at idle therefore you think mining only takes 42W. The 5770 actually draws 18W at idle per its specs. That means your card as a whole is closer to ~60W when mining. Taking into account this 18W baseline load is important when comparing different cards. Or else, imagine if a card was so inefficient that it would draw 100W when idle and 105W when under load. People would be claiming that mining only takes 5W, therefore making it the most efficient card of all! |
|
|
|
You people haven't even seen a prototype, have seen constant delays with unrealistic timelines, no proof at all that there even is an order at a foundry, and you still fall for these obvious scams every single time.
Oh yeah? Then put your money where your mouth is by betting against "BFL ASIC is real". Right now there are only 50.55 BTC on your side, and it will probably stay here, because you are probably too insecure about your own claims... That bigger idiocy, who does not like the speculation hardware manufacturers does not like the speculation of a bet. And who likes to speculate and make money buying hardware advance also likes to bet on either side of your bet will be okay ... Let TheBible reply. According to him, betting would not be speculation as BFL is "obviously a scam". This applies to tvbcof as well. I expect both of them to stay quiet and come up with some excuse for not betting, even so it would be an "oh-so-obvious" win for them.... |
|
|
|
I for example run some fpgas, and a bunch of 5770 (most power friendly mining card there is if you configure it correctly).
Hum, no. A 7970 beats the 5770 any day in terms of Mhash/Joule. It does 3.1 out of the box. 4+ when undervolted/underclocked. If you think your 5770 beats that, you must be incorrectly measuring its power consumption (eg. you measure at the wall and only measure the difference between idle and load, and incorrectly assume the card draws 0W at idle). |
|
|
|
You people haven't even seen a prototype, have seen constant delays with unrealistic timelines, no proof at all that there even is an order at a foundry, and you still fall for these obvious scams every single time.
Oh yeah? Then put your money where your mouth is by betting against "BFL ASIC is real". Right now there are only 50.55 BTC on your side, and it will probably stay here, because you are probably too insecure about your own claims... |
|
|
|
|
I lowered all my prices. Updated OP:
5970 now $200
7950 now $180
1200W PSU now $180
Mobo/CPU/RAM now $100
|
|
|
|
I found the solution mrb wrote to be a bit confusing, and wanted to clean up this code anyway, so I rewrote all these functions in a hopefully more readable/understandable way for 2.10.0: bfab076d (please excuse the accidental libblkmaker change)Since this change is pretty big, I also (now having a good understanding of the problem) wrote a very simple fix-only for 2.8.x and 2.9.x: 006faac6Obviously this code could very easily result in lost blocks/shares if it malfunctions, so I would very much appreciate anyone familiar with C and/or block hashing and targets to review this code before I release it. At the bottom of each link, there is a place to leave comments - feel free to post your review there, or even add comments/questions inline the code if that seems more appropriate (if you put your mouse over a line, a blue "+" appears to the left of it - click that). Of course, if you don't have or want a GitHub account, feel free to email/PM/post-here any reviews as well. looks fine. I have not had time to review the bigger patch. I see you released 2.10.0, so I will just test it when I have time.. |
|
|
|
|
I was busy this weekend, but I will try to review these patches Monday.
|
|
|
|
|
subSTRATA, that is correct.
More precisely, what was happening is that for shares with a difficulty between 1 and the target, "best share" was reporting them with an incorrect difficulty due to endianness issues. (However shares with a difficulty higher than the target were properly reported.) All in all this was just a display bug. No blocks were lost.
|
|
|
|
|
I confirm the bug. One of my tests shows:
Hash computed by hashtest2():
0000000039d5e400932fef0b1d7cdec1f2833dec594e30ee03252113f03be9b4
Hash computed by regeneratehash():
0000000000e4d5390bef2f93c1de7c1dec3d83f2ee304e5913212503b4e93bf0
regeneratehash() is the one that does not compute it correctly.
But there is a 2nd endianness bug in share_diff() which cancels the bug in regeneratehash (which is why the "best share" is always updated correctly when a new share is found)! This 2nd endianness bug in share_diff() is what causes TNR_HIGH shares to sometimes spuriously increase the "best share" statistic without a corresponding share submitted to the pool.
I have a patch fixing both endianness bugs. I am currently testing it...
|
|
|
|
|
I am reassured the bug seems to be in bfgminer. I may take a stab at a fix this weekend.
|
|
|
|
|
Well the highest share I found in share-logfile is 2.3M which was the value displayed by bfgminer yesterday. But then again, the code path between the moment receiveShare() is called and when it is logged in share-logfile, is quite complex and it is possible to imagine a bug that would cause the shared to be received, but not logged.
I am surprised about these reports of "Best share" possibly displaying incorrect information. I would think this is a dead simple feature to implement, so why would this be buggy?
|
|
|
|
|
Show Posts
