|
Lucko
|
 |
May 30, 2013, 09:09:03 PM |
|
Lucko, what do you have d= set to?
No need to troubleshot. I'm doing it deliberately so I can help find the problem... And it is only a really small part of my hashpower. Yesterday I have created FPGA for mining just to learn how. It is old chip and only 7 to 10 hashes... So I can use it on a same account with d=1 as others just to get data to help doublec. That is why I also report all I see... |
|
|
|
|
|
|
|
|
|
|
|
The grue lurks in the darkest places of the earth. Its favorite diet is adventurers, but its insatiable appetite is tempered by its fear of light. No grue has ever been seen by the light of day, and few have survived its fearsome jaws to tell the tale.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
kwaaak
|
|
May 30, 2013, 09:11:34 PM |
|
Hashing very well with cgminer 2.11.4 at d=2.
|
|
|
|
|
|
Lucko
|
|
May 30, 2013, 09:21:41 PM |
|
Hashing very well with cgminer 2.11.4 at d=2.
cgminer 2.11.4 doesn't have any problems 3.x does. So doublec asked for feedback... So I deliberately looking to have a problem... |
|
|
|
|
|
redtwitz
|
|
May 30, 2013, 10:28:17 PM |
|
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
I used to get frequent disconnects with CGMiner 3.1.1. It's working very well so far: not a single lost share in the last 4 hours. I've restarted CGMiner in text-only mode to monitor this more closely. It is hi difficulty 3.x problem... Pause between shares must be 90 second or more.... d=1 is a good workaround if you have at lest 50MH...
At least my connection problem were not due to lack of submitted shares. I got them while mining at 1.2 GH/s with worker difficulty 1. |
|
|
|
|
MiningMan
Newbie
 Offline
Activity: 11
Merit: 0
|
|
May 31, 2013, 01:30:20 AM |
|
Curious, on avg, how long is a round here?
Thanks in advance
|
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
May 31, 2013, 01:34:36 AM |
|
Curious, on avg, how long is a round here?
Rounds should on average equal the difficulty value over time. Currently at our hash rate, from the #mmpool bot: < doublec> !average
< mmbot> On average it will take 6.5 hours to find a block at 2238.3 Gh/s. 50% of blocks will be found in 4.5 hours. 95% in 19.4 hours. 99% in 29.8 hours.
< mmbot> The pool should earn approximately 92.62 BTC per day.
|
|
|
|
|
MiningMan
Newbie
Offline
Activity: 11
Merit: 0
|
|
May 31, 2013, 01:56:08 AM |
|
Curious, on avg, how long is a round here?
Rounds should on average equal the difficulty value over time. Currently at our hash rate, from the #mmpool bot: < doublec> !average
< mmbot> On average it will take 6.5 hours to find a block at 2238.3 Gh/s. 50% of blocks will be found in 4.5 hours. 95% in 19.4 hours. 99% in 29.8 hours.
< mmbot> The pool should earn approximately 92.62 BTC per day.
Thanks! |
|
|
|
|
|
|
|
roy7
|
|
May 31, 2013, 01:06:34 PM |
|
You all might want to report this on the cgminer thread too, in case it's a 3.x bug and not bitparking-specific.
|
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
May 31, 2013, 01:15:28 PM |
|
You all might want to report this on the cgminer thread too, in case it's a 3.x bug and not bitparking-specific.
The one I fixed was definitely bitparking specific. I use zeromq to notify the stratum server when a new block has arrived. The stratum server listens on the zeromq socket with a 30 second timeout and sends a notify message then. Unfortunately zeromq on the server was 2.x while I was testing on a 3.x install on my development machine. The 2.x version of zeromq doesn't honour the timeout. So the zeromq listen never timed out. If no blocks on any of the alt chains occurred within 90 seconds then cgminer would disconnect. I think this disconnect rule is new in cgminer 3.x.x which is why it's not seen in 2.x. |
|
|
|
|
|
redtwitz
|
|
June 01, 2013, 01:11:40 AM |
|
CGMiner and the pool are still not getting along.
CGMiner 3.1.1 has been claiming that the pool is dead since approximately 00:30 UTC. CGMiner 2.11.4 says it's alive, but I'm getting an unusually low hashrate.
Another rig on the same network is running GUIMiner, which is working as usual. So do both versions of CGMiner if I switch to the backup pool.
|
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
June 01, 2013, 01:14:10 AM |
|
CGMiner and the pool are still not getting along.
CGMiner 3.1.1 has been claiming that the pool is dead since approximately 00:30 UTC. CGMiner 2.11.4 says it's alive, but I'm getting an unusually low hashrate.
Another rig on the same network is running GUIMiner, which is working as usual. So do both versions of CGMiner if I switch to the backup pool.
It's working fine for me - anyone else seeing this issue? |
|
|
|
|
|
redtwitz
|
|
June 01, 2013, 01:20:00 AM
Last edit: June 01, 2013, 03:56:29 AM by redtwitz |
|
CGMiner just switched back to Bitparking.
EDIT: It happened again, but it only lasted about a minute this time...
EDIT: CGMiner 3.2.0 has the same issues 3.1.1 has. Right now, I'm getting disconnects every couple of minutes (7 in the last 15 minutes).
|
|
|
|
|
|
redtwitz
|
|
June 01, 2013, 05:05:35 AM |
|
I'm connecting through slush's stratum mining proxy right now, and it seems to be working peachy. However, the supplied reason for a couple of rejected shares caught my eye: REJECTED: (u'u', u'n', u'k') What does that mean? Speaking of rejected shares: My CGMiner has a suspiciously low number of rejected shares on Bitparking. Sometimes, I can submit literally tens of thousands of shares without seeing a single rejected one. That's not the case with others pools nor with different mining clients... |
|
|
|
|
|
Lucko
|
|
June 01, 2013, 06:21:59 AM
Last edit: June 01, 2013, 11:58:52 AM by Lucko |
|
It's working fine for me - anyone else seeing this issue?
Yes... On a test machine I'm still getting them with 3.1.1 but 2.11.4 is OK. I using now 630 HM for this tests... d=1 but still. I will soon get 1GH of USB ASIC and I will need to run 3.1.1. So if you need me for debugging please let me know what you need. EDIT: Upgraded to 1GH but still EDIT2: 2.11.4 is probably OK. I did get some disconnects since I have turned on this test machine and start running 3.1.1. If I run 2.11.4 there are no disconnects... EDIT3: Just seen a disconnect on all miners at the same time... All ruining 2.11.4 right now. So the same thing might happen in EDIT2. |
|
|
|
|
|
Lucko
|
|
June 01, 2013, 06:23:58 AM |
|
Speaking of rejected shares: My CGMiner has a suspiciously low number of rejected shares on Bitparking. Sometimes, I can submit literally tens of thousands of shares without seeing a single rejected one. That's not the case with others pools nor with different mining clients...
I also noticed that. But I see in logs that when rejected share happens cgminer puts in a user request and it is probably accepted... Not sure... |
|
|
|
|
doublec (OP)
Legendary
Offline
Activity: 1078
Merit: 1005
|
|
June 01, 2013, 03:58:53 PM |
|
This is a heads up that I've written and tested the code to have the pool no longer pay out on orphan blocks as discussed here previously. The way this works is there will be a "Pending BTC Payments" section in the user stats. When a block is found the bitcoin amount earnt is added to that and the block appears as "pending" in the list of solved blocks. When the block is marked "paid" the amount is moved from the "Pending BTC Payments" to the users bitcoin balance and is then available for withdrawal. If the block is marked "orphan" the amount is not added to the bitcoin balance. I'm expecting to set the threshold of confirmations to denote "not orphaned" to be about 3. When I first activate this I'll be processing the payments manually to check that everything is going ok before I automate things so there may some delay in confirmation initially. I'm looking at activating this process sometime in the next 24 hours when I've got a time I can watch the pool constantly to make sure nothing goes wrong. With regards to transaction fees I've not yet enabled the payment of these to users - the pool still keeps them - but I expect to do that in the next day or two once the orphan code has settled. Future updates after this are expected to be: - Continue to investigate the pool disconnectoin reports from cgminer 3.x that some users are experiencing
- Upgrade merge mining bitcoind to 0.8.2. I have the merge mining patches I use converted to 0.8.2 and have done a fair amount of testing and it's working so this won't be too far away. This should provide better pool performance, block propogation and less chance of orphans.
- Automatic payments over a set threshold
- More stats available from the apis
As always, feedback appreciated. |
|
|
|
|
|
Lucko
|
|
June 01, 2013, 04:38:11 PM |
|
As always, feedback appreciated.
I would also recommended changing the site a bit. If you would like to go ti irc you need to open a IRC, then look at the page for chanal and join it. What about link http://webchat.freenode.net/?channels=mmpool&prompt=1 on top of the page? Link names something like mmpool IRC Also I would recommend punting imported links on top of the page. Registration, user account, pool statistic,... So you don't need to look for them over the page. I would also like to see one page with impotent stats for user. I have now 3 page opened http://mmpool.bitparking.com/blockstatshttp://mmpool.bitparking.com/poolhttp://mmpool.bitparking.com/user/"my username" First one to see DGM Estimate(, Luck and Duration) Second to see PPS, Pool Hash Rate(, Luck and Duration) Last to see well all that that is on it... And I would still like to see Pool luck 48 hours, 7 days, 30 days(or maybe 8 blocks, 28 blocks, 120 blocks) or something like that... EDIT: If hash rate increases I would also like to see more then 5 blocks in history... |
|
|
|
|
|
redtwitz
|
|
June 01, 2013, 04:44:04 PM |
|
Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful  ) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed. As for feedback in general, it would be useful if the user stats showed the amount of active connections (i.e., workers). It can be hard to tell from the estimated hashrate alone if a rig has crashed. |
|
|
|
|
|
Lucko
|
|
June 01, 2013, 04:48:18 PM |
|
Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful ) and the pool finds a block that is later orphaned, the payments of the next valid block will be lower than they would be if the orphaned block never existed. As for feedback in general, it would be useful if the user stats showed the amount of active connections (i.e., workers). It can be hard to tell from the estimated hashrate alone if a rig has crashed. You are right on a first point and +1 on second... Hash rate per connection(worker) and inactive alarm... |
|
|
|
|
|
