ekoice
|
|
February 06, 2014, 09:13:57 AM |
|
at what hour are the payouts done? thanks.
|
|
|
|
rallasnackbar
|
|
February 06, 2014, 09:14:15 AM |
|
Still low reject rate, compared to other multipools.
GPU 0: 70.0C 3087RPM | 733.4K/732.7Kh/s | A:29138 R:23 HW:0 U: 11.33/m I:13
|
|
|
|
rallasnackbar
|
|
February 06, 2014, 09:15:45 AM |
|
at what hour are the payouts done? thanks.
My payouts have been between 14 - 16:30 GMT+1
|
|
|
|
poolwaffle (OP)
|
|
February 06, 2014, 09:29:26 AM |
|
Trying to figure out what is up with the issue you guys were having earlier. Load on our main db box is up a bit, but don't see anything very suspicious (no new badly written queries, etc).
I've gone ahead and added a few more keys for the DB which should speed it up slightly. A few things that weren't indexed before (but weren't a performance issue) may be starting to add up as the pool grows, so I'll go back through everything today and make sure all our queries are fast.
Those of you that saw the vardiff stuck at 1024, are you using the old endpoints I assume? The new endpoints max out at 512, so you should never be seeing them there.
Now that the new endpoints look reasonably stable (haven't seen anyone complaining yet!), I'll work on adding a vardiff minimum to connection params. I'll tell you guys if it changes, but plan on setting password in the format "d=XX" where XX is the difficulty you'd like to start at, examples: d=16 or d=128 Valid values will be 16-512. Hopefully will be implemented later today, and if so, we'll have rolling restarts on the new endpoints (you might drop connection for 10 seconds or so). Original endpoint will not have the new feature.
|
|
|
|
poolwaffle (OP)
|
|
February 06, 2014, 09:30:25 AM |
|
My payouts have been between 14 - 16:30 GMT+1
This is correct, however, they're going to be sliding forward over the next few days, probably edging closer to 10:00-12:00 GMT+1.
|
|
|
|
poolwaffle (OP)
|
|
February 06, 2014, 10:57:21 AM |
|
Cryptsy is down currently (502 Bad Gateway), so payouts today may be delayed depending on how long it takes to come back up (sorry!) Edit: Was able to get in and withdraw, assuming it goes through, payouts will be on time. Also, I need to go through and run some maintenance on our database later today. I'll be pulling the website offline during that time (with a "Website down for maintenance" notice), to reduce the load on it slightly during maintenance, API will be down during this time as well. I expect it to take 1-2 hours. Mining should not be affected, shares will continue to collect properly, and coin earnings will continue as normal. Exchanging coins _may_ be taken offline during that time (not sure yet), but shouldn't affect anything. Long story short, 1-2 hour maintenance starting in 4-5 hours from now. Mining unaffected, website down during that time. Faster everything afterward
|
|
|
|
eMiz0r
Member
Offline
Activity: 60
Merit: 10
|
|
February 06, 2014, 11:06:54 AM |
|
Just a question: for the last couple of hours we've been mining casinocoin and alphacoin from which almost every block is ending up orphaned. Does this hurt our BTC/MH per day? I see the BTC/MH/day dropping on the mainpage also fairly quickly from 0.013 12 hours ago to under 0.01 right now.
Do you automatically disable (temporarely) coins that return a lot of orphaned blocks? The payouts are really hurt when this occurs and might be the one (and only) reason why middlecoin is a little more profitable. I'm still happy with waffle, but it would be nice if this could be addressed.
|
|
|
|
cereal7802
Newbie
Offline
Activity: 57
Merit: 0
|
|
February 06, 2014, 11:30:05 AM |
|
Connect each worker in the form: [btcaddress]_[workername] Each worker will be tracked separately for vardiff, however balances are calculated on a per-address (not username) basis! Is this working? I ask because although i have 3 different worker names, all 3 miners seem to change to the higher diff settings at the same time. if i kill one of the faster miners i have the diff drops to 16, but when i have both fast miners diff goes to 128 then after a bit drops to 64, then back to 128 like it it is combining the mining power and hitting a diff that is too high and then falling back when it detects the share submit rate of my miners.
|
|
|
|
Leto74
Newbie
Offline
Activity: 16
Merit: 0
|
|
February 06, 2014, 11:49:12 AM |
|
casinocoin is broken, we only get orphans, wtf
|
|
|
|
Ledningen
Newbie
Offline
Activity: 11
Merit: 0
|
|
February 06, 2014, 12:08:03 PM |
|
Just a question from experience at middlepool: Does the new endpoints synchronize? I'm asking because when middlepool put up a new EU endpoint, it behaved differently from the original endpoints - which was rather annoying profit wise.
I'm not sure what you mean by synchronize. The profitability switcher switches all of the endpoints at once (give or take latency times, etc). The stats are dumped from endpoints in batches to the main servers to handle aggregation/etc. This happens every few seconds (10-15), and is the same delay as with the original servers (just the wafflepool.com endpoint). Essentially the endpoints behave identically to the original endpoint, just with better geolocation. Stats should be damn-near realtime (just like before). All of the new endpoints are redundant as well (4x stratum servers per new endpoint). Should something happen like the last few days (stratum server being non-responsive), we have watchdogs in place that will restart it within a minute (this will be sped up soon). If that didn't answer your question, let me know a bit more of what you meant, so I can be of more help Exactly the answer i was looking for. Thanks.
|
|
|
|
boubou
|
|
February 06, 2014, 01:53:11 PM |
|
casinocoin is broken, we only get orphans, wtf Same with alphacoins... It's either a bug in the screen, or a total waste of power, since a whole day.
|
BEHNZiP6UZunp41vurNaQi4r2hvgG57yzi : BdG
|
|
|
rallasnackbar
|
|
February 06, 2014, 02:04:04 PM |
|
casinocoin is broken, we only get orphans, wtf Same with alphacoins... It's either a bug in the screen, or a total waste of power, since a whole day. i dont care, i made 0.01667335 btc in 24hours with only 1.1mhash/s
|
|
|
|
poolwaffle (OP)
|
|
February 06, 2014, 04:17:32 PM |
|
casinocoin is broken, we only get orphans, wtf Same with alphacoins... It's either a bug in the screen, or a total waste of power, since a whole day. Its a display issue, trying to figure it out right now. For some reason the blocks are doing an odd path: immature --> orphaned --> generate (instead of immature --> generate). Not sure why. Checking through the blocks, they're majority paid (a few orphans, but not above normal), its just the earnings log that shows them funny.
|
|
|
|
boubou
|
|
February 06, 2014, 04:47:37 PM |
|
Same thing I was thinking.
Thanks for your answer. I switch back.
|
BEHNZiP6UZunp41vurNaQi4r2hvgG57yzi : BdG
|
|
|
poolwaffle (OP)
|
|
February 06, 2014, 05:31:37 PM Last edit: February 06, 2014, 05:54:22 PM by poolwaffle |
|
Website will be back up in a few minutes here, nothing visible changed, just backend stuff. Things on the immediate list for late tonight/tomorrow: 1) Optional starting vardiff for stratum. 2) Changing the display of the earnings log. It will be cleaner, and easier to understand. We're also going to start pruning older data (started tonight), probably keeping 2-3 days of data depending on pool size. As we've been growing, logs have been getting bigger and bigger, and that is a major piece 3) We're going to start removing some of the coins that we support, for a few reasons (see below) Coin removals: We're currently monitoring about 30 blockchains for transactions/blocks/etc. This becomes reasonably expensive, and its about time to remove a few coins. The coins we'll be removing aren't finalized yet, but there are some obvious ones that we can remove that I don't think will affect profitability much at all. Some of these are coins that, unless something drastically changes in price/difficulty, are not going to normally be profitable, things like litecoin/feathercoin. Some others are coins that we cannot mine efficiently (and shouldn't have been added in the first place), coins like fastcoin. These coins are rarely profitable, and even when they _look_ profitable, its hard to tell, as block times are so quick (12s average on fastcoin), that any latency whatsoever causes a huge number of orphans, and we mine them rarely enough that our orphan calculations are normally skewed back to "ok to mine". Removing these coins will give us more headroom for adding new coins as they show up (CAT/MEOW, looking at you guys). The only issue with removing coins, is in some cases, there is a tiny bit of them left, that cannot be exchanged at the current quantity. For example, bitbar, we have a total of 0.03 BTB, worth 0.0022 BTC, which is under the threshold for trading on Cryptsy. Transferring them off to another exchange is a hassle, and a decent amount will be eaten up by transaction fees. Unless there is any major opposition, those leftover amounts would be left in the exchange account for if we start mining that coin again (at which point they'll go right back into normal exchange cycles). If we don't ever end up mining that coin again, either they'll be considered a donation to the pool, or we'll have a vote here to decide what to do with them. Thoughts?
|
|
|
|
Daltonganger
Newbie
Offline
Activity: 30
Merit: 0
|
|
February 06, 2014, 05:59:22 PM |
|
Poolwaffle, Like the idea of removing worthless coins. Can you do something about the big exchange problem at the moment? More then 85% is unexchanged. Hope you fix it before payout ! Greets Daltonganger P.s. love the latency with my 3 mile away server (EU)
|
|
|
|
qsrab
Newbie
Offline
Activity: 56
Merit: 0
|
|
February 06, 2014, 06:01:15 PM |
|
The BTC per mhash is lower than if we mined litecoin directly! Looks like a real orphan problem (maybe somethign else too?. Instead of removing coins like fastcoin, just adjust for orphans
|
|
|
|
qsrab
Newbie
Offline
Activity: 56
Merit: 0
|
|
February 06, 2014, 06:04:36 PM |
|
Maybe it is just being calculated incorrectly? You should give users personal BTC/mhash based on BTC paid divided by sum of submitted share difficulty.
Edit: in particular i think you might be calculating it by past 24 hours bitcoins divided by current hashrate when you need to sum it all instead of using current hashrate
|
|
|
|
phzi
|
|
February 06, 2014, 06:20:22 PM |
|
Coin removals: <snip>
Unless there is any major opposition, those leftover amounts would be left in the exchange account for if we start mining that coin again (at which point they'll go right back into normal exchange cycles). If we don't ever end up mining that coin again, either they'll be considered a donation to the pool, or we'll have a vote here to decide what to do with them.
Thoughts? Just keep the fractions of coins for dropped chains. They equate to barely anything when you divide them up anyway. I'm okay with you considering it a donation for your efforts. No idea why I lost shares for an hour last night eh? Was weird, but at least I noticed it so not much income lost. --- Maybe it is just being calculated incorrectly? You should give users personal BTC/mhash based on BTC paid divided by sum of submitted share difficulty.
Edit: in particular i think you might be calculating it by past 24 hours bitcoins divided by current hashrate when you need to sum it all instead of using current hashrate
So far, BTC/MH seems to be consistently a bit higher then reported on the main page. That said, the orphan rate being reported was bugged - poolwaffle noted this a few posts above you.
|
|
|
|
eMiz0r
Member
Offline
Activity: 60
Merit: 10
|
|
February 06, 2014, 06:23:03 PM |
|
Still the rejectrate is kinda sick low. I've got one GPU that has 2045160 accepted shares and 1920 rejected. That's less than 0,1%... (connected to main server wafflepool.com and living near Amsterdam). Also nice to see hashrate is climbing. Glad I switched over from middlecoin I'm also behind moving some coins from the list. It probably wouldn't hurt earnings, but it will definately make it more managable in serverload terms. Rather add some new profitable coins then keep existing that almost aren't mined at all. I'm personally not bothered by leftovers added to the pool's funding to make it even more awesome
|
|
|
|
|