tachyon_john
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 21, 2014, 02:50:55 PM |
|
I've been having the same issue as a few others since the new stratum server came online. As I write this, two of my 3 GPUs are idle while the third is hard at work. They idle for between 10 seconds and 5 minutes, which is ridiculous. What can I do to fix this? My current CudaMiner command: "C:\Miners\cudaminer.exe" -R 1 -C 1 -d 0 -a scrypt -o "stratum+tcp://uswest.wafflepool.com:3333" -u [address] -p x I don't have much mining power (600kH/s) so I can't afford to have them idle for so long. How exactly do you know they're idling? I have also observed the same behavior on 3 machines, and I have been collecting logs of GPU utilization through nvidia-smi which correlate to the cudaminer log I'm also keeping. I ran cudaminer with "-P" so I've also got a lot of the network protocol. I captured this happening probably ten times last night. It occurs on machines that are also connected to different stratum endpoints. So it's not just an issue with useast, or uswest, for example. I should also add that the observed idle periods are occasionally quite long, often 15 to 20 seconds. This seems like a very long time to me. When it occurs, no timeouts or errors are printed by cudaminer, so from its point of view there is no problem. This behavior began when wafflepool switched to the new stratum code the other day. Prior to that, I never observed this behavior before.
|
|
|
|
xia0mingx
Newbie
Offline
Activity: 17
Merit: 0
|
|
March 21, 2014, 02:52:12 PM |
|
why is shift time reduced back to previous duration? sorry for being noob for asking, but it doesnt affect my mining performance right? i only have a 1 MH/s rig.
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 02:53:28 PM |
|
I have also observed the same behavior on 3 machines, and I have been collecting logs of GPU utilization through nvidia-smi which correlate to the cudaminer log I'm also keeping. I ran cudaminer with "-P" so I've also got a lot of the network protocol. I captured this happening probably ten times last night. It occurs on machines that are also connected to different stratum endpoints. So it's not just an issue with useast, or uswest, for example.
I should also add that the observed idle periods are occasionally quite long, often 15 to 20 seconds. This seems like a very long time to me. When it occurs, no timeouts or errors are printed by cudaminer, so from its point of view there is no problem. This behavior began when wafflepool switched to the new stratum code the other day. Prior to that, I never observed this behavior before. Any chance you have the protocol dump around when they're idling? Might let me know whats being sent/not being sent during that time...
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 02:55:35 PM |
|
why is shift time reduced back to previous duration? Duration wasn't changed, count was changed. It is just a matter of how we were keeping track of shares on the backend. This is mostly due to changes today for the following: Worker stats are updated. You should now see (on the stats page) your reject rate per worker, and stats coming from the stats page are now a ~15min average (instead of 5min average), in an attempt to have fewer people email me telling me their hashrate jumps around a lot.
|
|
|
|
xia0mingx
Newbie
Offline
Activity: 17
Merit: 0
|
|
March 21, 2014, 02:59:00 PM |
|
on the stats page, it says I have 3.5% stale rate but on my miner it says only 0.3% rejected. is there something else I need to put into account? thanks pw
|
|
|
|
MPBG
Newbie
Offline
Activity: 1
Merit: 0
|
|
March 21, 2014, 03:00:43 PM |
|
It's good to see your stales, I'm at 1.40%, which should be a little bit high I think, but it's fine.
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 03:02:29 PM |
|
on the stats page, it says I have 3.5% stale rate but on my miner it says only 0.3% rejected. is there something else I need to put into account? thanks pw This could be as simple as variance in shares/stales. If your 0.3% is over 24hrs, and just in the last 15min there was a burst, we'd be showing the burst, and yours wouldn't. Can you reset your stats locally, wait 15min and see how they line up?
|
|
|
|
dexu
|
|
March 21, 2014, 03:02:50 PM |
|
STALE 0.00% good to know ..
|
|
|
|
xia0mingx
Newbie
Offline
Activity: 17
Merit: 0
|
|
March 21, 2014, 03:26:03 PM |
|
on the stats page, it says I have 3.5% stale rate but on my miner it says only 0.3% rejected. is there something else I need to put into account? thanks pw This could be as simple as variance in shares/stales. If your 0.3% is over 24hrs, and just in the last 15min there was a burst, we'd be showing the burst, and yours wouldn't. Can you reset your stats locally, wait 15min and see how they line up? Yup, you are right. 0.3% is over 24 hours. And the stale rate is now 0.00% on stats page. Thanks
|
|
|
|
Pfool
|
|
March 21, 2014, 03:27:38 PM |
|
why is shift time reduced back to previous duration? Duration wasn't changed, count was changed. It is just a matter of how we were keeping track of shares on the backend. This is mostly due to changes today for the following: Worker stats are updated. You should now see (on the stats page) your reject rate per worker, and stats coming from the stats page are now a ~15min average (instead of 5min average), in an attempt to have fewer people email me telling me their hashrate jumps around a lot. Yeah ! Is it possible to add the reject rate in the API ? Thank you
|
Thanx BTC: 19wv8FQKv3NkwTdzBCQn1AGsb9ghqBPWXi
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 03:40:49 PM |
|
on the stats page, it says I have 3.5% stale rate but on my miner it says only 0.3% rejected. is there something else I need to put into account? thanks pw This could be as simple as variance in shares/stales. If your 0.3% is over 24hrs, and just in the last 15min there was a burst, we'd be showing the burst, and yours wouldn't. Can you reset your stats locally, wait 15min and see how they line up? Yup, you are right. 0.3% is over 24 hours. And the stale rate is now 0.00% on stats page. Thanks Yep, could have been something as simple as us jumping on a small coin, and seeing a slightly higher reject rate during that time \\ Is it possible to add the reject rate in the API ?
Yep, gimme a bit here
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 03:46:08 PM |
|
API now includes stalerate, returned as a % of overall hashrate. Hashrate include stale hashrate.
For example, if your miner submitted 1MHs, of which half was rejected, "hashrate" would show 1000000, "stalerate" would show 50.00.
|
|
|
|
gaalx
|
|
March 21, 2014, 05:19:30 PM |
|
pw, mintcoin in coin balances - stuck? Thank you.
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 05:42:28 PM |
|
pw, mintcoin in coin balances - stuck? Thank you.
Please see any of the posts about this. Thank you.
|
|
|
|
ziddey
Newbie
Offline
Activity: 16
Merit: 0
|
|
March 21, 2014, 05:55:09 PM |
|
Please see any of the posts about this. Thank you.
BTC address I've been mining with is now invalid. Any way to move the balance to a different address? No longer have access to 1Hk2vF17rc2v7uoGLk4i25fr8wGemaGESH Thank you
|
|
|
|
cleanbaldy
Newbie
Offline
Activity: 42
Merit: 0
|
|
March 21, 2014, 06:08:50 PM |
|
Have we determined why Wafflepool isn't showing correct khash yet? Not only that, with the lower reported khash than before the server was changed, the payouts are not equal anymore. My BTC / Day / 1mH is LITERALLY going off of the falsely reported khash numbers. I'm losing out on 21% of my khash. That's HUGE. Something broke when you switched to the new server. Might want to take a look... I've had reports on my reddit post about this. Everyone is seeing it. Money = the reason we're here with you You've been amazing thus far. One or two days of tweaking and fixing a config is fine. If this continues, you may have people thinking you're stealing 20% of their money. Money makes people believe crazy things... Secondary, something else changed last night at around 10:30, when the East server crashed for an hour? Still tweaking? The KHash issue did not get fixed, if that's what was going on... https://i.imgur.com/ofjzQMk.jpg
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 06:22:58 PM |
|
Please see any of the posts about this. Thank you.
BTC address I've been mining with is now invalid. Any way to move the balance to a different address? No longer have access to 1Hk2vF17rc2v7uoGLk4i25fr8wGemaGESH Thank you Nope. Won't move funds from one address to another unless you can sign a message with the first address. Its the only way for me to be sure you're not stealing someone else's coins. Sorry
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 06:24:50 PM |
|
Have we determined why Wafflepool isn't showing correct khash yet? Not only that, with the lower reported khash than before the server was changed, the payouts are not equal anymore. My BTC / Day / 1mH is LITERALLY going off of the falsely reported khash numbers. I'm losing out on 21% of my khash. That's HUGE. Something broke when you switched to the new server. Might want to take a look... I've had reports on my reddit post about this. Everyone is seeing it. Money = the reason we're here with you You've been amazing thus far. One or two days of tweaking and fixing a config is fine. If this continues, you may have people thinking you're stealing 20% of their money. Money makes people believe crazy things... Secondary, something else changed last night at around 10:30, when the East server crashed for an hour? Still tweaking? The KHash issue did not get fixed, if that's what was going on... Maybe I'm confused as to what you're showing in that graph... Nothing looks like the hashrate dropped by 20% anywhere in that graph...
|
|
|
|
rallasnackbar
|
|
March 21, 2014, 06:41:02 PM |
|
The problem is the high "vardiff" that causes small miners like gridseed and usb miners to show incorrect numbers. I mined on ghash.io while they had bonus, and because of the low difficulty, the khash on their website is much more stable on small units.
Are there any chance that wafflepool will get a lower vardiff than 512??
|
|
|
|
tachyon_john
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 21, 2014, 06:43:36 PM |
|
I have also observed the same behavior on 3 machines, and I have been collecting logs of GPU utilization through nvidia-smi which correlate to the cudaminer log I'm also keeping. I ran cudaminer with "-P" so I've also got a lot of the network protocol. I captured this happening probably ten times last night. It occurs on machines that are also connected to different stratum endpoints. So it's not just an issue with useast, or uswest, for example.
I should also add that the observed idle periods are occasionally quite long, often 15 to 20 seconds. This seems like a very long time to me. When it occurs, no timeouts or errors are printed by cudaminer, so from its point of view there is no problem. This behavior began when wafflepool switched to the new stratum code the other day. Prior to that, I never observed this behavior before. Any chance you have the protocol dump around when they're idling? Might let me know whats being sent/not being sent during that time... Yes, I have been logging both the protocol and the GPU utilization for the last 12 hours or so, so I should have several examples of where this occurs in my log. Right now I see it happening again at about 1:40pm central time...idle for about 1 minute and 45 seconds before it recovered. No errors from cudaminer when it happens, but no activity either. Same cudaminer binary worked fine for the last 2-3 weeks before the stratum change. I can send you a PM with a gzipped copy of the logs if you like. I sent you a short log snippet already last night, but sending the whole log may be more useful for you.
|
|
|
|
|