maunderingcabal
Full Member
Offline
Activity: 154
Merit: 100
Don't dwell in the past, don't dream of the future
|
|
February 13, 2013, 05:43:55 AM |
|
Bad luck has put a distaste in my mouth in regards to this pool. I have finally gotten sick of running my mine for hours with no payout, then hours after I stop and game on my computer there are like 3 blocks solved... Back to PPS I guess, I least I know what I'm going to get.
|
|
|
|
slush
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
February 13, 2013, 11:10:17 AM |
|
Depending on the performance results (specifically looking at the time it takes for bitcoind to return information needed for a new block), other servers may migrate to solid state drives/bare hardware in the future.
Did you consider SSD lifetime? I've been running on SSD RAID for a year, but I didn't have good feeling from that SSD setup. Especially RAID of two SSD from the same vendor and the same age doesn't have too much sense. I migrated to standard HDD RAID + blockchain in RAMdisk + periodic HDD snapshots. It's even faster and seems to be a safer solution.
|
|
|
|
irishmick
|
|
February 13, 2013, 01:55:54 PM |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
February 13, 2013, 02:01:21 PM |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss. If I understand you correctly, that is the expected behaviour for PPLNS. As the hashrate increases, you get fewer shares per shift, but the same number of shares per day and the same number of coin per week.
|
|
|
|
irishmick
|
|
February 13, 2013, 02:03:54 PM |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss. If I understand you correctly, that is the expected behaviour for PPLNS. As the hashrate increases, you get fewer shares per shift, but the same number of shares per day and the same number of coin per week. Ahh good point. Thank you. I feel stupid... Thanks ;o) Staying with BTCGuild Yea!
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 13, 2013, 04:54:55 PM |
|
Yes, with the increase in hash speed, shifts are now being closed about 25% faster, meaning your shares per shift will be ~25% lower than before. However, you will be participating in more shifts overall, and the blocks per shift shouldn't change (outside of the regular variance), so the payments should be similar for each shift, and for a 24-hour period.
Right now I'm leaving the PPLNS settings alone, but I will be looking into extending the 'N' value if difficulty hits 4~5 million, to lower the odds of shifts with 0 blocks found and help smooth the per-shift variance back down to the original levels.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 03:56:09 AM |
|
BTC Guild website host node is acting up again. Working on a fix. All stratum servers are working fine. One getwork server may be having slow performance since it shares a node with the website. Will update shortly.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 04:04:34 AM Last edit: February 14, 2013, 04:55:42 AM by eleuthria |
|
What a surprise. DDoS attack. Will update again shortly.
UPDATE1: It's not completely taking things offline, it's mostly affecting the website. As best I can tell, most Stratum servers are still functioning. UPDATE2: Things seem to be back to normal. Waiting on an email from the datacenter to find out more about it. UPDATE3: Total downtime was ~15 minutes (less for most servers). Everything is back to normal and the datacenter has my servers on watch tonight with instruction to call me immediately if something happens again.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
fcmatt
Legendary
Offline
Activity: 2072
Merit: 1001
|
|
February 14, 2013, 05:47:42 AM |
|
Does the datacenter filter for you or blackhole and then change ip? If filter... Is it costing you a lot?
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 05:54:49 AM |
|
Does the datacenter filter for you or blackhole and then change ip? If filter... Is it costing you a lot?
It's a mix of both. They can filter some attacks, while others are blackholes. It's one of the reasons my colocated servers there run with virtualization, it makes it very easy to migrate the services over different IPs when blackholes are required. I've actually got two extra subnets already reserved at the DC for my use that I can switch to if an attack ever targeted my current subnet ranges.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
Fiyasko
Legendary
Offline
Activity: 1428
Merit: 1001
Okey Dokey Lokey
|
|
February 14, 2013, 06:00:23 AM |
|
HURRAH! the ASIC is in the BTC Guild! Im so happy , i do hope that he stays, i for one have been getting higher payouts! Wooooo! Who IS this guy and what gearcis he running?
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 06:01:46 AM |
|
Higher payouts are a factor of MASSIVE luck today . But with this user in the pool, it should help shrink the daily variance a bit.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 06:27:53 AM |
|
User 67117 has now become the first connection on Stratum to reach a 4-digit variable difficulty.
[00:39:31] Increasing [obfuscated]'s difficulty to 1024!
What does that mean? It means somebody mining at 1.5+ TH/s is using roughly as much bandwidth and server resources as a miner running a graphics card over Stratum, and LESS bandwidth than a graphics card using the outdated getwork protocol.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
-ck
Legendary
Offline
Activity: 4284
Merit: 1645
Ruu \o/
|
|
February 14, 2013, 09:38:03 AM |
|
User 67117 has now become the first connection on Stratum to reach a 4-digit variable difficulty.
[00:39:31] Increasing [obfuscated]'s difficulty to 1024!
What does that mean? It means somebody mining at 1.5+ TH/s is using roughly as much bandwidth and server resources as a miner running a graphics card over Stratum, and LESS bandwidth than a graphics card using the outdated getwork protocol.
Sounds great! Do you use the client.get_version command with your stratum implementation? It would be interesting to know what software they apparently run.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 09:47:14 AM |
|
User 67117 has now become the first connection on Stratum to reach a 4-digit variable difficulty.
[00:39:31] Increasing [obfuscated]'s difficulty to 1024!
What does that mean? It means somebody mining at 1.5+ TH/s is using roughly as much bandwidth and server resources as a miner running a graphics card over Stratum, and LESS bandwidth than a graphics card using the outdated getwork protocol.
Sounds great! Do you use the client.get_version command with your stratum implementation? It would be interesting to know what software they apparently run. I've not added client.get_version yet. It's one of those commands that offers fairly limited use. I'll probably add it in the coming weeks as I continue to work on more diagnostic utilities in my Stratum code. I do know that they are using a Stratum Proxy (most likely slush's proxy) to run all their workers through one connection.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
slush
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
February 14, 2013, 12:54:29 PM |
|
I do know that they are using a Stratum Proxy (most likely slush's proxy) to run all their workers through one connection.
Good to know that the proxy can handle such load :-).
|
|
|
|
Liquid
|
|
February 14, 2013, 04:21:17 PM |
|
|
Bitcoin will show the world what hard money really is.
|
|
|
dresdenreader
|
|
February 14, 2013, 06:30:32 PM |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss. If I understand you correctly, that is the expected behaviour for PPLNS. As the hashrate increases, you get fewer shares per shift, but the same number of shares per day and the same number of coin per week. Assuming my hash rate doesn't change, if I'm seeing higher than 100% PPS only 10% of the time and the rest of the time its around 50-60%, wouldn't I still be making more by just doing straight PPS? i.e. in order for me to break even, I need block per shift to be at least 9, there are occasional strings of shifts that run 9+ for 10 or so shifts, but this maybe happens once a week. The majority of the time the block per shift is between 4-8 (outside of green). Again, assuming my hash rate doesn't change and I'm submitting the same number of shares, aren't I still making more BTC by doing PPS instead? I know that all PPLNS is pretty much just luck, but if difficulty is constantly increasing, won't this luck just continue to get worse and worse as more ASICs are added to the fold?
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
February 14, 2013, 06:41:13 PM Last edit: February 14, 2013, 07:02:31 PM by eleuthria |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss. If I understand you correctly, that is the expected behaviour for PPLNS. As the hashrate increases, you get fewer shares per shift, but the same number of shares per day and the same number of coin per week. Assuming my hash rate doesn't change, if I'm seeing higher than 100% PPS only 10% of the time and the rest of the time its around 50-60%, wouldn't I still be making more by just doing straight PPS? i.e. in order for me to break even, I need block per shift to be at least 9, there are occasional strings of shifts that run 9+ for 10 or so shifts, but this maybe happens once a week. The majority of the time the block per shift is between 4-8 (outside of green). Again, assuming my hash rate doesn't change and I'm submitting the same number of shares, aren't I still making more BTC by doing PPS instead? I know that all PPLNS is pretty much just luck, but if difficulty is constantly increasing, won't this luck just continue to get worse and worse as more ASICs are added to the fold? PPLNS has paid more than PPS consistently over the last month. The problem is you focus on bad shifts and don't acknowledge the good shifts (its human nature to dwell on the negatives). If you were mining with two identical speed workers, one on PPS, one on PPLNS this month, you would have made somewhere around 110% PPS on the PPLNS worker. Bad luck drags on longer than good luck, it's just how it works (due to bad luck requiring significant time to be considered bad luck). But if you get one shift of 15 blocks, that makes up for 6 shifts of 8 blocks, or 3 shifts of 7 blocks. And generally when you get a really big shift like that, you have a few others similarly above the average. Examples with real data: The last 90 MATURED shifts (you cannot include open shifts) have averaged 9.3 blocks per shift, AKA: 0.0000076339143/share (more than 100% PPS). The last 190 matured shifts have averaged 9.48 blocks/shift, or 0.00000777397457/share, which is 2% above 0%-fee PPS.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
dresdenreader
|
|
February 14, 2013, 07:05:26 PM |
|
My shares per shift is going down coinciding with the overall pool hash going up and not by a negligable amount. I am getting at least 40% less shares consistently than when the pool hash was between 3-3.5K. Also a month or two back where all miners had to restart their machines/proxy to reconnect I was getting +25% shares per shift consistently until miners reconnected. Sorry but I may have to switch pools. I'd rather not as I have the least problems with your pool, but a little hassle is better than a 1-3% fee and a 40% share loss. If I understand you correctly, that is the expected behaviour for PPLNS. As the hashrate increases, you get fewer shares per shift, but the same number of shares per day and the same number of coin per week. Assuming my hash rate doesn't change, if I'm seeing higher than 100% PPS only 10% of the time and the rest of the time its around 50-60%, wouldn't I still be making more by just doing straight PPS? i.e. in order for me to break even, I need block per shift to be at least 9, there are occasional strings of shifts that run 9+ for 10 or so shifts, but this maybe happens once a week. The majority of the time the block per shift is between 4-8 (outside of green). Again, assuming my hash rate doesn't change and I'm submitting the same number of shares, aren't I still making more BTC by doing PPS instead? I know that all PPLNS is pretty much just luck, but if difficulty is constantly increasing, won't this luck just continue to get worse and worse as more ASICs are added to the fold? PPLNS has paid more than PPS consistently over the last month. The problem is you focus on bad shifts and don't acknowledge the good shifts (its human nature to dwell on the negatives). If you were mining with two identical speed workers, one on PPS, one on PPLNS this month, you would have made somewhere around 110% PPS on the PPLNS worker. Examples: The last 90 MATURED shifts (you cannot include open shifts) have averaged 9.3 blocks per shift, AKA: 0.0000076339143/share (more than 100% PPS). The last 190 matured shifts have averaged 9.48 blocks/shift, or 0.00000777397457/share, which is 2% above 0%-fee PPS. For those negative nancies like myself, would it be possible to start getting information like this put somewhere on the PPLNS Shift History page? I think it might get more people to stick with PPLNS through the phases of bad luck if they had some stats they could look at that verified the average yield of blocks per shift. Putting it simply, that information you just posted about the last 90 Matured sprints, I don't have access to (unless I were to track it myself and do the math myself, all of which I don't have time for).
|
|
|
|
|