thx for your feedback, we have run test miners overnight and did not experience the issue at all. Can you please post the console output of your miner when the waiting for work package message appeared?
Ok, it looks like this is indeed a bug in qtMiner that is triggered if two consecutive work packages arrive in a very short time frame. This is caused by the new "pool-free" mining feature which causes work packages to be sent in the same speed that new blocks arrive which can be very fast (e.g. within a few ms). Previously new work packages were distributed at most every 200ms. We have checked the json messages send by the server and they are well formatted and complete.
Till qtMiner gets updated we have disabled the "poll-free" mining feature for now.
Curiously, when mining on ethermine, is there a warm up period before you start making what you should for your submitted shares? Like you have to be on the pool for two hours before you earn your optimal income rate.
Still occuring as of 5 minutes ago on US2, relevant console output:
i 16:41:58|main Work package received i 16:41:58|main Got work package: i 16:41:58|main Header-hash: 5907dc95fe80e6d4d8a70245d96d531159d4c31036b407ff17d88178cb6b5fac i 16:41:58|main Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 i 16:41:58|main Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:41:58|gpuminer0 workLoop 1 #1730dd81… #1730dd81… i 16:41:58|gpuminer1 workLoop 1 #1730dd81… #1730dd81… i 16:41:58|gpuminer2 workLoop 1 #1730dd81… #1730dd81… i 16:41:59|gpuminer3 workLoop 1 #1730dd81… #1730dd81… i 16:41:59|main Mining on PoWhash #5907dc95… : 72895657 H/s = 13631488 hashes / 0.187 s i 16:41:59|main Push: New work package received i 16:41:59|main Got work package: i 16:41:59|main Header-hash: 4db85025bf236f22cc656ba0a351d74f3e6af4592e58cb1c5674454ae54b3867 i 16:41:59|main Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 i 16:41:59|main Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:41:59|gpuminer0 workLoop 1 #1730dd81… #1730dd81… i 16:41:59|gpuminer1 workLoop 1 #1730dd81… #1730dd81… i 16:41:59|gpuminer2 workLoop 1 #1730dd81… #1730dd81… i 16:42:00|gpuminer3 workLoop 1 #1730dd81… #1730dd81… i 16:42:01|main Mining on PoWhash #4db85025… : 82558337 H/s = 101711872 hashes / 1.232 s i 16:42:03|main Mining on PoWhash #4db85025… : 83385765 H/s = 167772160 hashes / 2.012 s i 16:42:05|main Mining on PoWhash #4db85025… : 83385765 H/s = 167772160 hashes / 2.012 s i 16:42:07|main Mining on PoWhash #4db85025… : 83385765 H/s = 167772160 hashes / 2.012 s i 16:42:09|main Mining on PoWhash #4db85025… : 83906926 H/s = 168820736 hashes / 2.012 s i 16:42:11|main Mining on PoWhash #4db85025… : 83385765 H/s = 167772160 hashes / 2.012 s i 16:42:13|main Mining on PoWhash #4db85025… : 82864604 H/s = 166723584 hashes / 2.012 s i 16:42:15|main Mining on PoWhash #4db85025… : 83385765 H/s = 167772160 hashes / 2.012 s i 16:42:16|gpuminer1 Solution found; Submitting ... i 16:42:16|gpuminer1 Nonce: 31cd89c552c020d2 i 16:42:16|gpuminer1 Mixhash: 86835134eaca1a910a195c0b69fecaf8cd3fa1a595af3ad2988ab40295b7244d
i 16:42:16|gpuminer1 Header-hash: 4db85025bf236f22cc656ba0a351d74f3e6af4592e58cb1c5674454ae54b 3867 i 16:42:16|gpuminer1 Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf787544020321 5 i 16:42:16|gpuminer1 Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:42:16|gpuminer1 Ethash: 0000000001603d0c79c7d90547dacedcd1c1f3c5a5b2e91c6a86f19aa4b7b849 i 16:42:16|main Share submitted to server! i 16:42:17|main Work package received i 16:42:17|main Got work package: i 16:42:17|main Header-hash: 4db85025bf236f22cc656ba0a351d74f3e6af4592e58cb1c5674454ae54b3867 i 16:42:17|main Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 i 16:42:17|main Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:42:17|gpuminer0 workLoop 1 #1730dd81… #1730dd81… i 16:42:17|gpuminer1 workLoop 1 #1730dd81… #1730dd81… i 16:42:17|gpuminer2 workLoop 1 #1730dd81… #1730dd81… i 16:42:17|gpuminer3 workLoop 1 #1730dd81… #1730dd81… i 16:42:17|main Mining on PoWhash #4db85025… : 0 H/s = 0 hashes / 0 s i 16:42:17|main Pinging server... i 16:42:17|main Work package received i 16:42:19|main Mining on PoWhash #4db85025… : 80088505 H/s = 158334976 hashes / 1.977 s i 16:42:21|main Push: New work package received i 16:42:21|main Got work package: i 16:42:21|main Header-hash: 1b2f9bdf391a7ec9c4749238a288f8bdb475e5b7ee21686b1a41e60fe7aebfc6 i 16:42:21|main Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 i 16:42:21|main Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:42:21|gpuminer0 workLoop 1 #1730dd81… #1730dd81… i 16:42:21|gpuminer1 workLoop 1 #1730dd81… #1730dd81… i 16:42:21|gpuminer2 workLoop 1 #1730dd81… #1730dd81… i 16:42:21|gpuminer3 workLoop 1 #1730dd81… #1730dd81… i 16:42:21|main Mining on PoWhash #1b2f9bdf… : 82388114 H/s = 11534336 hashes / 0.14 s i 16:42:23|main Mining on PoWhash #1b2f9bdf… : 81903697 H/s = 164626432 hashes / 2.01 s i 16:42:29|main Push: New work package received i 16:42:29|main Grabbing DAG for #00000000… i 16:42:29|main Got work package: i 16:42:29|main Header-hash: 0000000000000000000000000000000000000000000000000000000000000000 i 16:42:29|main Seedhash: 0000000000000000000000000000000000000000000000000000000000000000 i 16:42:29|main Target: 0000000000000000000000000000000000000000000000000000000000000000 i 16:42:31|main Waiting for work package... i 16:42:33|main Waiting for work package... i 16:42:35|main Waiting for work package... i 16:42:37|main Waiting for work package... i 16:42:39|main Waiting for work package... i 16:42:41|main Waiting for work package... i 16:42:43|main Waiting for work package... i 16:42:45|main Waiting for work package... i 16:42:47|main Waiting for work package... i 16:42:47|main Pinging server... i 16:42:47|main Work package received i 16:42:47|main Grabbing DAG for #1730dd81… i 16:42:47|main Got work package: i 16:42:47|main Header-hash: ba183a145c825f0b3c27d58389d1b89e5663563ee4cba6770f7a6c3ab2dbb104 i 16:42:47|main Seedhash: 1730dd810f27fdefcac730fcab75814b7286002ecf541af5cdf7875440203215 i 16:42:47|main Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba i 16:42:47|gpuminer0 workLoop 1 #1730dd81… #1730dd81… i 16:42:47|gpuminer1 workLoop 1 #1730dd81… #1730dd81… i 16:42:47|gpuminer2 workLoop 1 #1730dd81… #1730dd81… i 16:42:47|gpuminer3 workLoop 1 #1730dd81… #1730dd81… i 16:42:49|main Mining on PoWhash #ba183a14… : 80846729 H/s = 139460608 hashes / 1.725 s i 16:42:51|main Mining on PoWhash #ba183a14… : 83468736 H/s = 167772160 hashes / 2.01 s i 16:42:53|main Mining on PoWhash #ba183a14… : 83261617 H/s = 167772160 hashes / 2.015 s
@dr_pra is it possible that disabling the "poll-free" feature resulted in slight miner underperformance using qtminer? I see a small decrease in 24hr averages between yesterday and today. Will have to check for longer to see if the trend stays. perhaps, it was a feature that significantly affected smaller % of individual rigs, yet overall it was a positive one for rigs that were not affected somehow.
I've been mining on ethpool for 5 weeks now, and I'm very happy with it. I occurred to me today that, when I first started on the pool (from solo), the pool hash rate was 1/3 what it is today. That's 300% growth in 5 weeks! I guess @dr_pra must be doing something right!
I am generally happy with this pool too, but it has some quirks that look strange at the first glance, but probably can be explained. Example; at ~1pm my miners reached the top, which then was at 24.3-24.4, sit there for good three-four minutes, got displaced and proceeded to drop and come back and get a block 1.5 hr later. I was watching the first 10 min and noticed that credits needed somehow went from 24.4 to 26.4 in the matter of minutes. This is a 10% increase in a few minutes. What could possibly cause this? Now credits went back down to 25.4 Question: if my miner was on the top (and even displaced afterwards), why it had to wait full 1.5 hr, which is basically 5% of total time to reach a block for me. In other words, because i did not get a block in 3-4 min when my miner was on top, it was essentially penalized 5% of hashing and had to accumulate 5% more hash. This seems excessive. This basically made me think to switch to ethermine after another round, unless there is a reasonable explanation.
@Biodom You just fell victim to pool bad luck. The same would apply if you were mining solo, too. The same would also appy if you were mining on ethmine in the form of a lower payment for that period of time.
The thing people need to come to grips with, is that it's all about your hashrate--regardless of where you mine--whether that be solo, ethpool, ethermine, Dwarfpool, etc.
While they all have slightly different payment schemes, they are all ultimately based off the amount of work you do over a given period of time, and in the end, it will all average out right where it should be given your hashrate.
Yeah, i agree with average and the hashrate part, but what could cause amount of needed credits increase 10% in the matter of minutes? Luck of the whole pool?
@Biodom One or more miners with significant hash rate got in front of you and stay there for some extended time, driving up the top credits needed, meanwhile everyone in back sat there and hashed. It's caused by extended times without the pool getting a block, causing a "traffic jam" of higher hashers at the top. By the time those higher hashers get taken out of the picture, because the pool gets a rash of blocks, everyone else has already run their credits up well beyond what would normally be required. The uncle policy also contributes to this. For example, I saw a miner today get an uncle and wait another *12 minutes* to get his full block. That's just the way it goes. I have a pretty decent hash rate, and I still experience the same thing you are referring too. There is always some hasher faster than you, unless you're the top dog.
Just got a 9.3Eth block. Realized why this happens too - if ethpool includes it's own uncle in a block, they get paid together to the person with top credits. Bit different then when someone else includes an ethpool block as an uncle.
@dlehenky you just revealed the pro-tip for ethpool - as soon as you hit top credits, you mine elsewhere (or to another address) and wait for payout before switching back. Might take a bit longer because larger miners may get in front of you, but eventually you'll get the payout.
@dlehenky thanks, yes, i got the principle of it, but this 'stuck' on seems to be most detrimental to those in the top 10-20 positions while having no affect on those who are still below, say 20 credits or even lower. Once i also got an uncle while being 'on top', then dropped down and got a block 40 min later, which is fine, of course. I guess my point is that i honestly don't see why i had to wait 1.5 hr (or 5% of 'extra' time) to come back to top since I was there initially. Psychologically, if i was on top already, it is difficult to accept that suddenly I have to work 1.5 hr more "for nothing" to get to the same place.
As i said, this probably averages out over longer term, but it was not pretty in this particular instance. if i get no uncle next time, and I probably won't, i will be switching to ethermine.
@work i don't think so. If you hit top credit, then switch your miner over, you will most likely NEVER get paid as your credit will be constantly passed by others.
@Biodom Actually, I saw a miner with 0 current hash rate get a block the other day. The pool mined enough blocks in a short period of time that the top credits needed for a block came down to where this miner was at. What you are talking about, above, is the inverse of this.
@work i don't think so. If you hit top credit, then switch your miner over, you will most likely NEVER get paid as your credit will be constantly passed by others.
Trust me... it works. There are at least a few people doing this. You'll get passed in credits, maybe; but eventually the pool will have a lucky streak of blocks and you'll get paid.
@work well, if the system is gameable, i don't really want to use it because i don't know the rules of such game yet. sometimes ethpool looks particularly interesting, as if some AI is driving/optimizing it, even on the level of pool/miner interaction. People tend to see patterns where there are none, but some patterns do look weird to my eye. I want something straightforward and ethermine looks more like it. @dlehenky yes, you are right, it is an exact mirror, now I get this
@Biodom I wouldn't say it's "gameable" per se. It's due to the fact that ethpool always saves your current credits. You can stop mining there at any time, go off somewhere else for a week, and when you come back you'll still have the credits you had when you left. The miner that reaches the top, or nearly, and then moves to another pool, *earned* the credits he has at that point, so if he gets a block, it seems only fair, don't you think? I not trying to dissuade you from moving to ethermine; it's the right pool for a lot of miners.
@dlehenky yes, sure. However, reading what yourself and @work had said, I already possibly derived one likely "game" rule that i will check next time. It might be interesting to try some 'active' strategies just for fun.
Since dr_pra put in the recommended "uncle" patch (as a result of Homestead), the uncle rates seems to have come down some, which is a good thing, of course.
@o0ragman0o Well, next to solo, which has a lot of stress factor for me, ethpool is the best pool I've found, at least for my rigs. I can certainly see why smaller miners would prefer using ethermine, though, especially as the network difficulty continues to climb. Man, these last couple of days have been brutal!
@dlehenky Naturally, you're in a position to be at an advantage on ethpool. Regardless of any bias, I personally prefer something a bit more statistically pure like ethminer (but not so puritanical as solo
Comments
Heard-hash: 00000000...0
Seedhash: 00000000...0
Target:00000000...0
I moved yesterday to ethproxy and cant provide log. But if you copy your cmd output to notepad and search for "0000000000000" you will find it.
Did you test in windows?
Till qtMiner gets updated we have disabled the "poll-free" mining feature for now.
Still occuring as of 5 minutes ago on US2, relevant console output:
is it possible that disabling the "poll-free" feature resulted in slight miner underperformance using qtminer?
I see a small decrease in 24hr averages between yesterday and today. Will have to check for longer to see if the trend stays.
perhaps, it was a feature that significantly affected smaller % of individual rigs, yet overall it was a positive one for rigs that were not affected somehow.
Example; at ~1pm my miners reached the top, which then was at 24.3-24.4, sit there for good three-four minutes, got displaced and proceeded to drop and come back and get a block 1.5 hr later.
I was watching the first 10 min and noticed that credits needed somehow went from 24.4 to 26.4 in the matter of minutes. This is a 10% increase in a few minutes. What could possibly cause this?
Now credits went back down to 25.4
Question: if my miner was on the top (and even displaced afterwards), why it had to wait full 1.5 hr, which is basically 5% of total time to reach a block for me. In other words, because i did not get a block in 3-4 min when my miner was on top, it was essentially penalized 5% of hashing and had to accumulate 5% more hash. This seems excessive.
This basically made me think to switch to ethermine after another round, unless there is a reasonable explanation.
The thing people need to come to grips with, is that it's all about your hashrate--regardless of where you mine--whether that be solo, ethpool, ethermine, Dwarfpool, etc.
While they all have slightly different payment schemes, they are all ultimately based off the amount of work you do over a given period of time, and in the end, it will all average out right where it should be given your hashrate.
Yeah, i agree with average and the hashrate part, but what could cause amount of needed credits increase 10% in the matter of minutes? Luck of the whole pool?
@dlehenky you just revealed the pro-tip for ethpool - as soon as you hit top credits, you mine elsewhere (or to another address) and wait for payout before switching back. Might take a bit longer because larger miners may get in front of you, but eventually you'll get the payout.
thanks, yes, i got the principle of it, but this 'stuck' on seems to be most detrimental to those in the top 10-20 positions while having no affect on those who are still below, say 20 credits or even lower.
Once i also got an uncle while being 'on top', then dropped down and got a block 40 min later, which is fine, of course.
I guess my point is that i honestly don't see why i had to wait 1.5 hr (or 5% of 'extra' time) to come back to top since I was there initially. Psychologically, if i was on top already, it is difficult to accept that suddenly I have to work 1.5 hr more "for nothing" to get to the same place.
As i said, this probably averages out over longer term, but it was not pretty in this particular instance.
if i get no uncle next time, and I probably won't, i will be switching to ethermine.
i don't think so. If you hit top credit, then switch your miner over, you will most likely NEVER get paid as your credit will be constantly passed by others.
well, if the system is gameable, i don't really want to use it because i don't know the rules of such game yet.
sometimes ethpool looks particularly interesting, as if some AI is driving/optimizing it, even on the level of pool/miner interaction.
People tend to see patterns where there are none, but some patterns do look weird to my eye.
I want something straightforward and ethermine looks more like it.
@dlehenky
yes, you are right, it is an exact mirror, now I get this
yes, sure. However, reading what yourself and @work had said, I already possibly derived one likely "game" rule that i will check next time. It might be interesting to try some 'active' strategies just for fun.