Need help from S9 owner

UnknownEntity · Post by **UnknownEntity** » Sun Jul 22, 2018 1:02 pm

TeamViewer is set up and ready to go on my end ...

UnknownEntity · Post by **UnknownEntity** » Sun Jul 22, 2018 1:10 pm

i sent the login info via ticket... "Re: Need help from S9 owner"

Post by **Steve Sokolowski** » Mon Jul 23, 2018 8:55 am

Thanks to everyone who has been reading this thread. I've now received help from UnknownEntity, so everyone else can stop whatever setup they are doing.

I'll post here if there is any need for additional help. Thanks!

Post by **Steve Sokolowski** » Mon Jul 23, 2018 4:00 pm

I've completed my work on this issue for now.

I determined that the S9, apparently, states that it supports ASICBOOST but doesn't actually submit share version numbers for ASICBOOST. However, there are other miner types that are apparently compatible with ASICBOOST.

I know that some of these miners are connected to the system, because some of them are generating errors. I'm going to ask Chris to deploy a new version of the mining servers that will record the data these miners are sending, because previously they only recorded that there was an error. I'll continue the investigation once I have this data available.

UnknownEntity · Post by **UnknownEntity** » Mon Jul 23, 2018 4:47 pm

shame it did not work out as expected...
if you need access again hit me up. I will store the pi in a save place for quick access.

Post by **Steve Sokolowski** » Mon Jul 23, 2018 6:22 pm

UnknownEntity wrote:shame it did not work out as expected...
if you need access again hit me up. I will store the pi in a save place for quick access.

Thanks again for all your help!

ryguy · Post by **ryguy** » Tue Jul 24, 2018 12:33 pm

Steve it appears that a lot of shares are now being rejected from S9's due to version_bits. This is going to cause the mining efficiency of S9's (and possibly other devices) to suffer on this pool.

EDIT: It appears this was a problem with a specific miner. Sorry for the confusion.

ryguy · Post by **ryguy** » Thu Jul 26, 2018 3:57 am

Actually I'd like to correct my previous statement. Some S9 are still having all of their hashrate rejected because of "version_bits must be null because this session did not request a version-rolling.mask".

If it means anything it appears to always be a multiple of 10 shares which are being rejected with this error.

I was under the impression from your status update on the 19th that you had made a change to stop rejecting these shares as invalid. Is that no longer the case?

Post by **Steve Sokolowski** » Thu Jul 26, 2018 9:54 am

ryguy wrote:Actually I'd like to correct my previous statement. Some S9 are still having all of their hashrate rejected because of "version_bits must be null because this session did not request a version-rolling.mask".

If it means anything it appears to always be a multiple of 10 shares which are being rejected with this error.

I was under the impression from your status update on the 19th that you had made a change to stop rejecting these shares as invalid. Is that no longer the case?

I don't understand why these S9s are sending an extra unneeded parameter to the mining server, so I added debug code to print the version_bits that is being sent in the share rejection message.

Could you post what the version_bits are from 10 or 20 shares that were rejected in this way?

ryguy · Post by **ryguy** » Thu Jul 26, 2018 1:23 pm

It was a 2 followed by however many 0s would be appropriate in that message. If I see that message again, I'll update with the full rejection message as I moved the S9 off this pool since it wasn't getting any hashrate accepted.