You don’t know why 4 of my shares are rejected every hour on every miner and not recorded by your system? I had 0% rejected by nanopool, but they had so many problems I’m trying to switch.
As you can see in the error message the share was stale, meaning for an old block. We cannot accept stale shares as they cannot be used to create a valid block. According to the stratum protocol miners should not submit stale shares back to the pool. As it can be seen in the log your miner received a new job shortly before it submitted the stale share. We do not record them in our interface at the moment as some miners tend to get stuck on stale jobs and keep flooding the pool with them.
@peter_zcash My ticket is still not resolved; I send all details requested. Can you please resolve it!
My latency to your servers is 45 ms, twice as fast as nanopool who did not hardly ever reject a share. You’re sending jobs nearly twice as fast, averaging 16 seconds between them. 0.045 x 2 / 16 = 0.5% accidental rejection which is a lot slower than the 2% to 8% I’m seeing. Either your system or my system is causing nearly a 1 second delay. Since I do not see anyone else making this complaint, I assume my internal network is slow AND nanopool was just not notifying my miners that shares were being rejected. I do have some delays on my browser if I don’t use the IP number, so I’m using your IP number instead of DNS. So there’s reason to believe the problem is on my end, but strange it does not show on nanopool. Otherwise, the fix is on your end.
291be1d8bd019869392e97a9346739f2e3150abf2c0e2f305c3471524d1b1880 transaction not found. What happened?
Refresh that in a few minutes. I’ve seen it happen a few times if I click on the TX before its fully broadcasted.
I changed routers and put my browser on a wired connection. My slow browser problem is solved (it was a wireless problem while the miners are wired). I’m getting 40 ms pings to flypool. Flypool is still calling 3 shares per miner per hour “stale” (and not showing any stale shares on their website) and calling my 700 S/s 630 S/s.
Someone, anyone, please give me an idea of how this might be a problem with my network or miners and not definitely a problem with Fypool.
Please post if you see any stale (red) shares in the past 3 hours on any of your miners. I think 1 stale share every 5 hours is about right.
2 of my rigs
35546 Accepted 186 Rejected (160H/s)
28096 Accepted 446 Rejected (110H/s)
Both running 24hrs+
Do NOT use the ip address. We rely on DNS for our failover system. If you connect using the pure IP and the server goes down you will not be redirected automatically to our backup server. Also if we migrate to a new server for whatever reason you will also not be migrated automatically.
I don’t know how nanopool handles stale shares and if they report them at all. Again, the issue is with the mining software, you can clearly see in the logs that your miner submits a old share after having received a new job. Miners should not submit stale shares back to the pool at all.
Now I see. nheqminer xenoncat for CPUs has a problem
Peter,
Are there any plans to have a night mode or update the color scheme to look more like ethermine.org?
Better would be if Peter will implement 24 h real earnings and estimated earnings graph. Dwarfpool have this table. And you can see how much you have earned in 24 h period. Nanopool have estimated earnings table. Just things that make your life easier. And much easier to calculate exact earnings.
1 Like
How do I a payout? I validated my IP address and still nothing.
I don’t know if there is a problem with flypool or if it is on my side.
I have been monitoring my hash rate and i have a constant output of about 83/84 sol but on the flypool site it shows 79 or at least about 2 or 3 sol lower then i am mining.
Is that a problem on my side and if how can i solve it?
I have one miner showing 102h/s while it’s over 140H/s … The rest show close to my real hashrate.
so the question is, is this only a display problem or is the hash rate recorded lower then the actual hash rate?
Stale shares happen to everyone, whether they realize it or not. I have 120 GPUs and everyone of them produces a stale share now and then (on ethereum, too). This is all about timing. What is happening on the pool server is independent of what your miner is doing. You find a solution and submit it, but during that time, a new block has already arrived or just been sent, your submitted share is stale, that’s just the way it works. You’re not doing anything wrong, the pool isn’t doing anything wrong, it just life in the client-server world. Did it occur to you that you don’t see them on nanopool simply because they don’t report them to you?
i haven’t seen any stale shares on the output i am getting
but meanwhile i think it is just a display issue as i had the miner show 79 sol and the flypool site show 84
He explained that he knew it was miner software because a share was being submitted immediately after a new job was given (in the same second). It could not have a solution that quick, so it must have been submitting a share for the previous job. The new job is supposed to stop work on the old job and no share for it is supposed to be submitted. So it looks like the miner is being triggered to submit a share it had solved, like it was holding it in memory, but it’s too late. More likely, the share is just no good.
I created a github issue for nheqminer to nicehash for the xenoncat CPU v3.
I just ran it in debug mode. Sure enough, it acknowledges a new job is recvieved but it does not stop working on the old one and takes 1/2 a second to say “load new job”
I wonder if flypool could make the jobs harder so they are not changed so often.
Peter did mention earlier (above) that the pool will be increasing the static diff, although he didn’t say when. It certainly could be the CPU miner software.