Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 21. (Read 163898 times)
September 29, 2013, 01:34:16 PM
gah, crashed (froze) for some reason... restarting with d=512. fingers crossed!
September 29, 2013, 12:29:49 PM
If memory serves, I'm supposed to use 780/1.4 = 557, so should I use d=512? Does it matter if it's not a multiple of 2?
I don't think it matters much if it's a power of 2. It might reduce variance a bit, but that would even out over time anyway. September 29, 2013, 12:26:23 PM
Sounds good, thanks.
After restarting, things are fine. when it doubt, reboot!
I'm using d=64 which may or may not be why it's running fine, too.
I'll switch to d=512 next time I'm messing with it.
However, I'm going to sell much of my gear for cash this week, so I'll need to re-evaluate anyway.
September 29, 2013, 12:14:41 PM
September 29, 2013, 10:49:33 AM
Looks like the stats page is displaying expected payout and rate fine.
http://mmpool.bitparking.com/blockstats
Must be something on the username page that's buggy. That's what's my check scrypt checks against though, so I'll keep getting e-mails every 10 minutes until it's updated, haha.
No worries, I can hit "delete" just fine
http://mmpool.bitparking.com/blockstats
Must be something on the username page that's buggy. That's what's my check scrypt checks against though, so I'll keep getting e-mails every 10 minutes until it's updated, haha.
No worries, I can hit "delete" just fine
ok, starting to think the stats page is just slower to change given that it's a 40+ hour average display.
Restarted using difficulty 64 for 780 GH/s. Gonna see if that affects anything.
If memory serves, I'm supposed to use 780/1.4 = 557, so should I use d=512? Does it matter if it's not a multiple of 2?
September 29, 2013, 08:30:21 AM
Looks like the stats page is displaying expected payout and rate fine.
http://mmpool.bitparking.com/blockstats
Must be something on the username page that's buggy. That's what's my check scrypt checks against though, so I'll keep getting e-mails every 10 minutes until it's updated, haha.
No worries, I can hit "delete" just fine
http://mmpool.bitparking.com/blockstats
Must be something on the username page that's buggy. That's what's my check scrypt checks against though, so I'll keep getting e-mails every 10 minutes until it's updated, haha.
No worries, I can hit "delete" just fine
September 29, 2013, 08:12:45 AM
Cool, so are you saying if I use d=16 with 780 GH, then I'll just be wasting bandwidth? Or are there any other downsides?
You'd be wasting bandwidth on both ends and load on the pool server as it has to keep track of all those additional shares.gotcha, but sounds like we can't quantify this?
I'll look into changing this as soon as work slows down (hopefully after Oct 1).
However, I notice my GH reported on the pool has been about 50-75% of what I'm running for the past 10-16 hours (was at a wedding).
Are other people experiencing this, or do I need to restart my miners? I checked before I left for work, and everything looks normal on my end with BFGMiner displaying a rate of 780 GH ish
September 28, 2013, 12:04:39 PM
Cool, so are you saying if I use d=16 with 780 GH, then I'll just be wasting bandwidth? Or are there any other downsides?
You'd be wasting bandwidth on both ends and load on the pool server as it has to keep track of all those additional shares. September 28, 2013, 07:43:07 AM
Any thoughts of user diff for 120Gh/s? I have it running at d=12 at the moment.
120/1.4=~86Round that to 64 or 128 if you prefer going by factors of 2.
Can I ask what the 1.4 is? just trying to understand it all.
Thanks for the info!
Cool, so are you saying if I use d=16 with 780 GH, then I'll just be wasting bandwidth? Or are there any other downsides?
September 27, 2013, 08:10:41 PM
Any thoughts of user diff for 120Gh/s? I have it running at d=12 at the moment.
120/1.4=~86Round that to 64 or 128 if you prefer going by factors of 2.
Can I ask what the 1.4 is? just trying to understand it all.
Thanks for the info!
September 27, 2013, 06:31:04 PM
Any thoughts of user diff for 120Gh/s? I have it running at d=12 at the moment.
120/1.4=~86Round that to 64 or 128 if you prefer going by factors of 2.
Can I ask what the 1.4 is? just trying to understand it all.
Thanks for the info!
September 27, 2013, 06:27:38 PM
Any thoughts of user diff for 120Gh/s? I have it running at d=12 at the moment.
120/1.4=~86Round that to 64 or 128 if you prefer going by factors of 2.
September 27, 2013, 06:12:20 PM
Any thoughts of user diff for 120Gh/s? I have it running at d=12 at the moment.
September 24, 2013, 09:11:02 AM
I'm sorry for being such a pain in a backside but I would like to take BTC out of my old accaunt(new coins) but I can't do that till you make recalculations. Any ETA?
Sorry about the delay, I've be waiting until I've found and resolved the issue so I can do a one time correction. Unfortunately it happened again last night so now I've put in code to attempt to detect the issue when it happens and autocorrect. This means going forward the bug, while still existant, won't have an effect. Now that that's done I'll revisit the uncorrected blocks and do a fixup. What I'll probably end up doing is a btc payment to all the affected accounts based on the affect the extra blocks had.thanks for the update! Keep up the awesome!
September 24, 2013, 08:59:50 AM
I'm sorry for being such a pain in a backside but I would like to take BTC out of my old accaunt(new coins) but I can't do that till you make recalculations. Any ETA?
Sorry about the delay, I've be waiting until I've found and resolved the issue so I can do a one time correction. Unfortunately it happened again last night so now I've put in code to attempt to detect the issue when it happens and autocorrect. This means going forward the bug, while still existant, won't have an effect. Now that that's done I'll revisit the uncorrected blocks and do a fixup. What I'll probably end up doing is a btc payment to all the affected accounts based on the affect the extra blocks had. 
September 23, 2013, 01:19:20 PM
I'm sorry for being such a pain in a backside but I would like to take BTC out of my old accaunt(new coins) but I can't do that till you make recalculations. Any ETA?
Or is there a way you would merge accounts they have same BTC address so it should not be a problem...
Or is there a way you would merge accounts they have same BTC address so it should not be a problem...
September 22, 2013, 11:30:17 PM
I need help setting this up with guiminer, can anybody help?
sent you my e-mail via PM
September 22, 2013, 11:26:12 PM
I need help setting this up with guiminer, can anybody help?
September 22, 2013, 09:51:50 AM
Whats the reason that every found block that only took a couple minutes to find is thrown away? Should i believe that everytime another miner was faster? I mean we found a block and always its too late? Why doesnt this happen with blocks found after a longer time? If other miners were faster to propagate then blocks that took longer should be lost too. But its only the fast blocks. I dont see the logic behind.
And when this pool has a bad connection to the network, so that other miners can propagate faster... why not change this?
Im not sure what to think about this.
Those short blocks aren't found. It's a bug in the pool software I'm using that occasionally reports a double finding of a block. I'm trying to track it down. If you read the thread on the HHTT pool they're having the same issue (I use the same software as them in the backend for Stratum users).And when this pool has a bad connection to the network, so that other miners can propagate faster... why not change this?
Im not sure what to think about this.
Ok. Thanks for the answer.
September 22, 2013, 07:47:14 AM
Whats the reason that every found block that only took a couple minutes to find is thrown away? Should i believe that everytime another miner was faster? I mean we found a block and always its too late? Why doesnt this happen with blocks found after a longer time? If other miners were faster to propagate then blocks that took longer should be lost too. But its only the fast blocks. I dont see the logic behind.
And when this pool has a bad connection to the network, so that other miners can propagate faster... why not change this?
Im not sure what to think about this.
Those short blocks aren't found. It's a bug in the pool software I'm using that occasionally reports a double finding of a block. I'm trying to track it down. If you read the thread on the HHTT pool they're having the same issue (I use the same software as them in the backend for Stratum users). And when this pool has a bad connection to the network, so that other miners can propagate faster... why not change this?
Im not sure what to think about this.
Jump to: