[9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining

[doublec]

I have also noted some lag on the stats page where a few refreshes inside of a minute or so will show just about everything changing except my shares, and then If I keep refreshing eventually the shares will jump by a significant portion.

There is a number of delays between a share being submitted and stats being shown on the stats page. The page itself is cached by the webserver for a number of seconds to reduce load. This means it is always behind. When you submit a share the share the result of that submit (rejected, accepted) goes into a queue. That share is submitted to the database when the queue is processed. This can take some time depending on pool load, database activities, etc. Once it's processed from the queue the web server can report it. This has been the apparent discrepancy in the times that others have reported issues.

[1714152841]

1714152841

[1714152841]

1714152841

[1714152841]

1714152841

[doublec]

I have been civil, and this is a poor attempt at deflection

You have not. You have not answered the questions I asked to track down the problem. Your response to my questions was "Seriously...". That's not being civil. If you really want to resolve the issue then to help find out the issue, please provide the information I asked for:

What mining software are you using? Do you have backup pools configured with it? Do you have any logs you can provide to look into it?

In particular, with regards to logs, if you can provide protocol dumps (cgminer uses "-P") that would be most useful.

[not.you]

I have also noted some lag on the stats page where a few refreshes inside of a minute or so will show just about everything changing except my shares, and then If I keep refreshing eventually the shares will jump by a significant portion.

There is a number of delays between a share being submitted and stats being shown on the stats page. The page itself is cached by the webserver for a number of seconds to reduce load. This means it is always behind. When you submit a share the share the result of that submit (rejected, accepted) goes into a queue. That share is submitted to the database when the queue is processed. This can take some time depending on pool load, database activities, etc. Once it's processed from the queue the web server can report it. This has been the apparent discrepancy in the times that others have reported issues.

Its about 500 shares low now and it was about 400 shares low 4 hours ago.  Does that sound about like the queue delay then if I am at 800Mhs?

[doublec]

Its about 500 shares low now and it was about 400 shares low 4 hours ago.  Does that sound about like the queue delay then if I am at 800Mhs?

No, that shouldn't be the delay. It would help to track down what's happening if you can email admin@bitparking.com with:

1) Your pool username
2) What miner your are using
3) Have you got any backup pools configured
4) Logs of a mining session that include lost shares. Something about 30 minutes long should cater for the delay.

The more detailed the logs the better but anything that includes submitted/rejected/accepted is helpful. If you could also let me know the timezone of the logs so I can match up with what's in the database that'd help.

Thanks!

[razorfishsl]

K the answer is a 'couple of hours', that is the apparent maximum the service is stable under a 4GH/s load...

Restarting the software and system clears it up for a bit of time, but then it comes back straight away.

2013-06-22 09:31:08.745   [200]   Hcfs_Stratum:    Stratum connection died:
2013-06-22 09:31:17.492   [200]   Hcfs_Stratum:    Stratum worker authorization timed out
2013-06-22 09:31:17.583   [200]   Worker_H01_03:    Exhausted keyspace!
2013-06-22 09:31:18.442   [350]   Worker_H01_04:    Found share: Hcfs_Stratum:000000021d00fba9f051baf49ea5c93b9597043ccd7b056dca8417ae0000009e00000000ddc4737 59cc28122b661db3a921ba97a15b145ce0b301186ce355c0d7805939051c4fe3b1a00de15:70fd37e9
2013-06-22 09:31:18.443   [200]   Worker_H01_04:    Hcfs_Stratum rejected share 70fd37e9 (difficulty 2.64623): Connection is not active
2013-06-22 09:31:19.499   [350]   Worker_FRA_07:    Found share: Hcfs_Stratum:000000021d00fba9f051baf49ea5c93b9597043ccd7b056dca8417ae0000009e0000000044993ac bea503dddad109fa02ba167228acc57c6079c60f14f152e69f066a55751c4fe311a00de15:d7a50408
2013-06-22 09:31:19.500   [200]   Worker_FRA_07:    Hcfs_Stratum rejected share d7a50408 (difficulty 1.21972): Connection is not active
2013-06-22 09:31:20.193   [200]   Worker_H01_10:    Exhausted keyspace!
2013-06-22 09:31:20.526   [200]   Worker_H01_09:    Exhausted keyspace!
2013-06-22 09:31:20.617   [200]   Worker_H01_11:    Exhausted keyspace!
2013-06-22 09:31:20.747   [200]   Worker_H01_07:    Exhausted keyspace!
2013-06-22 09:31:20.782   [200]   Worker_H01_08:    Exhausted keyspace!
2013-06-22 09:31:22.464   [200]   Worker_H02_01:    Exhausted keyspace!
2013-06-22 09:31:24.280   [350]   Worker_FRA_04:    Found share: Hcfs_Stratum:000000021d00fba9f051baf49ea5c93b9597043ccd7b056dca8417ae0000009e000000008e47716 0f0fe7087894e5d89188d0dc980da78a99701a93e2d39abfc5144cf2f51c4fe341a00de15:af40df20
2013-06-22 09:31:24.283   [200]   Worker_FRA_04:    Hcfs_Stratum rejected share af40df20 (difficulty 23.14465): Connection is not active
2013-06-22 09:31:26.158   [350]   Worker_FRA_04:    Found share: Hcfs_Stratum:000000021d00fba9f051baf49ea5c93b9597043ccd7b056dca8417ae0000009e000000008e47716 0f0fe7087894e5d89188d0dc980da78a99701a93e2d39abfc5144cf2f51c4fe341a00de15:9ddfae31
2013-06-22 09:31:26.159   [200]   Worker_FRA_04:    Hcfs_Stratum rejected share 9ddfae31 (difficulty 2.20841): Connection is not active
2013-06-22 09:31:26.364   [350]   Worker_H01_04:    Found share: Hcfs_Stratum:000000021d00fba9f051baf49ea5c93b9597043ccd7b056dca8417ae0000009e00000000ddc4737 59cc28122b661db3a921ba97a15b145ce0b301186ce355c0d7805939051c4fe3b1a00de15:5cac7d39
2013-06-22 09:31:26.364   [200]   Worker_H01_04:    Hcfs_Stratum rejected share 5cac7d39 (difficulty 1.82548): Connection is not active
2013-06-22 09:31:29.974   [200]   Worker_H02_02:    Exhausted keyspace!

[doublec]

K the answer is a 'couple of hours', that is the apparent maximum the service is stable under a 4GH/s load...

Given that there are miners mining with 100+ GH/s I don't think that's true. Again, what miner are you using. Do you have backup pools configured. Can you paste, PM or email the command line and/or configuration file you use for the pool. There's obviously something wrong with either your setup or the pool's setup such that it doesn't like something your mining software is doing and it'd be good to work out what it is.

[razorfishsl]

K the answer is a 'couple of hours', that is the apparent maximum the service is stable under a 4GH/s load...

Given that there are miners mining with 100+ GH/s I don't think that's true. Again, what miner are you using. Do you have backup pools configured. Can you paste, PM or email the command line and/or configuration file you use for the pool. There's obviously something wrong with either your setup or the pool's setup such that it doesn't like something your mining software is doing and it'd be good to work out what it is.

Well ,
The fact is my post is clearly time stamped, from the time I posted the "yellowed" out image, to the date  & time stamp in my last post.

Miner
https://github.com/TheSeven/Modular-Python-Bitcoin-Miner

[doublec]

The fact is my post is clearly time stamped, from the time I posted the "yellowed" out image, to the date  & time stamp in my last post.

I'm not sure what this is referring to.

Miner
https://github.com/TheSeven/Modular-Python-Bitcoin-Miner

Thanks. Any chance of getting the rest of the information I asked for? It would be most useful.

[bitpop]

So fees are still kept by pool right?

[doublec]

So fees are still kept by pool right?

Correct, transaction fees are currently used to build the pool reserves.

[Lucko]

So fees are still kept by pool right?

Correct, transaction fees are currently used to build the pool reserves.

You do know what you say when implementing new system?

With regards to transaction fees I've not yet enabled the payment of these to users - the pool still keeps them - but I expect to do that in the next day or two once the orphan code has settled.

So you are kind of eating up your words. I thought you have problems implementing...

[bitpop]

I support you bitparking

[doublec]

So you are kind of eating up your words. I thought you have problems implementing...

No, I'm not eating my words. Transactions fees are currently being used to build pool reserves. I'm also implementing support for paying transactions fees. That support is not yet done. In the meantime I'm letting you know what they're being used for, hence 'currently'.

[Lucko]

So you are kind of eating up your words. I thought you have problems implementing...

No, I'm not eating my words. Transactions fees are currently being used to build pool reserves. I'm also implementing support for paying transactions fees. That support is not yet done. In the meantime I'm letting you know what they're being used for, hence 'currently'.

OK sorry then... I though you have it ready...

[doublec]

OK sorry then... I though you have it ready...

Not yet unfortunately. The pool isn't my full time job so adding and testing features that involve risky things like payouts take a bit of time. The last lot of changes I did, regarding orphans, put in a bunch of stuff allowing transaction payments but I still need to do the rest.

[doublec]

Since the task of implementing transaction fee payout to miners is taking longer than expected I've made an adjustment to pool fees. From this moment the fee for DGM reduces from 1.5% to 0%. That is, there is no explicit fee on DGM mining for bitcoins. The pool continues to keep transaction fees. Once I've made the code changes to allow distribution of transaction fees I'll switch back to 1.5%. So for now, enjoy no fee DGM.

[bitpop]

Thanks

[not.you]

Since the task of implementing transaction fee payout to miners is taking longer than expected I've made an adjustment to pool fees. From this moment the fee for DGM reduces from 1.5% to 0%. That is, there is no explicit fee on DGM mining for bitcoins. The pool continues to keep transaction fees. Once I've made the code changes to allow distribution of transaction fees I'll switch back to 1.5%. So for now, enjoy no fee DGM.

woot!

[matt4054]

Since the task of implementing transaction fee payout to miners is taking longer than expected I've made an adjustment to pool fees. From this moment the fee for DGM reduces from 1.5% to 0%. That is, there is no explicit fee on DGM mining for bitcoins. The pool continues to keep transaction fees. Once I've made the code changes to allow distribution of transaction fees I'll switch back to 1.5%. So for now, enjoy no fee DGM.

Thanks a lot for this transitional change. It wasn't even expected from me but very much appreciated indeed.

[kjlimo]

You know I'm on strat because we HAVE discussed this.. that is why you 'retired' some servers.

I get quite a few emails and requests for support, it's helpful if you answer questions in a civil tone with the information requested so we can move towards a solution. If you're not willing to do this I suggest you mine elsewhere.

I have been civil, and this is a poor attempt at deflection

There is more than 20Gh I can point at your pool, but if I have to continually adjust my costings and monitor the setup so I don't loose money (something you are being paid to manage), then I can just as easily point it at Elgius.

You provide a chargeable service, perhaps it would be conducive to your pools health  if you started to act like it, or perhaps it is YOU that should not be in this business.

But I will take your suggestion.... If your system can hold together long enough to for me to meet the minimum target for payout.
To that end I have thrown 4GH/s at your pool to see how long it can go without serious issues, but the pool has already started to 'pull' downwards.
Elgius shows the same allocation as >4.4GH/s

I think you don't realize Doublec does this as a hobby... not a business...