What I really worry about, is that new hardware will continue to come out frequently enough that people end up on a cycle of investing in hardware that basically never pays itself off as slightly newer hardware and higher diffs keep coming out. Sure at some stage the limits of technology will be reached, but given the best tech at the moment is going to be 65nm ASICs when CPUs are 28nm devices, I can see the cycle going on for some time, and then even if btc mining ASICs end up in line with CPU manufacturers, they still continue to evolve over time. Dramatic profits from ASICs will likely only last a couple of weeks at most for a lucky few. The rest of you who paid for devices that don't even exist yet will not be making any magical profit no matter how big the hashrate appears. Your proportion of the total bitcoin hashrate will remain pitiful.
Sigh...
There's definitely some merit to this, but remember, the exact same thing happens with Video Cards, every 9-12 months the new GPU cards hit the market and are more efficient at mining. Of course video cards are much less expensive than the current round of ASIC's and can be resold. The resale and multipurpose nature of them is what makes the equation so different though. My 7970s are selling for more than half of what I bought them for. Though I had to invest the money in the first place, there is still that extra return on selling them at the end, provided you don't try to keep them forever. |
|
|
|
Hmm. So cgminer tries GBT first, and if it sees no Stratum header it stays on GBT?
In order of priority, cgminer will try to mine on stratum first, gbt second and getwork if all else fails, based on what order I think mining should occur. As far as I'm concerned, it's up to the pool operator to decide what they think is most important to prioritise. If you want to put a stratum redirect header in your GBT based pool, that's entirely your choice, knowing that cgminer will then use stratum preferentially. You can see the way cgminer prioritises the different protocols based on what I think is best for miners and pools, and the rest is up to you. |
|
|
|
|
I've always thought FPGAs were a waste of money. Assuming ASICs come in the next 2 months, indeed hardly anyone would have made a return on investment with FPGAs yet they will find themselves with devices that have no other realistic useful purpose - AKA doorstops. I have never spent a cent on FPGAs, do not own one, and have only gotten involved with their development when no one else could find solutions to awkward problems with them. On the other hand, GPUs have only just fallen below profitability, yet if you factor in resale value for them, they still don't look so bad compared to FPGAs, but mining long term on them seems a waste now. I never once believed GPU mining would die in the face of FPGAs unless the status quo was somehow magically maintained for years which I never believed would happen.
However, ASICs are a totally different ball game. They basically will redefine what mining means with bitcoin, where there is no point mining with anything else if any profit is to be made. They will make GPUs, and even FPGAs, look totally useless to mine with. 1 year from now, absolutely no one will be mining BTC on anything but ASICs, except for newbies to bitcoin mining, who will ask the obvious questions about GPU mining, and still even CPU mining.
I will sorely miss the "anyone can use their spare hardware to mine with" aspect to bitcoin mining. I honestly believe that is more true to the ideal of bitcoin, where everyone running a node was contributing to its security. However, what spare hardware people had has changed dramatically recently anyway as PCs are dramatically on the decline and people move to more portable devices with less CPU/GPU power in the form of tablets and phones etc. Alas the algorithm lends itself really well to ASIC based mining, meaning everything else will be a complete waste of time. Now while cgminer will continue to work on alternate cryptocurrencies, I honestly think all the alternative cryptocurrencies will go nowhere. The only reason to mine them is to find something that can be profitable by converting it to BTC.
Down the track, cgminer will indeed be used mostly to mine with dedicated ASIC hardware to mine BTC. GPU mining for BTC will be as irrelevant then as CPU mining is today. I don't like the fact that the network will be secured with devices from 4 or 5 manufacturers making hardware that serves only one purpose - btc mining. While BTC mining previously was still only in the hands of intel, amd and nvidia, the fact is it was not on their radar at all. Bitcoin mining was a lucky aside they did, where AMD/ATI GPUs happened to do better than anyone else, and anyone with spare cycles on their hardware could choose to contribute and earn a little on the side.
Long term, cgminer will be the lowest overhead c software to drive ASICs to do bitcoin mining, with lots of code in it that is no longer relevant to BTC mining. What I really worry about, is that new hardware will continue to come out frequently enough that people end up on a cycle of investing in hardware that basically never pays itself off as slightly newer hardware and higher diffs keep coming out. Sure at some stage the limits of technology will be reached, but given the best tech at the moment is going to be 65nm ASICs when CPUs are 28nm devices, I can see the cycle going on for some time, and then even if btc mining ASICs end up in line with CPU manufacturers, they still continue to evolve over time. Dramatic profits from ASICs will likely only last a couple of weeks at most for a lucky few. The rest of you who paid for devices that don't even exist yet will not be making any magical profit no matter how big the hashrate appears. Your proportion of the total bitcoin hashrate will remain pitiful.
Sigh...
|
|
|
|
|
I really wouldn't celebrate... all the GPU btc mining escapees will blow your difficulty out of the water killing your mining profit margins. Difficulty is supposed to parallel price. Price does not go up just because miners are driving difficulty up.
|
|
|
|
Please add --no-restart
That way it will not try to restart if it crashes, which is stopping it from dumping properly. Thanks. Does this help? I truncated everything after the #2 because they all (737) said "No symbol table info available." gdb cgminer core.15150
GNU gdb (GDB) Fedora (7.3-43.fc15)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/cgminer...done.
[New LWP 15230]
[New LWP 15205]
[New LWP 15158]
[New LWP 15209]
[New LWP 15157]
[New LWP 15150]
[New LWP 15210]
[New LWP 15207]
[New LWP 15202]
[New LWP 15206]
[New LWP 15203]
[New LWP 15212]
[New LWP 15208]
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/3a/8fe6cb0063d56fc9be76ecd085c05f1b8a76e6
[Thread debugging using libthread_db enabled]
Cannot find new threads: generic error
Core was generated by `cgminer -o http://GBTPOOL:GWPORT -O x:y'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000003c6f67e8c1 in strcat () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.23-18.fc15.x86_64 glibc-2.14.1-5.x86_64 keyutils-libs-1.2-7.fc15.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 libX11-1.4.3-1.fc15.x86_64 libXau-1.0.6-2.fc15.x86_64 libXext-1.2.0-2.fc15.x86_64 libXinerama-1.1.1-2.fc15.x86_64 libcom_err-1.41.14-2.fc15.x86_64 libcurl-7.21.3-11.fc15.x86_64 libgcc-4.6.0-10.fc15.x86_64 libidn-1.19-2.fc15.x86_64 libselinux-2.0.99-4.fc15.x86_64 libssh2-1.2.7-1.fc15.x86_64 libstdc++-4.6.0-10.fc15.x86_64 libxcb-1.7-2.fc15.x86_64 mesa-libGLU-7.11-1.fc15.x86_64 ncurses-libs-5.8-2.20110319.fc15.x86_64 nspr-4.8.8-1.fc15.x86_64 nss-3.12.10-6.fc15.x86_64 nss-mdns-0.10-9.fc15.x86_64 nss-softokn-freebl-3.12.10-2.fc15.x86_64 nss-util-3.12.10-1.fc15.x86_64 openldap-2.4.24-3.fc15.x86_64 openssl-1.0.0g-1.fc15.x86_64 xorg-x11-drv-catalyst-libs-11.6-1.fc15.x86_64 zlib-1.2.5-3.fc15.x86_64
(gdb) bt full
#0 0x0000003c6f67e8c1 in strcat () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004093f0 in submit_upstream_work (work=0x7f67e4000c00, curl=0x7f67e400b5f0,
resubmit=false) at cgminer.c:2331
gbt_block = "02000000ca538130d3b31ccc24be835ba05bf2b8c41f8dfe8c112584ca03", '0' <repeats 12 times>, "8d4ca763df01df8377efc6a798d0607e3325259b4923e603308d8237d8ece2b97a22b650eae0041a11865698400100000001", '0' <repeats 64 times>, "ffffffff4b034e34030e"...
varint = 0x3030303030303030 <Address 0x3030303030303030 out of bounds>
header = 0x3136646362313465 <Address 0x3136646362313465 out of bounds>
data = "76a914dcacb1cb4f31a6a3a239ae0199626bce00a72c3788acacc59502000000001976a91428220c"
hexstr = 0x3838376332663736 <Address 0x3838376332663736 out of bounds>
val = 0x3633343139613637
res = 0x3931303030303030
err = 0x3030303030306461
s = "4188acb896", '0' <repeats 12 times>, "1976a914f52651ec8fe199ea975c63fc36369364c31fe80288ac980b", '0' <repeats 12 times>, "1976a9140f9bfe4cfd6c45c623a77d8087982c41a6fef69588ac50a2", '0' <repeats 12 times>, "1976a914cccdfc3b5e7ae849041e954dc48f47b96b2219f4"...
rc = 57
thr_id = 959918646
cgpu = 0x3239333738353534
pool = 0x6465343939663962
rolltime = 1681469798
hash32 = 0x6639313265646462
tv_submit = {tv_sec = 7306075964502533688, tv_usec = 4121744960866432049}
tv_submit_reply = {tv_sec = 4134645543713452080, tv_usec = 3978477492665463857}
hashshow = "ad", '0' <repeats 12 times>, "1976a9141f24c264b0f47ece27326a3905be9b91fd1da97788ac34"
worktime = "ac4c320200000000001976a914bd43b675c496b8b13bde490465ea355a94136faf88acc0543a00000000001976a914bcd6b30774cc7bdcc922e4f1817ca035667b18cd88acd46e1800000000001976a9147cb7a1d86ddddcdc8ef192cbd0bc67a370524b"
#2 0x3931303030303030 in ?? ()
No symbol table info available. It sure does. This bug should be fixed in git now, thanks! |
|
|
|
One question about "Best share:" ... is it working correctly when Solo Mining?
Yes |
|
|
|
In case anyone wants me to try something else... Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run:
gdb cgminer core
bt full
And post the information from that please. I'm getting "No stack." I assume that makes it obvious I've never done this before... ETA: cat /usr/src/cgminer-2.9.5/Makefile | grep CFLAGS\ =
CFLAGS = -I/usr/src/ati-stream-sdk-v2.1-lnx64/include -g Also, FYI, this is the exact error I was getting in 2.9.4 on GBT only: Crashed with signal 11! Will attempt to restart--- Failed to restart, exiting nowing latest version, x86_64 linux, build with -02 -Wall I'm not sure whether the fact that it is also happening on that other miner will make you laugh or cry... Well that's my code so it's no surprise... Please add --no-restart That way it will not try to restart if it crashes, which is stopping it from dumping properly. Thanks. |
|
|
|
|
I for one would be very surprised if every pool survived the block halving unscathed.
|
|
|
|
|
Was this with getwork, gbt or stratum? One thing about share submission for non-stratum on cgminer - it will keep retrying to submit if for some reason the submission failed (server responded with empty reply, busy etc.) until it has deemed there is no chance it is still valid. It retries sending every 5 seconds. Perhaps that is what's going on here? cgminer certainly does throw out all work on a longpoll equivalent, and checks if it should on every "cycle" through the work in GPUs at least.
|
|
|
|
All servers are updated on EMC. I'll be curious to see how it works.
Great! Trying it out now on stratum. Will report back. Half hour of mining with 2.7GH: Accepted shares: 723 Rejected shares: 1 I watched diff go from .99 to 2 and fluctuate frequently during that time and a handful of block changes went by as well. I happened to see the rejected share as well, and it was a diff 1/2 high hash reject. This means diff had risen, and cgminer knew about the rise, but being conservative as per a scenario A described here: https://bitcointalk.org/index.php?topic=28402.msg1357099#msg1357099 cgminer still submitted it. All in all, great stuff. I'm glad to see this issue sorted out for both the pool and the miners. |
|
|
|
I hate to interrupt all of this stratum discussion, but I am having crashes with GBT. Running Fedora 15 with SDK 2.1 I think. 2.9.4 would exit with something like error code 11 (or 15 maybe?), and 2.9.5 segfaults. I don't need GBT, so I should probably try to remember to try --fix-protocol instead of switching back to 2.8.7, but for now, I'm on 2.8.7 again. I didn't report the issue with 2.9.4, but I suppose I should've.
ETA: con, note that I wouldn't be against GBT being scrapped/removed from cgminer based on anything I've seen, but from a userbase standpoint, that might not be the option. I'm only providing this most basic info in case it is helpful in some way.
Debug build would be helpful. If you're running fedora that suggests you're building it yourself. If that's the case, add "-g" to your CFLAGS, rebuild your cgminer 2.9.5 (without stripping the file), enable coredumps with "ulimit -c unlimited" and then run whatever it is that's crashing. Once you get a "core dumped" message at the end of running it, then run: gdb cgminer core bt full And post the information from that please. |
|
|
|
|
Throwing out work with every notify message on stratum, which comes on average every 30 seconds, would have the same effect as a longpoll every 30 seconds. That's a lot of work to discard midstream. Why on earth would there even be a clean_work method with stratum if every notify implied we throw out the work?
|
|
|
|
I believe I've found what the issue is with stratum+emc+cgminer causing lots of rejects. Okay I see the problem here on EMC stratum.
Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.
|
|
|
|
|
Okay I see the problem here on EMC stratum.
Based on a commit luke-jr did to bfgminer, it seems he thinks that new work notification by stratum mandates that all work be thrown out in favour of the new work, because he FORCES the clean flag. However no other pool actually expects this, only forcing a clean when they actually send the work clean message. So I'm going to go out on a limb here and say the problem lies with the implementation of stratum on EMC, as coded up by luke-jr.
|
|
|
|
|
There's something else about stratum on EMC, and that appears to be lots of disconnects? That's another limitation of stratum, that once you disconnect the shares cannot be submitted on reconnect. Slush is going to have to add a reconnect option to it, or any disconnect of the socket will always be associated with shares lost if you're actively mining on it. Certainly it appears to be a combination of things and not just the frequent retargetting, although that is easy to see - the reject will say something like "share above target". "Unknown work" after longpoll is a true stale, work from the previous block. Not sure what's going on with GBT on EMC, but yes the rejects appear higher there too. For the time being you can still mine on getwork with --fix-protocol, but I'd rather see the pool issues sorted out.
|
|
|
|
So the issue with stales on stratum EMC...
Are they actually stale, or is it submitting shares which are below the expected target or something?
I'm getting 1% stale on EMC, and 0.1 on Ozcoin.
This is the issue I've been discussing at length on this thread with Inaba. Yes it's just submitting shares below target after diff rises. Try the EMC GBT server until it's resolved. |
|
|
|
|
7000 cards need SDK 2.6 or later
|
|
|
|
With p2pool having upgrade pains, I've pointed my miners to eclipse and ozcoin respectively. It seems eclipse is shipping me non integer difficulty work, ie, somewhere between 1 and 2. I couldn't tell by the share output, because it always says x/1, but I see this on top: (5s):1.928G (avg):1.963Gh/s | Q:167 A:1075 R:6 HW:0 E:644% U:20.2/m
TQ: 0 ST: 7 SS: 1 DW: 328 NB: 7 LW: 1789 GF: 0 RF: 2 WU: 27.9
The WU is around what I expect U to be when dealing with difficulty 1 work. Am I reading this right? Any change we could get a decimal point or two in the cgminer output to show this?  Not much point when we'll all be mining difficulties in the 10s to 100s soon. |
|
|
|
Ok, if that's the case then that solves the issue. Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?
For scenario A, if the old diff applies to work given out prior to the diff change it's almost the same as tying it with the work, and is how cgminer currently manages difficulty already for rising diff. Scenario C will sort itself out as well. So this works for me. What about if diff drops as in scenario B? Do you credit work to the new difficulty or does the old difficulty still apply? There is still the potential for lost opportunity in scenario D, and this would be no different if difficulty is tied with work or not, with gbt or stratum, as every window lost is the time of a one way trip from the server to the miner. While small, if done often it would start to add up. Thus it would still be prudent to minimise the diff changes to avoid this. |
|
|
|
|
Show Posts
