so i didn't go to bed  found your bug cgminer.c:4519 memcpy(work->target, target, 256); 256 should be 32 (or 33?? prob not) now i can sleep Very good, thanks! Fixed in git and hopefully fixes the problem for those who have it. |
|
|
|
[2012-10-05 01:35:29] Submitting share 4170db0c to pool 0
[2012-10-05 01:35:29] SEND: {"params": ["xxxx", "", "n", "2024", "229896f9"], "id": 4, "method": "mining.submit"}
[2012-10-05 01:35:29] Popping work to work thread
[2012-10-05 01:35:29] Generated stratum merkle cc95510e6a4e1827a0a827e526a655483ffdc1a147ab0e2395adf625e00aed50
[2012-10-05 01:35:29] Generated stratum header 00000002e9e9f48adc78181008747a20018b4286890db02aee4afe2d000000c500000000cc95510e6a4e1827a0a827e526a655483ffdc1a147ab0e2395adf625e00aed50506e9bc21a057e0800000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
[2012-10-05 01:35:29] Work job_id 1b84 nonce2 06000000 ntime 506e9bc2
[2012-10-05 01:35:29] Generated target ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000
[2012-10-05 01:35:29] BFL1: block data: c68555222103a5e1c6078755fc8fc3624de3e5f84c81d6624d5e6afb14bbb2dee00aed50506e9bc21a057e08
[2012-10-05 01:35:30] Failed to recv sock in recv_line
no error in the response (RECVD) this time, but still get the repeating "Failed to recv sock in recv_line" Sent message is still corrupted, though job_id, nonce2 and ntime are all intact earlier on. Can you git pull and try again please. |
|
|
|
[2012-10-05 00:49:01] SEND: {"params": ["xxxxx", "", "sh/", "", "bae154a2"], "id": 6, "method": "mining.submit"} Interesting, extranonce2 is coming up blank. Can you git pull and try again? |
|
|
|
pulled the latest changes now debug output keeps repeating [2012-10-05 00:29:36] Failed to recv sock in recv_line
Can you give us the leadup up to the first time you see that message when you have the debugging options --verbose -D -P -T please |
|
|
|
Kaerf, what version of linux/architecture are you on?
heh....a ghetto old ubuntu 9.04 32bit intel atom netbook :p Hmm... can you try the latest git changes to the stratum branch then? |
|
|
|
Stratum update The code has been in testing for a while now, and numerous issues have been ironed out. I've been mining with it for a few days in a mixture of regular pools + stratum pools and things seem to working out okay. I've just managed to get it building and working on windows and have created the first binary for people to start testing it. It's still not mature enough for a full release, but at some stage I need people to start testing it so I can sort out issues as they arise. If you're on linux, and can use git, checkout the stratum branch and build from that. git pull -a && git checkout stratum For those on windows, here is a test binary. http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeJust drop it into your existing 2.7.6 directory. It will still read version 2.7.6, but don't let that fool you. For stratum to be active, you need - of course - to mine on one of the 2 pools that currently support it: slush's pool and btcguild . The way I've set up the code, you shouldn't need to do anything special to mine stratum, just use your regular settings (or you can plug in the stratum info directly if you're so inclined). The advantages to the miner should be far far less network communications with less network delays which should also translate into less rejects. Of course the real advantage is to the pools and for the ability to scale to much higher hashrates with the advent of ASICs. Lots has been written about it here (though it may be rather confusing): https://bitcointalk.org/index.php?topic=108533.0EDIT: There is NO proxy support whatsoever for stratum at this stage.Updated the codebase, and uploaded another windows test binary. It now uses curl for its sockets which allows at least socks proxies to work. http proxies are tricky since you'd need a proxy with special permissions to allow such an arbitrary connection. |
|
|
|
Leakage question...
I'm mining with cgminer with 2 workers one on ubuntu 12 and the other on windows 7 and I see the same odd behavior on both...
I've got 2 pools configured as failover (I did not choose load balance or rotate or anything like that), and about 80% of the time I see "leakage" over to my secondary pool! Weird.
I'm mining at 4500Mh/s at bitminter (2 workers) with no overt pool switching--either automatically or by my choice. I keep it steadily pointed at bitminter....But most of the time I'm seeing about 14Mh/s coming from my 2 workers to Mtred--my secondary pool!
I see no indication of this in either worker's console--they both look solidly connected to bitminter. I don't have any connection errors or slow communication or anything. Everything looks great except there's 14Mh/s leakage to Mtred from both workers.
What gives?? Any ideas?
Read the readme faq |
|
|
|
Interesting behavior/question with stratum version..
On my test machine, I have pools set up the following way:
0 - stratum proxy
1 - btcguild #1
2 - btcguild #2
3 - btcguild #3
cgminer talked to pool0 (the proxy) and immediately punched right through to the real IP address for the stratum server, not using the proxy any more.
So should bypass the proxy when it sees the header, or should it stay pointed there? (IE what if the stratum server is diff hostname/IP than the configured pool?)
(as a side note, it immediately reduced all 4 pools to a single IP address, based on the headers it received from each server, since btcguild only has 1 stratum server today, but that will change has they add more)
Right, a question without an obvious answer. The point of the stratum header on the regular getwork pools is to redirect them to a better protocol pool. The fact that btcg redirects all pools to the same one stratum pool is more a sign of early days with btcg having only one stratum server. I'm guessing with time btcg will have 3 stratum servers to match its 3 getwork servers. |
|
|
|
just checked debug output and it keeps saying: [2012-10-04 14:13:27] Failed to parse a \n terminated string in recv_line
I have the same, looks like there's some issue with Stratum+BFL. I don't think that's it. Others have used this with BFL devices. Something else is trashing buffers somewhere for your setup, I just haven't found where or why yet. In your case slush, you are on ARM architecture so there are even more issues to deal with. Kaerf, what version of linux/architecture are you on? |
|
|
|
Stratum update
<snip>
If you're on linux, and can use git, checkout the stratum branch and build from that.
git pull -a && git checkout stratum
Grabbed, compiled, playing with it on a single machine. (wish it had a subversion# or something so I'd know which was running..) Didn't change a single line of my config file, and it's working for multiple host entries and pools, including moving away from the stratum proxy directly to the stratum pool. Too soon to tell if there are any issues, but I'll let you know. Thanks again for all your hard work! btw, what happens if stratum+tcp fails.. does it drop back to http or eliminate the pool# alltogether? Thanks. At the moment it only tries to use stratum+tcp if the pool supports it. I'll probably try to make it fall back to whichever works if I can. |
|
|
|
Stratum update The code has been in testing for a while now, and numerous issues have been ironed out. I've been mining with it for a few days in a mixture of regular pools + stratum pools and things seem to working out okay. I've just managed to get it building and working on windows and have created the first binary for people to start testing it. It's still not mature enough for a full release, but at some stage I need people to start testing it so I can sort out issues as they arise. If you're on linux, and can use git, checkout the stratum branch and build from that. git pull -a && git checkout stratum For those on windows, here is a test binary. http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeJust drop it into your existing 2.7.6 directory. It will still read version 2.7.6, but don't let that fool you. For stratum to be active, you need - of course - to mine on one of the 2 pools that currently support it: slush's pool and btcguild . The way I've set up the code, you shouldn't need to do anything special to mine stratum, just use your regular settings (or you can plug in the stratum info directly if you're so inclined). The advantages to the miner should be far far less network communications with less network delays which should also translate into less rejects. Of course the real advantage is to the pools and for the ability to scale to much higher hashrates with the advent of ASICs. Lots has been written about it here (though it may be rather confusing): https://bitcointalk.org/index.php?topic=108533.0EDIT: There is NO proxy support whatsoever for stratum at this stage. |
|
|
|
I think I must just have the wrong combination of AMD Linux drivers and ADL SDK. I cannot break the 150 MHz below core barrier, or change core voltage..
Any program setting the clocks through ADL cannot go lower than 150 below the core speed. You need a program that uses unofficial overclocking methods, which are all pretty much Windows only. I could be wrong, but if you want lower memory speeds and/or undervolting, you can't use Linux. You are correct. |
|
|
|
|
Slush, the miners are concerned about the potential losses by moving to stratum as well as the gains. The miners know about the possible gains and are querying the possible losses. While I will do whatever I can within the mining software to minimise these, you need to explain why this compromise is there as you are trying ultimately to convince miners to move to this protocol.
|
|
|
|
Scrypt mining is still broken in that it can not utilize high thread concurrencies (I need to use a thread concurrency of 24000 for my 7950s to mine effectively). The bug seems to be with the calculation for memory allocation. It can be easily duplicated by setting the thread concurrency above 8192, eg 12288. In reaper, any thread concurrency may be used as long as it is a multiple of 64 and produces a memory padding that fits within the card's memory space.
Using "set GPU_MAX_ALLOC_PERCENT=100" in Windows allows the program to run, but it doesn't hash at all and does not create a memory pad on the GPU.
I reported this several weeks ago and it still hasn't been addressed.
That's cause I have no idea what the problem is. Setting GPU_MAX_ALLOC_PERCENT does nothing on windows, only linux. |
|
|
|
If you use cgminer and set solo mining as your first pool and set up a real pool which has longpoll as your 2nd pool, cgminer will use the longpoll from the backup pool to help speed up block change on the solo mining.
Does this work both ways with cgminer? Can I have my main pool as the first pool and solo mining as a backup pool? Yes. |
|
|
|
Can you track down which version did *not* have this problem? cgminer only, please.
Will be happy to look into that more but so far it has seemed to be occouring independant of what version I run of either . I tried your suggestion and jumped to another pool and I am at a:276 with only r:5 and those were all prevhash-stale. So it may be pool dependent, I even have I=18 right now and no issues with rejections. In that case it might actually be the pool's fault setting a high rolltime and then rejecting the shares as late. |
|
|
|
Is this new? If so, can you pinpoint which version it started from? If not, is it unique to lc.ozco.in ?
Fairly recent yes. https://dl.dropbox.com/u/7490029/log2.txt Log file with debug turned on. I haven't tried another pool lately, will try that now. As for version I had been running bfgminer, all the way up to 2.8.1 was getting the error so switched back to cgminer then have tried cgminer 2.7.5. Can you track down which version did *not* have this problem? cgminer only, please. |
|
|
|
That said, how does that effect efficiency calculations going forward? Stratum is effectively the same in that regard, so if you pull a template and send back getworks, how is CGminer going to calculate efficiency or does that just become a redundant metric at that point?
I haven't decided what to do with the efficiency metric. Either I'll make up something or just not use it. Making it halfway through the stratum protocol, I've decided that each mining notify message will be counted as the equivalent of a getwork. Of course efficiency is increasingly becoming a figure that is of not much use to miners and pool ops alike, but perhaps a target efficiency will be the endpoint of tuning what variable diff to set it to. I'd argue efficiency isn't even a meaningful stat on Stratum. Pools sending you more job notifications aren't less efficient, they're actually MORE efficient (more frequent jobs = more current on transactions in the network). Indeed efficiency is already confusing enough in the light of rolltime and vardiff, and not even defined in any meaningful fashion for stratum. It looks like it might be time to retire it as a metric. |
|
|
|
ckolivas,
I know LTC is no more your favorite thing than Stratum is Luke-jr's. However a few of us are starting to see a lot of rejections with time-too-old issues. Do you have any insight what might be done to stop these? I mentioned it over at #ozcoin and Graet was kind enough to fire up an instance and he got "<@Graet> A:644 R:197 after 1.5 hours" so you can see its a ton of rejects I have seen 44-50% on my own miners with no other hardware errors etc.
Anything you can suggest?
Is this new? If so, can you pinpoint which version it started from? If not, is it unique to lc.ozco.in ? |
|
|
|
It seems the only reason he's so vehemently against stratum is that it was a competing protocol to what he was working on, and therefore anything he didn't do must be wrong in his eyes. Essentially what it comes down to. As far as I can tell, we have: GBT: + Easier to implement in existing code - Larger bandwidth requirements - Includes redundant features for miners Stratum: + Tiny bandwidth + Streamlined features for mining - Difficult to implement in existing code To my mind, Stratum wins. Maybe initially more difficult to roll out, but ultimately will hold out better as hash rates continue to increase. In a nutshell yes. However the bandwidth requirements of both are so small that the advantage in that regard is no big deal. Stratum has advantages across block change and in terms of network latencies. |
|
|
|
|
Show Posts
