|
comeonalready
|
 |
March 21, 2014, 10:28:09 PM |
|
Oh please, not again! Use search. Search is your friend. |
|
|
|
|
|
|
|
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
rallasnackbar
|
|
March 21, 2014, 10:28:50 PM |
|
Dont think so, by the name of some of them, they might be gridseeds, or the new ones from alpha-t with 90 mh/s |
|
|
|
|
|
comeonalready
|
|
March 21, 2014, 10:37:00 PM |
|
I'm getting TONS of duplicate shares. What's the cause?, I didn't see that on other pools.
This can be caused by cgminer inadvertently mining two different coins at the same time, as it only maintains one block table internally. But this would only occur if you are not receiving enough work from your active (and in most cases primary) server, and you have backup servers configured, and you have not specified the FAILOVER-ONLY option -- as cgminer by default will send some work to backup pools in an attempt to keep maximize efficiency when the active server is unable to provide enough work to maximize your hashing efficiency. But if that backup server is mining a different coin, and even wafflepool's various servers are not mining the same coin at the same time, then that internal table will become corrupted and cgminer will often produce duplicate shares as a result. (Or it could also result from quotas causing same, but very few people actually try to use them so I doubt this would be relevant.) poolwaffle is looking into a server efficiency issue right now, and based upon his past performance, he will very likely have a solution very soon. poolwaffle, may I suggest that you try to determine if there is a correlation between the times people say they are witnessing these idle periods and the times we actually solve a block and submit it to a blockchain? As it could be very well be the same or similar to the issue you noticed with the old server code but wearing a different mask. e.g. solved block gets submitted to blockchain and everything stalls until it provides us with more work. If that is the case, perhaps provide us with work for a different coin in the meantime? |
|
|
|
|
|
poolwaffle (OP)
|
|
March 21, 2014, 10:45:58 PM |
|
I'm getting TONS of duplicate shares. What's the cause?, I didn't see that on other pools.
This can be caused by cgminer inadvertently mining two different coins at the same time, as it only maintains one block table internally. But this would only occur if you are not receiving enough work from your active (and in most cases primary) server, and you have backup servers configured, and you have not specified the FAILOVER-ONLY option -- as cgminer by default will send some work to backup pools in an attempt to keep maximize efficiency when the active server is unable to provide enough work to maximize your hashing efficiency. But if that backup server is mining a different coin, and even wafflepool's various servers are not mining the same coin at the same time, then that internal table will become corrupted and cgminer will often produce duplicate shares as a result. (Or it could also result from quotas causing same, but very few people actually try to use them so I doubt this would be relevant.) poolwaffle is looking into a server efficiency issue right now, and based upon his past performance, he will very likely have a solution very soon. poolwaffle, may I suggest that you try to determine if there is a correlation between the times people say they are witnessing these idle periods and the times we actually solve a block and submit it to a blockchain? As it could be very well be the same issue you noticed with the old server code wearing a different mask. e.g. solved block gets submitted to blockchain and everything stalls until it provides us with more work. If that is the case, perhaps provide us with work for a different coin in the meantime? It seems unlikely, in fact we fixed the issue that was giving us duplicate shares on the old system (we're seeing almost none now). Some users I've seen however submit nonstop duplicate shares (literally 100%) even minutes after new work has been given (and _many_ new works given). Leading me to believe its just a very misconfigured miner. fabrizziop, what % are you seeing of duplicate shares, and how often? One thing I'm working through with someone else seeing their miner stall out, is with the new stratum servers we re-send the same work request after 30 seconds (some miners were disconnecting/reconnecting if they didn't hear from the server in 30 seconds - not sure why). This fixed things in testing, but it might be causing issues with other miners we hadn't tested. I've got a patch here that may fix it, but don't want to launch a new stratum immediately before going to bed, so it will go in in the morning and we'll see what that changes  |
|
|
|
|
|
phzi
|
|
March 21, 2014, 10:56:34 PM |
|
USWest server just hiccuped, it appears. Was not responding for about 30 seconds. Seems fine now, however.
|
|
|
|
|
Uniphase21
Newbie
 Offline
Activity: 55
Merit: 0
|
|
March 22, 2014, 12:47:02 AM |
|
how do you determine if you have duplicate shares?
|
|
|
|
|
|
fabrizziop
|
|
March 22, 2014, 02:53:28 AM |
|
I'm getting TONS of duplicate shares. What's the cause?, I didn't see that on other pools.
This can be caused by cgminer inadvertently mining two different coins at the same time, as it only maintains one block table internally. But this would only occur if you are not receiving enough work from your active (and in most cases primary) server, and you have backup servers configured, and you have not specified the FAILOVER-ONLY option -- as cgminer by default will send some work to backup pools in an attempt to keep maximize efficiency when the active server is unable to provide enough work to maximize your hashing efficiency. But if that backup server is mining a different coin, and even wafflepool's various servers are not mining the same coin at the same time, then that internal table will become corrupted and cgminer will often produce duplicate shares as a result. (Or it could also result from quotas causing same, but very few people actually try to use them so I doubt this would be relevant.) poolwaffle is looking into a server efficiency issue right now, and based upon his past performance, he will very likely have a solution very soon. poolwaffle, may I suggest that you try to determine if there is a correlation between the times people say they are witnessing these idle periods and the times we actually solve a block and submit it to a blockchain? As it could be very well be the same issue you noticed with the old server code wearing a different mask. e.g. solved block gets submitted to blockchain and everything stalls until it provides us with more work. If that is the case, perhaps provide us with work for a different coin in the meantime? It seems unlikely, in fact we fixed the issue that was giving us duplicate shares on the old system (we're seeing almost none now). Some users I've seen however submit nonstop duplicate shares (literally 100%) even minutes after new work has been given (and _many_ new works given). Leading me to believe its just a very misconfigured miner. fabrizziop, what % are you seeing of duplicate shares, and how often? One thing I'm working through with someone else seeing their miner stall out, is with the new stratum servers we re-send the same work request after 30 seconds (some miners were disconnecting/reconnecting if they didn't hear from the server in 30 seconds - not sure why). This fixed things in testing, but it might be causing issues with other miners we hadn't tested. I've got a patch here that may fix it, but don't want to launch a new stratum immediately before going to bed, so it will go in in the morning and we'll see what that changes I saw about 30-40% duplicate shares, happens in random periods. |
|
|
|
|
caution
Member
Offline
Activity: 65
Merit: 10
|
|
March 22, 2014, 06:19:11 AM |
|
noticed my hash rate dropped to zero, mining on both uswest & useast with failovers to both plus other pools. Checked both machines to see each is saying: Connected to 206.223.224.225 diff 1.02K going to try restarting sgminer (BAMT), see if that fixes it...no ideas why or what happened. edit: stopping & restarting fixed it, for now. |
|
|
|
|
|
|
|
poolwaffle (OP)
|
|
March 22, 2014, 09:15:53 AM |
|
Poloniex has a total of 0.31btc depth. Mintpal has a total of (approx) 1.5btc depth. We could mine it for like 15min. |
|
|
|
|
|
utahjohn
|
|
March 22, 2014, 09:25:13 AM |
|
I say again what about auroracoin (AUR) ...
Stats from multipool.us
Pool Hash Rate 356.096 Mh/s
Pool Efficiency (10 minute) 100.00%
Avg. Profit (last 30 blocks) 0.02074154 BTC/MH/day
Avg. Luck (last 30 blocks) 388.49%
Block Stale Rate (4h/24h) 0.00%/0.00%
Current Users Mining 280
Current Block 5,096
Current Difficulty 2892.53
Total AUR Paid 8,073
Last Block Found 5,093
Avg. Time To Find Block 10 Hours 41 Minutes
Time Since Last Block 2 Hours 30 Minutes
Current Round Shares 162626880*
Current Round Luck 116.56%
|
|
|
|
|
Pierrot59
Newbie
Offline
Activity: 23
Merit: 0
|
|
March 22, 2014, 09:29:27 AM |
|
GPUs GAME OVER
<0.005 BTC/Day/Mh
GOOD BYE
|
|
|
|
|
|
utahjohn
|
|
March 22, 2014, 09:32:46 AM |
|
Seems to me if we throw 30+ GHs at it occasionally could get avg time to block down quite a bit.
Only exchange I am using at moment is coinedup.com 1% fee
|
|
|
|
|
|
gaalx
|
|
March 22, 2014, 09:33:57 AM |
|
pw, 3 Gh work for mining. think maybe we should have our share of workers on the cards and workers on the ASIC. For the development of the pool will be the short time necessary to, for example Vertcoin ( https://bitcointalk.org/index.php?topic=514242.0). PS became very cautious and go on about the major workers. |
|
|
|
|
poolwaffle (OP)
|
|
March 22, 2014, 09:41:48 AM |
|
pw, 3 Gh work for mining. think maybe we should have our share of workers on the cards and workers on the ASIC. For the development of the pool will be the short time necessary to, for example Vertcoin ( https://bitcointalk.org/index.php?topic=514242.0). PS became very cautious and go on about the major workers. I don't know what you're saying... |
|
|
|
|
|
SirGeekalot
|
|
March 22, 2014, 09:48:12 AM |
|
Its like hes talking english, but i've suddenly got dyslexia..
|
|
|
|
|
|
poolwaffle (OP)
|
|
March 22, 2014, 10:02:48 AM |
|
So, I made some major changes to our profitability switcher a couple hours ago.
Short synopsis is that it more accurately gauges the amount of hash power is on each individual section of the pool, and assigns them more appropriately to various coins. It should end up being a bit more aggressive on small coins than it was before (and more accurate). Previously for efficiency, it was treating all segments of the pool as static sizes (we have 24 switchable servers, so each was counted as 1/24 of the pool), this was just meant to be an estimate, and only really became a problem when our servers got horribly lopsided (mostly a few days ago when we switched to the new stratum servers). Pool is split roughly: 60% usw, 25% use, 14% eu, 1% sea. Which meant any time we switched use/eu, everything worked out pretty correctly, but when sea/usw got switched, we'd see higher orphan rates than we wanted (or less blocks than we'd want).
The other major switch is that we now switch pieces of the pool that match up closest with what we're mining. If our switcher says "We need 2GH on coin X", it was previously randomly assigning segments of the pool (again, we counted them as even), but now tries to find the right combination of servers to switch to closest match the goal.
Ideally this means a bump in profitability, and so far I've seen a significant bump over the last 2 hours, however, its damn near impossible to tell if this is based on a better script, or just random luck (which is the next major upgrade - tracking luck). So we'll see as the day progresses and luck evens itself out.
|
|
|
|
|
|
gaalx
|
|
March 22, 2014, 10:08:10 AM |
|
sorry do not know English. Google helps
Coming soon forks only for video cards (Asic stable) and it should be considered in the development of a pool.
|
|
|
|
|
poolwaffle (OP)
|
|
March 22, 2014, 10:18:53 AM |
|
sorry do not know English. Google helps
Coming soon forks only for video cards (Asic stable) and it should be considered in the development of a pool.
The pool has no way of knowing if a user is an ASIC, a GPU, or some guy manually writing down numbers and sending them in... |
|
|
|
|
|
comeonalready
|
|
March 22, 2014, 10:25:12 AM |
|
sorry do not know English. Google helps
Coming soon forks only for video cards (Asic stable) and it should be considered in the development of a pool.
The pool has no way of knowing if a user is an ASIC, a GPU, or some guy manually writing down numbers and sending them in... Why is my reported hashrate so low? Haven't you been receiving my letters via postal mail? |
|
|
|
|
|
