I notice that i am getting many more rejected shares now that im using 2.8.4 compared to 2.7.5. I usualy get about 10 rejected shares per 20 000 accepted shares. Now with 2.8.4 ive gotten 200
Nothing's changed in management therein, so I can only assume it's coincidence and pool related. I immediately stopped the 2.8.4 and restarted 2.7.5 and i have no stale shares at all yet. Soemthing is definetly up Did you move to stratum with 2.8.4? EDIT: To explain why I ask that, cgminer + stratum gets notification of block changes much faster than ever so it should reduce the number of stales. On the other hand, I have noticed that slush uses that as an excuse to ignore any shares that are returned from the previous block immediately once it has stratum notified you of the new block saying job not recognised, so to me it looks like stales on slush went up, not down, despite the potential advantages. I'm not sure how btcguild fares there. |
|
|
|
I notice that i am getting many more rejected shares now that im using 2.8.4 compared to 2.7.5. I usualy get about 10 rejected shares per 20 000 accepted shares. Now with 2.8.4 ive gotten 200
Nothing's changed in management therein, so I can only assume it's coincidence and pool related. |
|
|
|
Ok so what I've done to try and help debug this is I've built a special windows build of cgminer that uses a special dll to help print out the backtrace if it crashes that should help me find where it's crashing.
To use it, grab the following 2 files:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe
http://ck.kolivas.org/apps/cgminer/temp/backtrace.dll
and put them into a regular 2.8.4 windows directory. Start it as you normally would, but with the -T option otherwise the display gets corrupted when the program exits, and if it crashes while mining stratum, send me what is output when it crashes please!
Meh doesn't seem to do what it's advertised as doing... sigh need to think of another strategy. |
|
|
|
OK - so here the last lines before my cgminer crashed (v2.8.4 on Win7x64). Note: I lost Internet connection for a few hours - maybe that caused the crash? [2012-10-22 02:37:39] 64.0 C F: 55%(1984RPM) E: 940MHz M: 200Mhz V: 1.175V A: 99% P: 0%
[2012-10-22 02:37:41] [thread 0: 1174405120 hashes, 210719.1 khash/sec]
[2012-10-22 02:37:42] 64.0 C F: 55%(1984RPM) E: 940MHz M: 200Mhz V: 1.175V A: 99% P: 0%
[2012-10-22 02:37:44] [thread 1: 1174405120 hashes, 210681.4 khash/sec]
[2012-10-22 02:37:45] 64.0 C F: 55%(1983RPM) E: 940MHz M: 200Mhz V: 1.175V A: 99% P: 0%
[2012-10-22 02:37:46] Reusing stratum work
[2012-10-22 02:37:46] Generated stratum merkle 21fccc1ae2762046362be1c31c71a92c40ce2a82dd4ccf81e6c96f4c218980c1
[2012-10-22 02:37:46] Generated stratum header 000000021cc6ab9ee271679f7e235158cdc5dfa57fad35ffa0554412000000c50000000021fccc1a
e2762046362be1c31c71a92c40ce2a82dd4ccf81e6c96f4c218980c15084950a1a0575ef00000000000000800000000000000000000000000000000000000000
000000000000000000000000000000000000000080020000
[2012-10-22 02:37:46] Work job_id 23349 nonce2 46000000 ntime 5084950a
[2012-10-22 02:37:46] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
[2012-10-22 02:37:46] Reusing stratum work
[2012-10-22 02:37:46] Generated stratum merkle 12962fdf3b3660e6e478991e90540812fd076649ad1040cde70d48d00e193d6b
[2012-10-22 02:37:46] Generated stratum header 000000021cc6ab9ee271679f7e235158cdc5dfa57fad35ffa0554412000000c50000000012962fdf
3b3660e6e478991e90540812fd076649ad1040cde70d48d00e193d6b5084950a1a0575ef00000000000000800000000000000000000000000000000000000000
000000000000000000000000000000000000000080020000
[2012-10-22 02:37:46] Work job_id 23349 nonce2 47000000 ntime 5084950a
[2012-10-22 02:37:46] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
[2012-10-22 02:37:46] [thread 0: 1207959552 hashes, 209158.4 khash/sec]
[2012-10-22 02:37:48] 64.0 C F: 55%(1983RPM) E: 940MHz M: 200Mhz V: 1.175V A: 99% P: 0%
[2012-10-22 04:38:48] Work stale due to expiry
C:\bitcoin\cgminer-2.8.4-win32> Not exactly revealing of anything :\ Was there a relationship time-wise with the internet connection going down/up and the crash time? |
|
|
|
Even better would be a custom debug build running in gdb but I doubt any of you are up for that  I'm trying that on my laptop which is the only thing that has windows. Hopefully I don't fry it in the process, but at 10MH/s I also doubt it will recreate the problem. Sigh. I wish it were only linux... How do you do that? I tried something a while back but didn't get it working. What I want to do is run under gdb, save the environment when it crashes, then continue running so that it's not sitting all day locked up. When you build it, build it without optimisations in the CFLAGS and with the -g option, i.e. CFLAGS="-g -Wall -W" only. Then gdb cgminer run [usual cgminer parameters] -T Running it with -T is a good idea cause gdb spews out other information and corrupts the display when you're using the curses display. Here's a debug build in case someone is willing to try it: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exeMeanwhile my laptop continues to fry itself but has not crashed with the windows binary. It's probably too slow to even reproduce the problem. |
|
|
|
I keep having problems with 2.8.4 freezing. It doesn't give any errors, it just stops, like someone hit the pause button. Sometimes it'll go for days before it happens, sometimes it'll go a few hours. This one points to p2pool, running on windows 7. I have two other machines with 2.8.4 on it, and they don't seem to have the problem. However, one of the machines is unstable (windows 8 preview) and tends to reboot of its own accord. The other is my main workstation and cgminer gets shut down fairly often there.
Also, I'm confused by the new output on 2.8.4 that shows the difficulty found vs difficult desired. I'm guessing the pools don't care about it, and they credit you for what's desired, not what's given? Otherwise if you hit the magic number and found a block, they'd be crediting you a whole lot, which they don't do.
M
Are you using any stratum pool somewhere in backups or otherwise in the cgminer that fails? The output diff is purely cosmetic. I don't think so. I have p2pool, ozcoin, emc, and 50btc there. But I see what you're thinking. Let me remove emc and 50btc. M No, neither of those are stratum pools so should not be affected directly by stratum code. |
|
|
|
I keep having problems with 2.8.4 freezing. It doesn't give any errors, it just stops, like someone hit the pause button. Sometimes it'll go for days before it happens, sometimes it'll go a few hours. This one points to p2pool, running on windows 7. I have two other machines with 2.8.4 on it, and they don't seem to have the problem. However, one of the machines is unstable (windows 8 preview) and tends to reboot of its own accord. The other is my main workstation and cgminer gets shut down fairly often there.
Also, I'm confused by the new output on 2.8.4 that shows the difficulty found vs difficult desired. I'm guessing the pools don't care about it, and they credit you for what's desired, not what's given? Otherwise if you hit the magic number and found a block, they'd be crediting you a whole lot, which they don't do.
M
Are you using any stratum pool somewhere in backups or otherwise in the cgminer that fails? The output diff is purely cosmetic. |
|
|
|
Interesting... I would like to know more about that at some point. I've not run into any problems and my server load is dramatically decreased. Regardless, though, I'm not sure that pools ignoring some transactions in favor of others is necessarily a negative thing. Right now, I limit the amount of transactions I put into any one block and I don't see any major issue with favoring higher transaction fee transactions over lower ones.
If there are no higher fee transactions waiting, then the lower fee ones will get processed and that's as designed as far as I know. I'm not saying it's a bad thing to "fix" GBT, but I've not run into any problems so far and I'd like to know at what point GBT becomes more cumbersome than getwork from a transaction standpoint.
The issue is the payload the longer a block takes to solve as the number of transactions rises. It would not be surprising if the pool was sending 100k sized payloads with all the transactions after 10 minutes on the block. While the load on the pool is definitely less, the data being spewed out to miners will eventually rise, and the more transactions and more popular bitcoin becomes, the larger the payload grows in a linear fashion with transactions. Eventually sending out 100kb payloads say every 30 or 60 seconds from the pool to all your miners will become a burden. Prioritising transactions is your prerogative but with this disincentive to sending transactions we will see a deepbit like situation where pool ops will put a static upper limit on the amount of transactions in total they care about including. This is much worse for bitcoin in general. But with an extension to the gbt protocol that more closely resembles the merkle root base of stratum it can easily be fixed. |
|
|
|
I don't seem to be able to see a v2.8.4 tag in git - can I just assume that the tip of the master branch is at 2.8.4?
roy
My bad. On this occasion it was at the commit with the version number. Uploaded tag now. |
|
|
|
|
Put the stratum URL in without any prefix in the config file.
|
|
|
|
Is vardiff on US1 not doing the vardiff dance any more? I'm stuck at diff 1 despite ~38 shares per minute.
Never mind, it just took a long while... But it seems to only hover between 1 and 2 where previously it would go 3-4. |
|
|
|
Requiring a full bitcoind instance on a mining node is ludicrous, at least in the current implementation of bitcoind. It's far, far, far too resource intensive to put on most serious mining setups. I don't want to run heavy weight computing back end, just to satisfy the ridiculously complex blockchain processing for a machine that is intended to solely mine, which requires few resources.
Now, if you want to redesign a bitcoind that doesn't require heavy computing resources, then I'm listening, but until then, it's a non-starter. A mining backend is a netbook, DD-WRT router, Raspberry Pi, Sheeva Plug or Android tablet. Trying to run a full blockchain on any of those would be an exercise in futility.
Which means you pretty much unintentionally agree with my position: GBT in its current form is not advantageous to miners. Luckily jgarzik is open to modifying it based on what I have recommended. We will be talking about it in the near future. |
|
|
|
Sigh. In that case, with p2pool being 400 GH of a 20TH network, then GBT is only going to benefit 2% of the miners. It's pretty obvious by now you can't force people to do what you think is best. If anything, GBT with non-p2pool pooled mining will make it more likely that pools will not want to pass on lots of transactions and will be worse than getwork.
How about adding an extension to GBT that has some kind of mode that sends a "suggested merkle root" for pooled mining?
Definitely interested in extensions that broaden the userbase as much as possible. Even for bitcoind (rather than a pool server), extensions like this make sense. The old "getwork" protocol did as much work as possible on the server side, thereby minimizing the miner's work -- notably the miner did not have to care about anything besides the block header itself. No transactions or other parsing to worry about. getblocktemplate is intended to replace getwork. If there are improvements to be made, I'm quite open to that. Ping me on IRC, if you want to rapidly iterate some changes to make bitcoind's GBT work better for a wider selection of mining softwares. I did the final getblocktemplate polish, simplifying and cleaning things up from its original BIP 22/getmemorypool state. If BIP 22 / BIP 23 are currently missing something you want... I want to put it in there. Thanks. When I get some extended block of time on IRC in the very near future, and you're online, I will most certainly. |
|
|
|
Hopefully you don't make the mistake of rejecting block solves then just because they happen across difficulty changes  |
|
|
|
|
No, it's quite alright. I have enough to do myself as well and I'm not in the business of helping pool designs. I'll implement it as is and let the mining community determine which pools and with what protocols they prefer.
|
|
|
|
|
slush, not a bad idea but I'm actually not questioning stratum here since I obviously think it's the better protocol for pooled mining as I've already implemented it in cgminer. It's just that this is the GBT thread, I have been asked to include GBT support as well and I'm not really happy with the protocol as is.
|
|
|
|
Even better would be a custom debug build running in gdb but I doubt any of you are up for that I'm trying that on my laptop which is the only thing that has windows. Hopefully I don't fry it in the process, but at 10MH/s I also doubt it will recreate the problem. Sigh. I wish it were only linux... How do you do that? I tried something a while back but didn't get it working. What I want to do is run under gdb, save the environment when it crashes, then continue running so that it's not sitting all day locked up. When you build it, build it without optimisations in the CFLAGS and with the -g option, i.e. CFLAGS="-g -Wall -W" only. Then gdb cgminer run [usual cgminer parameters] -T Running it with -T is a good idea cause gdb spews out other information and corrupts the display when you're using the curses display. Here's a debug build in case someone is willing to try it: http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe |
|
|
|
|
Sigh. In that case, with p2pool being 400 GH of a 20TH network, then GBT is only going to benefit 2% of the miners. It's pretty obvious by now you can't force people to do what you think is best. If anything, GBT with non-p2pool pooled mining will make it more likely that pools will not want to pass on lots of transactions and will be worse than getwork.
How about adding an extension to GBT that has some kind of mode that sends a "suggested merkle root" for pooled mining?
|
|
|
|
"Scrypt will now not fail when setting high thread concurrency values that still return some ram even if opencl returns an error on that ram allocation."
what exactly is considered "high"? I still cant get 2.8.4 to run on a 7950 with anything over 8192 (look-up gap2) unless i raise the look-up gap to 3 and go to 12224 (which i could do pre-2.8.4). Which allows intensity of 20 without HW errors. 3 vs 2 makes you lose some performance at the same concurrencies, but high intensities MORE than makes up for it. ( 3 @ 12224 @ 19 = ~400kh/s vs 2 @ 8192 @ 13 ~330kh/s)
Also... would you know why starting Cgminer @ 12 and raising to 13 gives HW errors, and using the -I 13 flag in my shortcut doesnt?
Thanks for your time.
I didn't say it would magically work, just that I relaxed one of the checks. And no I can't answer the second part about HW errors either. The scrypt opencl code remains a mystery to me. EDIT: Actually with the HW error scenario, it might be that because you're setting the kernel/memory size to intensity 13 on the first pass, that it allocates enough pinned system ram for that amount and continues working, whereas it doesn't like being increased after the fact. Magical scrypt pixie dust... |
|
|
|
|
Show Posts
