[9 TH] Bitparking Pool, DGM 0%,vardiff,stratum,Merge Mining - page 62.

doublec

legendary

Activity: 1078

Merit: 1005

There's now a #mmpool irc channel on freenode irc for those that want to discuss the pool or get support.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: razorfishsl on May 02, 2013, 03:49:37 AM

That is what I am saying the results are not consistent, the 'get work server' should be 'worse', but it seems it is the most stable.
mmpool.bitparking.com:3333 .. seems to be ok

It looks like there's a network issue between the 'stratum2' server and the pool backend which is causing the problem. I'm looking into it but in the meantime I'll disable the stratum2 functionality. I've changed the DNS to point to the mmpool server and will shut it off when it has propogated. Thanks for pointing out the issue!

Edit: I'll also try the same mining software you are using to see if there's some incompatibility.

razorfishsl

sr. member

Activity: 399

Merit: 250

Quote from: doublec on May 01, 2013, 11:23:37 PM

Quote from: razorfishsl on May 01, 2013, 11:18:17 PM

...stratum2 issues....

Ok, thanks. I'm going to take stratum2/dgm2 out of rotation and see if I can find out what's going wrong with those servers. It sounds like 'mmpool.bitparking.com:3333' and 'mmpool.bitparking.com:4333' are fine? You mention '15098' but that's the getwork server.

Edit: What miner are you using?

That is what I am saying the results are not consistent, the 'get work server' should be 'worse', but it seems it is the most stable.
mmpool.bitparking.com:3333 .. seems to be ok

The miner software is:
https://github.com/TheSeven/Modular-Python-Bitcoin-Miner

Yep I know it is Gash and it is python... but none of the other mining software give me the 'simplers232' RS232 interface
which I use because it is easy to implement in the FPGA's (i know it works, so it is one less thing to check)
I've not found anyone who will write me some C++ code for a plugin so i can use another miner

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: razorfishsl on May 01, 2013, 11:18:17 PM

...stratum2 issues....

Ok, thanks. I'm going to take stratum2/dgm2 out of rotation and see if I can find out what's going wrong with those servers. It sounds like 'mmpool.bitparking.com:3333' and 'mmpool.bitparking.com:4333' are fine? You mention '15098' but that's the getwork server.

Edit: What miner are you using?

razorfishsl

sr. member

Activity: 399

Merit: 250

Quote from: doublec on May 01, 2013, 10:33:27 PM

Quote from: razorfishsl on May 01, 2013, 10:08:10 PM

and yet the non DMG strat is fine with no dropout:

Can you give me the exact servers you are connecting to. There is no "non DMG strat" anymore.

K there Is something wrong.

IF I submit EVERYTHING on the PPS section (yep i know it does not exist as PPS)

mmpool.bitparking.com:15098

my mining rate and credit is WAY higher using the same equipment (it is currently creeping up >1.65GH/s)
Because I have a couple of boards out I'm working on.
It should settle just < 2.0GH/s for this rig with a full load of boards.

stratum2.bitparking.com:4333 (what I call DGM)

gives all the errors and about 1GH/s, even with a full complement of boards (which is why I Fruitlessly spent the last 3 hours faultfinding)

stratum2.bitparking.com:3333

is also 'fine' if not loaded up with work, I.E if I start throwing load at it, then it starts to fail

Code:

PING stratum2.bitparking.com (50.116.38.44): 56 data bytes
64 bytes from 50.116.38.44: icmp_seq=0 ttl=56 time=228.456 ms
64 bytes from 50.116.38.44: icmp_seq=1 ttl=56 time=229.857 ms
64 bytes from 50.116.38.44: icmp_seq=2 ttl=56 time=229.272 ms
64 bytes from 50.116.38.44: icmp_seq=3 ttl=56 time=229.027 ms
64 bytes from 50.116.38.44: icmp_seq=4 ttl=56 time=229.550 ms
^C
--- stratum2.bitparking.com ping statistics ---
6 packets transmitted, 5 packets received, 16.7% packet loss
round-trip min/avg/max/stddev = 228.456/229.232/229.857/0.477 ms

Code:

PING mmpool.bitparking.com (206.71.179.116): 56 data bytes
64 bytes from 206.71.179.116: icmp_seq=0 ttl=53 time=194.617 ms
64 bytes from 206.71.179.116: icmp_seq=1 ttl=53 time=193.556 ms
64 bytes from 206.71.179.116: icmp_seq=2 ttl=53 time=194.526 ms
64 bytes from 206.71.179.116: icmp_seq=3 ttl=53 time=194.527 ms
64 bytes from 206.71.179.116: icmp_seq=4 ttl=53 time=194.383 ms
^C
--- mmpool.bitparking.com ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 193.556/194.322/194.617/0.390 ms

Code:

PING stratum.bitparking.com (206.71.179.116): 56 data bytes
64 bytes from 206.71.179.116: icmp_seq=0 ttl=53 time=193.621 ms
64 bytes from 206.71.179.116: icmp_seq=1 ttl=53 time=193.632 ms
64 bytes from 206.71.179.116: icmp_seq=2 ttl=53 time=194.077 ms
64 bytes from 206.71.179.116: icmp_seq=3 ttl=53 time=194.533 ms
^C
--- stratum.bitparking.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 193.621/193.966/194.533/0.376 ms

juhakall

sr. member

Activity: 658

Merit: 250

Quote from: Reckman on May 01, 2013, 11:54:45 AM

Can you explain the prolonged low luck? Over a period between Jan 17 to May 1, blockchain.com shows pool luck at 60 percent. Statistically this just doesn't seem likely.

That site claims that Eligius has had ~250% luck over the same period, with a total of 273 blocks. Why would you even consider Bitparking if you believed that site, Eligius is clearly enjoying some divine luck.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: razorfishsl on May 01, 2013, 10:08:10 PM

and yet the non DMG strat is fine with no dropout:

Can you give me the exact servers you are connecting to. There is no "non DMG strat" anymore.

razorfishsl

sr. member

Activity: 399

Merit: 250

I think if you don't sort out your pool soon, then I will be forced to switch.

It was mining fine at a consistent 1.8GH/s until you started to fool about . Now Your stratum is continually starving my rigs of work and it is down by 50%.
Really if you are going to roll out serious modifications, then you should be doing so on a test rig rather than just throwing them at a live server.

Quote

2013-05-02 10:53:58.237   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:53:58.264   [200]   Razorfishsl_stratum_DGM:    Received unexpected Stratum response: {u'id': 10000, u'method': u'client.get_version'}
2013-05-02 10:53:58.735   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:02.462   [200]   Worker_102:    Exhausted keyspace!
2013-05-02 10:54:04.541   [350]   Worker_104:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000003dbaf8e de3b2f661db9796ced5ec3cae20d12b3f94e46c9a657d49b60551dd965181d5151a01aa3d:380712aa
2013-05-02 10:54:04.584   [350]   Worker_107:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e00000000f16b670 e908afb03d426faec72e865c2af83c8c7657072e162470b8fa224a9e15181d5131a01aa3d:e83cdac2
2013-05-02 10:54:05.006   [250]   Worker_104:    Razorfishsl_stratum_DGM accepted share 380712aa (difficulty 1.43710)
2013-05-02 10:54:05.275   [250]   Worker_107:    Razorfishsl_stratum_DGM accepted share e83cdac2 (difficulty 1.92376)
2013-05-02 10:54:05.338   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:54:06.554   [350]   Worker_108:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000008f508d2 17634e141205c903dbb33db1f9386eb6a648805fb2ebdb49291d158645181d51e1a01aa3d:98746db7
2013-05-02 10:54:07.015   [250]   Worker_108:    Razorfishsl_stratum_DGM accepted share 98746db7 (difficulty 3.67269)
2013-05-02 10:54:09.006   [350]   Worker_104:    Found share: Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e000000003dbaf8e de3b2f661db9796ced5ec3cae20d12b3f94e46c9a657d49b60551dd965181d5151a01aa3d:b978a7d4
2013-05-02 10:54:09.470   [250]   Worker_104:    Razorfishsl_stratum_DGM accepted share b978a7d4 (difficulty 6.70452)
2013-05-02 10:54:10.994   [200]   Worker_107:    Exhausted keyspace!
2013-05-02 10:54:13.551   [200]   Worker_104:    Exhausted keyspace!
2013-05-02 10:54:14.163   [200]   Worker_108:    Exhausted keyspace!
2013-05-02 10:54:16.521   [200]   Worker_106:    Exhausted keyspace!
2013-05-02 10:54:25.298   [200]   Worker_101:    Exhausted keyspace!
2013-05-02 10:54:27.653   [200]   Razorfishsl_stratum_DGM:    Stratum connection died: Traceback (most recent call last):

Quote

013-05-02 10:54:29.793   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:54:30.090   [400]   Razorfishsl_stratum_DGM:    Successfully authorized Stratum worker razorfishsl
2013-05-02 10:54:30.105   [200]   Razorfishsl_stratum_DGM:    Received unexpected Stratum response: {u'id': 10000, u'method': u'client.get_version'}
2013-05-02 10:54:30.106   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.106   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.585   [400]   Razorfishsl_stratum_DGM:    Successfully subscribed to Stratum service
2013-05-02 10:54:30.603   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:54:37.838   [200]   Worker_107:    Exhausted keyspace!
2013-05-02 10:54:40.395   [200]   Worker_104:    Exhausted keyspace!
2013-05-02 10:54:41.007   [200]   Worker_108:    Exhausted keyspace!
2013-05-02 10:54:47.200   [200]   Worker_106:    Exhausted keyspace!
2013-05-02 10:54:52.993   [200]   Worker_102:    Exhausted keyspace!
2013-05-02 10:54:55.869   [200]   Worker_103:    Exhausted keyspace!
2013-05-02 10:55:00.122   [400]   Worker_106:    Mining Razorfishsl_stratum_DGM:00000002a17e1045791e442eaa009f8deea1e67f6c8a4bf850c32cc60000018e00000000096c1c9 7cfa4008c3f7d17e5b37f635013a38577af7393a8683542abcb39f70c5181d5811a01aa3d
2013-05-02 10:55:01.090   [200]   Worker_101:    Exhausted keyspace!
2

and so on.......

and yet the non DMG strat is fine with no dropout:

Quote

2013-05-02 10:38:18.494   [400]   W1:    Mining Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d
2013-05-02 10:38:21.889   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:a82f4d22
2013-05-02 10:38:22.347   [250]   W1:    Razorfishsl_stratum accepted share a82f4d22 (difficulty 1.22497)
2013-05-02 10:38:29.267   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:bd6ffe6c
2013-05-02 10:38:29.726   [250]   W1:    Razorfishsl_stratum accepted share bd6ffe6c (difficulty 4.75615)
2013-05-02 10:38:36.869   [350]   W1:    Found share: Razorfishsl_stratum:0000000251a32bfab86ac0c766db8f910005de035934d48fc99a9dfa0000007400000000c75e309 013d9096e61d369916fd52dba970f6c238cc6f3bd3c941e384296877d5181d17e1a01aa3d:bad706ba
2013-05-02 10:38:37.317   [400

zapeta

full member

Activity: 180

Merit: 100

Quote from: roy7 on May 01, 2013, 07:29:23 PM

I'm not sure what DGM settings you are using, but if you want to offer a PPS style system you could go with f=-1 (and whatever c and o are supposed to be for that, I think Meni provides an example) which still pays people per share and out of your pocket on a long round once a block is found, but a lot less variance and operator risk.

This might be viable if you can figure out the settings, but I don't think you should take on any sort of risks to your financial health to operate a pool. You definitely shouldn't agree to fund some huge buffer out of pocket just because some people want to whine about a payout scheme that isn't going to bankrupt you.

roy7

sr. member

Activity: 434

Merit: 250

Quote from: doublec on May 01, 2013, 06:10:08 PM

Quote from: firefop on May 01, 2013, 02:46:48 PM

Guess I'm mining at backup pools until the pps side comes back. Always sad when a good pool can't stick to an easy to understand payment system.

If you can provide the funds for the reserve I'll switch it on now.

I'm not sure what DGM settings you are using, but if you want to offer a PPS style system you could go with f=-1 (and whatever c and o are supposed to be for that, I think Meni provides an example) which still pays people per share and out of your pocket on a long round once a block is found, but a lot less variance and operator risk.

firefop

sr. member

Activity: 420

Merit: 250

Quote from: doublec on May 01, 2013, 06:42:32 PM

I've thought of a few possibilities to bring some form of PPS back without needing large reserves. One approach might be to split the 25 BTC reward so that 5BTC is distributed via PPS and 20 BTC via DGM (or whatever split). A single share gets a PPS payment computed from the value of the 5 BTC and a DGM share at the value of the 20 BTC. At 5 BTC provided for PPS and a 5% fee the pool would need a 230 BTC reserve to cover that with a 1 in 100 risk of ruin. This provides at least some regular, no need to wait for a block, type of earning with a chunk that becomes available when a block is found via DGM. The split could be adjusted based on reserves the pool has. What are the thoughts of something like this?

Please don't take this the wrong way doublec, I'm not trying to be mean or sarcastic here or anything, and do love the simplicity and elegance of your pool's website (which is the primary reason I've stuck around even when the pool has had issues or lower pps rate than other pools). But...

In traditional businesses most keep at least 3 months and 12 months of funding sitting around ready to be used... when a business struggles and has to go into credit to make payroll that's a sure sign that it's being mis-managed.

That being said:

I assume that you started out with some reserve to cover the pps payouts - and that over time that reserve has become depleted (either through growth or bad luck re:block generation). I also assume that you've been making some sort of income off the pool (otherwise why would you desire to continue at all). If both of those are correct then it comes down to mismanagement on the business side of things. Either through not taking enough control over the amount of hashing allowed at your pool (so you could keep smaller reserves) or through profit taking rather than building up your reserve as the pool hash-rate grew.

I am very sympathetic to either of these situations, it is a challenge that every business manager runs into sooner or later. The traditional ways of dealing with it are either taking a loan out to cover the operating costs needed (if you have faith in the process changes you'll make to fix it) or going out of business.

and while ~3000 btc would at current market value be a huge loan - I would consider funding your reserves. But of course, I'd have to be getting something in exchange, as well as being made aware on the entire process and how much income you're actually making or have made from the pool. If you aren't willing to disclose this information I have a couple of other ideas that we could go over on how to build up your reserve quickly (with the consent of your miners) in a fair way that I suspect most of them would be enthusiastic about.

But if the situation is different than I've described above, there's no point to you operating at a loss - just leave it as DGM and tell me to get lost.

roy7

sr. member

Activity: 434

Merit: 250

Even with a split, given a long enough period of bad luck you'll run into unlimited negative expense for the PPS payments won't you? I'm not one of your miners and I know people like the simplicity and reliability of PPS. But my advice is to stick to payment models that don't put the operator at risk.

doublec

legendary

Activity: 1078

Merit: 1005

I've thought of a few possibilities to bring some form of PPS back without needing large reserves. One approach might be to split the 25 BTC reward so that 5BTC is distributed via PPS and 20 BTC via DGM (or whatever split). A single share gets a PPS payment computed from the value of the 5 BTC and a DGM share at the value of the 20 BTC. At 5 BTC provided for PPS and a 5% fee the pool would need a 230 BTC reserve to cover that with a 1 in 100 risk of ruin. This provides at least some regular, no need to wait for a block, type of earning with a chunk that becomes available when a block is found via DGM. The split could be adjusted based on reserves the pool has. What are the thoughts of something like this?

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: firefop on May 01, 2013, 02:46:48 PM

Guess I'm mining at backup pools until the pps side comes back. Always sad when a good pool can't stick to an easy to understand payment system.

If you can provide the funds for the reserve I'll switch it on now.

doublec

legendary

Activity: 1078

Merit: 1005

Quote from: Reckman on May 01, 2013, 11:54:45 AM

Can you explain the prolonged low luck? Over a period between Jan 17 to May 1, blockchain.com shows pool luck at 60 percent. Statistically this just doesn't seem likely.

blockchain.info doesn't pick up all the blocks. You're better off using blockorigin. There's also the stats.csv which is the block file I provide for the weekly pools thread.

The pool has had a bad run of luck, especially in the last two weeks. This is a major reason for providing DGM. I don't have the funds to keep a reserve of PPS going through the bad luck period. It does vary a a lot though. The last difficulty period I think I was about 1.4x difficulty overall. The period before that I was about 0.9x difficulty.

Ascholten

full member

Activity: 155

Merit: 100

You know.... Im beginning to detect a pattern of randomness here Huh

Aaron

roy7

sr. member

Activity: 434

Merit: 250

The easiest thing to understand about PPS is "pool will eventually go bankrupt".

firefop

sr. member

Activity: 420

Merit: 250

Guess I'm mining at backup pools until the pps side comes back. Always sad when a good pool can't stick to an easy to understand payment system.

roy7

sr. member

Activity: 434

Merit: 250

Randomness is random.

gr0bi42

full member

Activity: 158

Merit: 100

Quote from: Reckman on May 01, 2013, 11:54:45 AM

Can you explain the prolonged low luck? Over a period between Jan 17 to May 1, blockchain.com shows pool luck at 60 percent. Statistically this just doesn't seem likely.

It doesn't matter. It was a pure PPS pool (before the DGM switch), hence withholding blocks doesn't affect you earnings. Now with DGM of course it would be an issue.

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