Pages:
Author

Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 40. (Read 163898 times)

legendary
Activity: 1078
Merit: 1005
Please let me know if any of that output was useful. Stratum disconnects seemto affect my USB AsicMiner Erupters.
Thanks these are very useful. In particular they've told me exactly where in the cgminer source it's failing so I can try and track it down:
Code:
Failed to recv sock in recv_line
sr. member
Activity: 296
Merit: 250
Okay, email sent with a 1.5Mby attachment.

Running a second run with -P -D -T 2>log.txt

This seems to have less data, but seems still relevant for what you want. I'll send email #2 soon.

EDIT: corrected, was running 2>log.txt not 1>log.txt

Email with the second, 2.0 Mby attachment sent.

Please let me know if any of that output was useful. Stratum disconnects seemto affect my USB AsicMiner Erupters.
sr. member
Activity: 296
Merit: 250
I'm running now -P -D -T >log.txt

There is A LOT of data, including shares.
sr. member
Activity: 296
Merit: 250
yes I think I need to use something like 2>%1 log.txt       hold on.
legendary
Activity: 1078
Merit: 1005
it outputs COM port device discovery information only, so far in the first 5 min or so. Will email you if I get anything more in the next hour or so.
Possibly windows logs things differently. When I run with that I immediatly get a low level list of everything going on, including all traffic sent to and from the pool. For example:

Code:
[2013-06-15 23:43:29] Generated stratum merkle 6a7443dde8a6046878e488cc9afc573d83c57a8d70218255e14bff19ffa08ffd
 [2013-06-15 23:43:29] Generated stratum header 00000002a0b952cd312f1a81174ea27994c5038d480c74f4e7712b2a000000c6000000006a7443dde8a6046878e488cc9afc573d83c57a8d70218255e14bff19ffa08ffd51bc53501a01133700
000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
 [2013-06-15 23:43:29] Work job_id job_6fb692a6_1 nonce2 00000000 ntime 51bc5350
 [2013-06-15 23:43:29] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000
 [2013-06-15 23:43:29] Generated stratum work
 [2013-06-15 23:43:29] Pushing work from pool 0 to hash queue
 [2013-06-15 23:43:29] Network diff set to 15.6M
 [2013-06-15 23:43:29] New block: 00c6e7712b2a480c... diff 15.6M
 [2013-06-15 23:43:29] Got work from get queue to get work for thread 0
 [2013-06-15 23:43:29] Generated stratum merkle ccc510a8b331ba22b7d8b1450767c5787334a0c98dac6746778d737d529558d0
 [2013-06-15 23:43:29] Generated stratum header 00000002a0b952cd312f1a81174ea27994c5038d480c74f4e7712b2a000000c600000000ccc510a8b331ba22b7d8b1450767c5787334a0c98dac6746778d737d529558d051bc53501a01133700
000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000
legendary
Activity: 1078
Merit: 1005
please could you lower your minimum withdraw, its far higher than other pools and takes an eternity using my single gpu, especially with the difficulty rising so rapidly.
The reason for not being too low is to prevent accumulation of dust amounts in both the pool wallet and the user wallet. This results in higher fees when those funds are spent. I'll add lowering it to the list of things to investigate though.
sr. member
Activity: 296
Merit: 250
Just ran this




./cgminer -o ... -u ... -p ... -P -D 2>log.txt

on Win 7

it outputs COM port device discovery information only, so far in the first 5 min or so. Will email you if I get anything more in the next hour or so.
full member
Activity: 214
Merit: 100
please could you lower your minimum withdraw, its far higher than other pools and takes an eternity using my single gpu, especially with the difficulty rising so rapidly.
legendary
Activity: 1078
Merit: 1005
I'm using cgminer v. 3.3.1. The first 550 Accepted shares report only 2% HW errors, which is almost normal. However, I just saw "lost 2 shares to stratum disconnect" on pool 0. HW error did not occur in this instance.
Are you able to run it with the"-P -D" switches for "protocol dump" and "debug" respectively? You can pipe the output using "2>log.txt". So something like:
Code:
./cgminer -o ... -u ... -p ... -P -D 2>log.txt

If you can send the log to [email protected] or see anything relevant in there around the disconnect it would be useful.
sr. member
Activity: 296
Merit: 250
I'm using cgminer v. 3.3.1. The first 550 Accepted shares report only 2% HW errors, which is almost normal. However, I just saw "lost 2 shares to stratum disconnect" on pool 0. HW error did not occur in this instance.
legendary
Activity: 1078
Merit: 1005
Just restarted and am watching the screen. Will report if the situation changes.
What miner are you using? cgminer v3.2.1?
sr. member
Activity: 296
Merit: 250
I was (as of a few minutes ago) still getting "stratum disconnect" messages as reported above on this page. At the same time, the ASICMINER USB Erupters report a few HW errors through cgminer. The rate of HW errors comes to about 10% which is way above the usual 1.5%.

Just restarted and am watching the screen. Will report if the situation changes.
legendary
Activity: 1078
Merit: 1005
please could you lower your withdraw fees, its far higher than other pools and takes an eternity using my single gpu, especially with the difficulty rising so rapidly.
What withdraw fee? There isn't one.
full member
Activity: 214
Merit: 100
please could you lower your withdraw fees, its far higher than other pools and takes an eternity using my single gpu, especially with the difficulty rising so rapidly.
legendary
Activity: 1078
Merit: 1005
There was a pool restart just now as I rolled back to bitcoin 0.8.1 to see if the recent upgrade is the cause of the instabilities.
legendary
Activity: 1078
Merit: 1005
The amazing thing is that the pool server remembered those few shares that got lost during the crash.
That's why after the server recovered the hashrate went up for a moment despite my rig automatically switched to a different pool:
Share's are kept in a queue and if they fail to transmit to the database server they wait until the database becomes available again. When restarting the pool services this results in a bunch of shares in the queue getting submitted when the database server comes up again and it often shows up as an increase in hash rate like that.
full member
Activity: 154
Merit: 100
Yes, the bitcoind crashed.
The amazing thing is that the pool server remembered those few shares that got lost during the crash.
That's why after the server recovered the hashrate went up for a moment despite my rig automatically switched to a different pool:

22:30: {"hashrate":540.609,"pps":0.00000000,"score":4312, ...
22:31: {"hashrate":544.634,"pps":0.00000000,"score":4318, ...
22:32: {"hashrate":533.885,"pps":0.00000000,"score":4318, ...


By the way, I wish the payout process from the "crashed" exchange.bitparking.com could run as smoothly as doublec's pool software ...
http://bitcointalk.org/index.php?topic=165153.80
legendary
Activity: 1078
Merit: 1005
Looks like somebody gave 'er the 'ol reboot.
Yes, the bitcoind crashed. I'm having a few problems with the recent upgrade to bitcoind 0.8.2. I'm running under the debugger at the moment to try and see what's going on. Worst case I may need to rollback the last update.
full member
Activity: 140
Merit: 100
In POS we trust
It's alive again
legendary
Activity: 1726
Merit: 1018
Looks like somebody gave 'er the 'ol reboot.
Pages:
Jump to: