Interestingly, this version 0.6-203@210403 does not appear in the list of available versions for downgrade - I downgraded to 0.6-203@210401 instead - but the problem doesn’t seem to have been solved.
how would one go about downgrading to a version that is not in the list and, thus, the downgrade cannot just be run with a click of a button?
Thanks!
Update the driver
My drivers were already the latest (465… If you meant “downgrade” the driver - I did now downgrade it to the latest “stable” version 460.80. But I’m still not seeing the version you mentioned in the list of OS versions available for downgrade. Still the same list.
Oh, I had a similar problem.
After updating to the latest version of hiveos, invalid share started to appear.
I updated the nvidia driver to version 465.31, and also tested the trex versions 0.20.3 and 0.20.4.
But there are still invalid shares.
At first I thought the problem was overclocking and I said change the overclock. But now I know the problem arises after updating hiveos.
I will now try the stable version 0.6-203@210403 and announce the result.
You can with the command
hive-replace -y --stable
Reduce to this version
I’m trying this as well, will report back.
its the eth 2.0 waiting to burst in July hahaha. i get those invalids as well.
But im not on nvidia. I have vega 64s. Would get 2-3 invalids per day. I just reset them every 10 days as those red circles are annoying to look at.
Yes, invalid shares still exist for me.
Now amd gpu have also started sending stale share!!!
Maybe the problem is because of the hiveon pool!
any idea?!
I checked the log file for miners, I noticed that when invalid share and stale share is sent, the ping reaches 15000ms!
In a case where my internet connection ping between 150ms and 200ms at other times.
It kinda sucks… So there is no solution to this at the moment? I’ve also downgraded to the “stable” version, will see how this goes. Keep getting invalids otherwise on most GPUs.
If this continues and downgrading doesn’t solve the issue, there is no point in keeping this version and I’m thinking of upgrading back up to the most recent versions of everything.
I changed the pool from hiveon to 2miners.
Now more than 1 hour and 100% share accepted.
I will wait a little longer and announce the result.
Of course, I do not know why after changing the pool, the total power consumption has increased by about 5 watts and the temperature of GPUs has risen slightly!
Alright, this is where reading patch notes is super important. Before the latest HiveOS update, there was a “bug” with T-Rex and HiveOS in which it wouldn’t show the red circle within the HiveOS page. This didn’t mean that you weren’t getting invalid or rejected shares, it just meant that HiveOS wasn’t showing them. The latest HiveOS patch “fixed” this bug and now T-Rex miner and HiveOS will properly show rejected/invalid shares.
You will never have 100% accepted rate, it just won’t happen. This is why looking at the farm efficiency is so important. Running for months on end, you should be around 99% efficiency. If you’re at that, you’re good.
You can login to your server and run the command “motd watch” without the quotes. This will show you what T-Rex miner is doing and the accepted/rejected share ratio of each card.
Again, there isn’t anything wrong with your cards and they didn’t “suddenly” become unstabble. HiveOS just started reporting them properly.
For reference…
Prior to this update, the problem was that it did not display invalid share with a red circle, but instead rejected share was displayed, which I knew was invalid that was not displayed correctly. I checked all the logs.
But now the problem is the hiveon pool.
As I posted in the screenshot, I had a lot of invalid shares with the hiveon pool.
But for about 6 hours now I have no invalid share or reject share and it is 100% Accept share.
I did not change anything else, neither overclock, nor nvidia driver, nor hiveos version
Everything is the same as my previous test and I just changed the pool from hiveon to 2miners.
Eventually you will start to get invalid/rejected shares, it’s part of mining. You have to feel comfortable with your farm efficiency and then just leave it at that. There are too many variables and there are things that you just can’t prevent. You can submit a share to a block that has already been solved. This isn’t ineffciency on the card, it’s just bad timing. If you keep resetting the miner for a few bad shares your’re going to have a bad time.
Hopping from one pool to another is also inefficient. The payout plans are designed to discourage pool hopping.
In the previous screencap your farm efficiency was at 99.76%. That was a really good ratio.
Here’s a screencap from a random miner on the ethermine pool. They have 2% rejection.
Gringochuck,
In your screenshot there are 0 invalid shares. Stale shares are not the same as invalid. On one hand, you’re saying that invalid shares are inevitable, on the other you post a screenshot of 146 workers without a single invalid share. If invalid shares are natural, then how did this person manage to not get a single one at 19GH/s?
This is a random miner I just pulled from. It was to show you pool efficency. You’re correct, invalid and stale are not the same. So it was a bad example.
HiveOS will tell you your farm efficiency and will tell you if it’s good or not. You just have to be comfortable with the efficiency.
Yes I agree with you, invalid / stale share will definitely exist, but the ratio of their number to the number of Accept share is important.
In the previous test in 8 hours there was about 0.2% reject / invalid in hiveos, at the same time in the pool it was about 4%.
But now it is much more stable in the 2miners pool.
I’ve used hiveon in the past, and my stale share was usually less than 2%. But apparently there is a problem now and the hiveon pool is increasing the number of invalid / stale shares.
Surely you know that the return displayed in hiveos is not what is in the pool, because when a share is sent to the pool, it takes time to reach the pool, which is ping. At this time, hiveos displays that share as Accept, but in the same short period of a few milliseconds that it took to send the share to the pool, the other share may be stale, in which case the share in the pool is displayed as a stale share. Is given and displays the same share in hiveos Accept share.
But our problem is not stale share at all. The problem now is invalid share.
As you know, invalid shares is a share whose difficulty is less than the difficulty determined by the pool and that share becomes invalid. This is a hardware error.
I guess you do not understand some of my sentences, I apologize because English is not my language.
im very sorry
I have one card that is a pain in the ass. It seems regardless of my OC it just wants to have more invalid/rejects shares than any other card. It’s the Gigabyte card. I’ve just learned to live with it. I’m happy with the return I’m getting.
No worries. I understand what you’re saying. You don’t need to apolgize. The previous screencap was a bad example, again showing stale shares and not rejected. That was my fault and I apologize for that.
My whole point is that there are going to be invalid/rejected/stale shares regardless of the pool/hardware/OC. So as long as you’re comfortable with the stability of the pool and your card, then mine on.
I was also making a point to the main topic of the thread that these invalid/rejected shares just didn’t suddenly happen because of the most recent update. It’s that HiveOS started showing them properly on their display.
BTW, for English not being your primary language you speak/write it very well. I know that doesn’t have anything to do with the topic, but I alway feel like if someone is doing something well, you should let them know.
Is it possible for you to check the log miner file and see when the rejection share was created to see why?
Usually writes what the problem is.
The file is available at the following address
/var/log/miner/t-rex/t-rex.log
(You can also download it to the hiveos web page via ssh with the following command. 
)
message file "t-rex log" --file=/var/log/miner/t-rex/t-rex.log
