Pages:
Author

Topic: [9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 38. (Read 163780 times)

hero member
Activity: 826
Merit: 1000
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...
legendary
Activity: 1078
Merit: 1005
So fees are still kept by pool right?
Correct, transaction fees are currently used to build the pool reserves.
legendary
Activity: 2912
Merit: 1060
So fees are still kept by pool right?
legendary
Activity: 1078
Merit: 1005
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.

Quote
Thanks. Any chance of getting the rest of the information I asked for? It would be most useful.
sr. member
Activity: 399
Merit: 250
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

legendary
Activity: 1078
Merit: 1005
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.
sr. member
Activity: 399
Merit: 250
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.



Quote
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!
legendary
Activity: 1078
Merit: 1005
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 [email protected] 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!
legendary
Activity: 1726
Merit: 1018
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?
legendary
Activity: 1078
Merit: 1005
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:

Quote
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.


legendary
Activity: 1078
Merit: 1005
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.
sr. member
Activity: 399
Merit: 250
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


legendary
Activity: 1726
Merit: 1018
It appears that not all of my shares are being counted.  I restarted my miners right at the last block to make it easier to count, and since I have been seeing a discrepancy lately, and about 20% of the submitted shares are not showing on the stats page.  No errors on my end.  Shares are not being reported as rejected.

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.

Is it possible the missing shares have not been added to the stats yet?  Twenty percent seems like a large portion to be missing especially 4 hours into the block.

I only have 2 miners (400Ghs each).  They are both connecting on port 3333 using the same credentials.  Given that about 1/5th of the shares are not being reported on the stats page it is not a problem with one miner working and one not.  There are too many shares reported for one miner but not enough for them both.
legendary
Activity: 1078
Merit: 1005
Why in your GUI can we not get  access to the orphaned data(block number)?
Block numbers are available here. Block 242,435 is the one referred to.
legendary
Activity: 1078
Merit: 1005
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.
sr. member
Activity: 399
Merit: 250
I would like to know the % of orphans other pools have, because I still have the feeling that this pool has a fairly high ratio.
This most recent orphan was caused by a bitcoind issue that an emergency patch was supplied for. The issue caused the bitcoin daemon that the pool daemon was hidden behind to crash due to OOM and the pool daemon no longer received updates. It's unfortunate but not much could be done about bitcoind bugs.

This one, or are we talking about another one?

Quote
2013-06-20 11:52   08:03:57   0.02035677   19,905   orphaned


Why in your GUI can we not get  access to the orphaned data(block number)?
sr. member
Activity: 399
Merit: 250
Yep this is just too much.......
The pool is continually playing up.
This is the first I've heard of this. Are you on getwork or stratum?

giving the miners work then continually rejecting it.... with "unknown-work"
'unknown-work' means work is being submitted to the pool that it didn't serve. 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?


Seriously.......
Quote
This is the first I've heard of this. Are you on getwork or stratum?

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


I have TWO Identical accounts under different usernames on the servers with IDENTICAL settings and yet one continually plays up.

I.E
Quote
Stratum worker authorization timed out


Quote
2013-06-21 18:31:22.532   [400]       *USERID*_Stratum2:    Successfully subscribed to Stratum service

Quote
2013-06-21 18:31:25.196   [350]   Worker_H01_12:    Found share:
2013-06-21 18:31:26.153   [200]   Worker_H01_03:    *USERID*_Stratum2 rejected share d90a6a63 (difficulty 1.54167): timed out
......
2013-06-21 18:31:27.354   [350]   Worker_FRA_03:    Found share: *USERID*_Stratum2:00000002724d64614a9b4728e0935112926ff809d2b5478e2f3984490000003a00000000b9bb6c2 19d3945c0836d8f309f98b421428ac9cc1b6b6b5f868d1a37a113d2dd51c42b511a00de15:b9352787
2013-06-21 18:31:27.355   [200]   Worker_FRA_03:    *USERID*_Stratum2 rejected share b9352787 (difficulty 10.32996): Connection is not active



And yet I have  ZERO problems with elgius,BTCguild,ABCpool
50BTC gives me problems when it is DOS'ed

So why is it that one account mines fine and yet another is continually a problem, or is it that the 'new' account is the only one that works reliably ?
hero member
Activity: 826
Merit: 1000
I would like to know the % of orphans other pools have, because I still have the feeling that this pool has a fairly high ratio.
I can tell you that all pools have problems since 0.8.1. Before that it was normal to have 1 to 2 %. Slush record is 3 orphans in a day... It is more of a bitcoind issues lately. I first thought WTF but when I got explanation I perfectly OK with it.
legendary
Activity: 1078
Merit: 1005
I would like to know the % of orphans other pools have, because I still have the feeling that this pool has a fairly high ratio.
This most recent orphan was caused by a bitcoind issue that an emergency patch was supplied for. The issue caused the bitcoin daemon that the pool daemon was hidden behind to crash due to OOM and the pool daemon no longer received updates. It's unfortunate but not much could be done about bitcoind bugs.
full member
Activity: 188
Merit: 100
I would like to know the % of orphans other pools have, because I still have the feeling that this pool has a fairly high ratio.
Pages:
Jump to: