Bitcoin Forum
December 05, 2016, 02:47:19 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
Author Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining  (Read 150985 times)
Lucko
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 30, 2013, 09:09:03 PM
 #821

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...
1480906039
Hero Member
*
Offline Offline

Posts: 1480906039

View Profile Personal Message (Offline)

Ignore
1480906039
Reply with quote  #2

1480906039
Report to moderator
1480906039
Hero Member
*
Offline Offline

Posts: 1480906039

View Profile Personal Message (Offline)

Ignore
1480906039
Reply with quote  #2

1480906039
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kwaaak
Full Member
***
Offline Offline

Activity: 139


View Profile
May 30, 2013, 09:11:34 PM
 #822

Hashing very well with cgminer 2.11.4 at d=2.
Lucko
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 30, 2013, 09:21:41 PM
 #823

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
Full Member
***
Offline Offline

Activity: 231


View Profile
May 30, 2013, 10:28:17 PM
 #824

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 Offline

Activity: 11


View Profile
May 31, 2013, 01:30:20 AM
 #825

Curious, on avg, how long is a round here?

Thanks in advance
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
May 31, 2013, 01:34:36 AM
 #826

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:
Code:
< 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 Offline

Activity: 11


View Profile
May 31, 2013, 01:56:08 AM
 #827

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:
Code:
< 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!
Lucko
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 31, 2013, 06:35:16 AM
 #828

doublec if it helps, this is log of overnight testing run...

I had one crash(but I'm sure it is not pool related but FPGA related) so there are 2:

https://www.dropbox.com/s/kzs6e6mnnnrl1ap/log.txt
https://www.dropbox.com/s/7c1rjuv6cbqddcm/log%20%282%29.txt

I did run parallel on same computer 2.11.4 just to see if there were any connection issues. No disconnects and about same speed...
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
May 31, 2013, 01:06:34 PM
 #829

You all might want to report this on the cgminer thread too, in case it's a 3.x bug and not bitparking-specific.

RoyalMiningCo: Pools retired. Was fun!
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
May 31, 2013, 01:15:28 PM
 #830

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
Full Member
***
Offline Offline

Activity: 231


View Profile
June 01, 2013, 01:11:40 AM
 #831

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
Legendary
*
Offline Offline

Activity: 1078


View Profile
June 01, 2013, 01:14:10 AM
 #832

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
Full Member
***
Offline Offline

Activity: 231


View Profile
June 01, 2013, 01:20:00 AM
 #833

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
Full Member
***
Offline Offline

Activity: 231


View Profile
June 01, 2013, 05:05:35 AM
 #834

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:

Code:
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
Hero Member
*****
Offline Offline

Activity: 714



View Profile
June 01, 2013, 06:21:59 AM
 #835

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
Hero Member
*****
Offline Offline

Activity: 714



View Profile
June 01, 2013, 06:23:58 AM
 #836

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
Legendary
*
Offline Offline

Activity: 1078


View Profile
June 01, 2013, 03:58:53 PM
 #837

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
Hero Member
*****
Offline Offline

Activity: 714



View Profile
June 01, 2013, 04:38:11 PM
 #838

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/blockstats
http://mmpool.bitparking.com/pool
http://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
Full Member
***
Offline Offline

Activity: 231


View Profile
June 01, 2013, 04:44:04 PM
 #839

Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful Wink) 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
Hero Member
*****
Offline Offline

Activity: 714



View Profile
June 01, 2013, 04:48:18 PM
 #840

Will the scores get recalculated when a block is orphaned? If I understand DGM correctly (doubtful Wink) 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...
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!