|
The sudden interruption of work when a GPU is running flat out overclocked to the max is a great way of exposing instability, and has been there for as long as I can remember and is nothing to do with how cgminer handles failover, yet has to do with how tightly overclocked the GPUs are. It goes away if you lower the clocks.
|
|
|
|
What would be recommended server behavior in the case that, after authentication, a worker's credentials are no longer valid. For instance due to the password changing, the worker being deleted, the user being banned or the user account deleted.
And does it make sense to implement more commands than the ones in the docs at bitcoin.cz?
I'd say just drop the connection since that would mandate they try to reauthorise. |
|
|
|
|
I suspect all manufacturers will be delivering ASICs within 2 months of each other. I don't expect difficulty to rise slowly at all, nor do I believe BFL will corner the market early on.
|
|
|
|
I tell you, I've been running the numbers, and I'm beginning to wonder if ASIC's are even going to be able to cut the mustard. Figure the most efficient unit announced so far is ASIC at 60 GH/60 Watts for $1,299 and the most powerful per dollar is the BTCGPGA at 72GH/80-120 Watts for $1,069.
So, let's kick in a _conservative_ difficulty increase of 10x, and I say conservative because BFL has already said they have enough orders to bump the network at least that high. With power costs of .10/kwh and a BTC/$ rate of $12.50, the hardware breakeven is:
BFL: 132 Days
BTCFPGA: 88 Days
So at _best_ you're looking at a minimum of 3 months before you can break even, and that's assuming the difficulty doesn't ramp up higher during that time, which is rediculous. I'm beginning to think that if $/BTC doesn't jump drastically or BFL/BFGA don't increase their hashing/watt/$ drastically, you could easily end up in a situation where you never actually break even.
I'm glad others are starting to work this out. Check my post here (which you already responded to): https://bitcointalk.org/index.php?topic=28402.msg1368704#msg1368704I think diff will go up 50x |
|
|
|
|
If ASICs never were to appear, difficulty would readjust for mining to be on the fringe of profitability, as it always does. It's just that difficulty drops take longer than rises by their nature, since it needs to take longer for the usual 2106 blocks for bitcoin to detect that difficulty needs to drop.
|
|
|
|
I'm wondering if there is a way get get cgminer to use GBT with bitcoind (satoshi client), I know bitcoind doesn't support longpoll but it does support coinbase/append which should be enough to use GBT (i'm guessing) but it seems I can only get it to use getwork with bitcoind.
Any ideas? or is this just not possible at this point.
Nope, bitcoind does not support the extensions required by pool mining for cgminer to work with it at this time. |
|
|
|
Interesting. The only thing I can think of that could cause this is trying to submit a share even before gbt is fully set up, or the gbt structures sent by the pool are corrupt somehow. Does this happen shortly after startup? Is the GBT pool somewhere I can test it publicly or is this your custom pool? Thanks. This does happen shortly after startup, and I am only running one 5830, so trying to submit a share that quickly seems unlikely. I only ran it once, though, so not impossible by any means. The pool is the one previously run by he who shall not be named. (aka eligius) ETA, I was running in screen, so I don't know if this is the same error I was getting before. I can tell you that on 2.9.4 it first ran quite a while before crashing, and then crashed on startup when I ran it again, at which point I went back to 2.8.7 (and then when 2.9.5 came out, I got the segfault instead of the error I was getting in 2.9.4 [which I quoted someone else mentioning a few pages back]). That said, 2.9.5 crashed on startup more than once, and this is why I didn't go for a second test run when 2.9.6 crashed at startup. Well the crash is happening in the share submission path, so it must be trying to submit a share. That said, I found something else that might be a problem. Try current git master please. |
|
|
|
4 GPUs on 1 computer, and I've got 1 instance of GPUMiner open using cgminer.
Well I have no idea what GPUMiner is. But 5830's should be getting 300+Mhash/s though. I spoke too soon...all 4 of my 5830s are averaging 220 MHash each now, and they aren't overheating because the temp is only 60c for each of them Sigh...so frustrating, maybe its time to finally quit after mining for 1.5 years. All because I decided to switch to new version of GUIminer with cgminer. I used to use old guiminer version + phoenix Can't really debug it with guiminer in front of it. Try cgminer direct. |
|
|
|
And another (this in 2.9.6): $ gdb cgminer core.29958
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.
Missing separate debuginfo for
Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/3a/8fe6cb0063d56fc9be76ecd085c05f1b8a76e6
[Thread debugging using libthread_db enabled]
Core was generated by `cgminer -o http://GBTPOOL:GWPORT -O x:y'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000003c6f67abcc in free () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.14.1-5.x86_64 krb5-libs-1.9.1-5.fc15.x86_64 libcurl-7.21.3-11.fc15.x86_64 libgcc-4.6.0-10.fc15.x86_64 libssh2-1.2.7-1.fc15.x86_64 libstdc++-4.6.0-10.fc15.x86_64 mesa-libGLU-7.11-1.fc15.x86_64 nspr-4.8.8-1.fc15.x86_64 nss-3.12.10-6.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 0x0000003c6f67abcc in free () from /lib64/libc.so.6
No symbol table info available.
#1 0x00000000004093d9 in submit_upstream_work (work=0x7fa534000b10,
curl=0x7fa5340014a0, resubmit=false) at cgminer.c:2336
gbt_block = 0x3966373762363563 <Address 0x3966373762363563 out of bounds>
varint = 0x6663336638373135 <Address 0x6663336638373135 out of bounds>
data = "\002\000\000\000H\005\321\\\207\366\271\256[\254\311A\200\251\372s\311\350S\234\246\264\345\322\337\003\000\000\000\000\000\000\232\313W\272\233 \r\203-\375P\006N\222\255\062\025\204\252Z\226\230\205\233s\254b1\002\251\367_UÕ»P\352\340\004\032\071\356\234\033"
hexstr = 0x3739313030303030 <Address 0x3739313030303030 out of bounds>
val = 0x3335363632353435
res = 0x6634613266623831
err = 0x3966376163613262
s = "{\"id\": 0, \"method\": \"submitblock\", \"params\": [\"020000004805d15c87f6b9ae5bacc94180a9fa73c9e8539ca6b4e5d2df03", '0' <repeats 12 times>, "9acb57ba9b200d832dfd50064e92ad321584aa5a9698859b73ac623102a9f75f55d5bb50eae0041a39ee"...
rc = 55
thr_id = 808464481
cgpu = 0x3135636361383833
pool = 0x3435653636343365
rolltime = 0
hash32 = 0x3139613637393130
tv_submit = {tv_sec = 0, tv_usec = 0}
tv_submit_reply = {tv_sec = 0, tv_usec = 0}
hashshow = '\000' <repeats 67 times>
worktime = '\000' <repeats 199 times>
#2 0x6461393935383765 in ?? ()
No symbol table info available.
<snip>
#90 0x0000000000424eba in sha2_update (ctx=Cannot access memory at address 0x653561383730341d
) at sha2.c:259
fill = <error reading variable fill (Cannot access memory at address 0x653561383730342d)>
left = <error reading variable left (Cannot access memory at address 0x6535613837303431)>
Cannot access memory at address 0x653561383730343d
(gdb) Interesting. The only thing I can think of that could cause this is trying to submit a share even before gbt is fully set up, or the gbt structures sent by the pool are corrupt somehow. Does this happen shortly after startup? Is the GBT pool somewhere I can test it publicly or is this your custom pool? Thanks. |
|
|
|
So current miners try GBT first, and if it has a Stratum HTTP header they switch to Stratum.
I have no idea how it works with GBT in miners. That X-Stratum is for getwork protocol... GBT is all done in http so the headers can just as easily contain x-stratum as getwork does, and cgminer will still switch to stratum if it finds the header in gbt comms. |
|
|
|
|
New version - 2.9.6, 2nd December 2012
Minor bugfixes.
Human readable changelog:
Fixed further crashes with GBT mining.
Scrypt mining now shows more of the relevant hash portion and higher diffs than just 65.5k.
Full Changelog:
- Make gen_stratum_work more robust by using a dynamically allocated array for
the header in case bogus data is sent by the pool to avoid overflowing a static
array.
- scrypt_diff now returns a uint64_t
- Support monitoring and reporting much higher diffs for scrypt mining,
truncating irrelevant zeroes from displayed hash.
- Pass ostate values around in scrypt to be able to extract full hashes if
needed later on.
- Since we will be using calloc_str to put a string into it, convert the
function to calloc_strcat which does it automatically.
- Revert "Handle crash exceptions by trying to restart cgminer unless the
--no-restart option is used."
- Count longpoll and GBT decodes as queued work since the count otherwise
remains static.
- Use the string helper functions to create gbt blocks of any length.
- Provide helper functions calloc_str and realloc_strcat to create and extend
arbitrary length arrays based on string length.
|
|
|
|
|
There was a huge spike in hashrate just before the block halving as people tried to get the "last block" and the "first block" and then that stopped. Since then, the hashrate is pretty close to what it was before the spike. What's actually happening is the vast majority of miners are still hanging in there. It will just take time for the reality of mining at a loss to get through to them. There are an awful lot of miners that are just hopeful the value will go up, and there are still a heap of miners who honestly don't even know the reward has halved. It will just take time for the new steady state to be reached, but by then ASICs will have honest and truly hit, so there may well be no significant drop in hashrate at any stage. Don't underestimate the power of inertia on human nature.
|
|
|
|
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.
And as expected, difficulty has now been driven past the point of profitability in no time  |
|
|
|
|
LTC just died in the arse as a bunch of GPU miners jumped on board for a bit and pushed difficulty beyond profitability. I did warn them that the BTC halving would hurt LTC but they saw more people mining as a good thing. The LTC fanboys thought that more people mining would somehow magically drive LTC prices up when there is no such mechanism.
|
|
|
|
Been having random crashes ever since I upgraded to 2.9.5 from 2.4.x. My install is 1½ years old Ubuntu 11.04, with 11.6 drivers and 2.4 SDK I believe. Runs fine for a day or so, and this happens on both a 4x 5970 machine and a 5x 58xx one.
It screws up the screen output a bit when it crashes, and looks like this:
Any ideas? Should I just downgrade back to 2.4 as that seemed to work, I mainly updated due to stratum but I suppose that's not really necessary atm.
Absolutely do not downgrade please. Are you running with a pool, backup or otherwise, with GBT at all? There is still one bug when mining on GBT which is only fixed in git. Alternatively run a debug build with core dumps enabled and get a backtrace if you know how. Sorry, I'm pretty much clueless around linux/cgminer  Primary pool is eclipse (GBT), secondary is btcguild with Stratum. EDIT: It seems git has a newer version, will try if that helps. Yes please try the git version then since you have a gbt pool. I also recommend connecting to EMC's stratum pool instead. |
|
|
|
Been having random crashes ever since I upgraded to 2.9.5 from 2.4.x. My install is 1½ years old Ubuntu 11.04, with 11.6 drivers and 2.4 SDK I believe. Runs fine for a day or so, and this happens on both a 4x 5970 machine and a 5x 58xx one.
It screws up the screen output a bit when it crashes, and looks like this:
Any ideas? Should I just downgrade back to 2.4 as that seemed to work, I mainly updated due to stratum but I suppose that's not really necessary atm.
Absolutely do not downgrade please. Are you running with a pool, backup or otherwise, with GBT at all? There is still one bug when mining on GBT which is only fixed in git. Alternatively run a debug build with core dumps enabled and get a backtrace if you know how. |
|
|
|
Thus, all the efforts now for cgminer development should be in the direction of LTC (scrypt)  I only work on something if there's an incentive of some sort. |
|
|
|
cgminer version 2.9.5 - Started: [2012-11-30 18:39:27]
--------------------------------------------------------------------------------
(5s):0.000 (avg):0.000h/s | Q:9 A:0 R:0 HW:0 E:0% U:0.0/m
TQ: 0 ST: 12 SS: 0 DW: 5 NB: 2 LW: 20 GF: 1 RF: 0 WU: 0.0
Connected to coinotron.com with LP as user Nolo.5
Block: 2eee5f52bb986e0aa827f861... Started: [18:39:30] Best share: 0
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S ]ettings [D]isplay options [Q]uit
GPU 0: 51.0C 1216RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 1: 44.5C 1244RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 2: 39.0C 1237RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
GPU 3: 39.5C 1270RPM | OFF / 0.000h/s | A:0 R:0 HW:0 U:0.00/m I:18
--------------------------------------------------------------------------------
[2012-11-30 18:39:27] Thread 1 being disabled
[2012-11-30 18:39:28] Error -5: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
[2012-11-30 18:39:28] GPU 2 failure, disabling!
[2012-11-30 18:39:28] Thread 2 being disabled
[2012-11-30 18:39:28] Error -5: Enqueueing kernel onto command queue. (clEnqueu
eNDRangeKernel)
[2012-11-30 18:39:28] GPU 3 failure, disabling!
[2012-11-30 18:39:28] Thread 3 being disabled
[2012-11-30 18:39:30] LONGPOLL from pool 0 detected new block
What does this error -5 mean?
#define CL_OUT_OF_RESOURCES -5 Combination of your current graphics requirements and your choice of settings for your hardware is too high. |
|
|
|
CGMiner attempting undesired conection to IP in Germany on every primary pool fail. Dare to "explain" it a bit?  You sir, imply some very serious allegations and I suggest you consult your lawyers before posting such drivel before I sue you for libel. You are connecting to 50BTC.com and this is what 50BTC is sending you: [2012-12-01 09:29:51] HTTP hdr(X-Long-Polling): http://5.9.207.236:8331/LP That address is where 50BTC's longpoll comes from. If you don't want to connect to there, use a different pool. |
|
|
|
|
Show Posts
