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.
Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 45. (Read 163780 times)
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.
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 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...
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...
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.
< 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!
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.
< 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.
Curious, on avg, how long is a round here?
Thanks in advance
Thanks in advance
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.
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...
Hashing very well with cgminer 2.11.4 at d=2.
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... 
Lucko, what do you have d= set to?
There were a number of server restarts over the last hour as I worked to track down the cause of the stratum disconnections every 90 seconds occurring with users of cgminer 3 and above. I finally found the issue and have installed a fix. Hopefully there will be no more restarts or disconnections related to that issue.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
I Haven't seen this problem at all myself with 3 separate rigs all running cgminer 3.1.1 - although I do set d=1 on all three...
EDIT:
EDIT2: No last share didn't disconnect me... But I did restart cgminer to change some settings.
EDIT3: Interesting. Disconnect affected my hashrate but logs of my 2.11.4 miners doesn't show any disconnects... No idea why I lost 20% so hashrate... It looks like after restart cgminer works for some time and then you start getting disconnects. Looking for a any kind of pattern...
There were a number of server restarts over the last hour as I worked to track down the cause of the stratum disconnections every 90 seconds occurring with users of cgminer 3 and above. I finally found the issue and have installed a fix. Hopefully there will be no more restarts or disconnections related to that issue.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
I Haven't seen this problem at all myself with 3 separate rigs all running cgminer 3.1.1 - although I do set d=1 on all three...
I did notice while I was debugging a number of people connecting to the stratum port with a getwork miner. If your miner has been connecting and constantly getting errors you might want to check this.
There were a number of server restarts over the last hour as I worked to track down the cause of the stratum disconnections every 90 seconds occurring with users of cgminer 3 and above. I finally found the issue and have installed a fix. Hopefully there will be no more restarts or disconnections related to that issue.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
Unfortunately I couldn't reproduce on my test environment as it turns out the issue was due to a third party library version being different on the pool server vs on my testing machine.
Feedback on whether the number of "pool interrupted" errors have increased or decreased from here on appreciated.
I switched all of my machines over to d=2, and initially as I was halfway through switching them I was still seeing rejects. At some point along the way, all started working without rejects. Not sure if it was the complete change-over, or DoubleC made some fixes but either way bitparking is working great again! 
And, as always, thanks again to DoubleC for a fine pool and excellent support!
And, as always, thanks again to DoubleC for a fine pool and excellent support!
I had same problem on another pool. Then I just say to my self:"Don't fix it if it is not broken and go back on 2.11.4." But never figure out what was wrong... But I'm soon getting ASIC usb keys so I will be forced to go to 3.1.1. So if you can figure it out would be great.
I can't duplicate it locally unfortunately so there will be some restarts as I add debugging to the stratum server and tweak settings.Edit: Logging lots of debug goodness now.
Still seeing the problem, but haven't changed any difficulty settings yet. Also, running cgminer 3.1.1
I ran a test mining at difficulty 32 with 14 Mhash and didn't see these disconnections. I am noticing that users reporting it are running cgminer 3.1.x. I'm running 2.11.x. I'll do some testing with the newer version. Perhaps there's some difference in how they're dealing with stratum.Still seeing the problem, but haven't changed any difficulty settings yet. Also, running cgminer 3.1.1
I ran a test mining at difficulty 32 with 14 Mhash and didn't see these disconnections. I am noticing that users reporting it are running cgminer 3.1.x. I'm running 2.11.x. I'll do some testing with the newer version. Perhaps there's some difference in how they're dealing with stratum.Jump to: