Changed RandomX and static difficulty requirements
Posted: Tue Oct 05, 2021 7:06 am
Last night, the system fell behind in inserting shares into the database. It was behind by 25 minutes at one point around 4:00am EDT on October 5, but the shares queued in memory until we were able to determine the cause of the issue, after which time they were all inserted.
The cause of the problem was that a small number of RandomX workers were submitting a large number of shares at the minimum static difficulty for RandomX (128.) These 1% of workers were responsible for half the system's shares over the past few days.
After some research, we determined that most modern hardware can mine at a difficulty higher than 128, so we increased the minimum difficulty to 256 for RandomX. We also changed the share frequency limit to 2 seconds, up from 0.8 seconds. These two changes reduced the number of shares being inserted by half.
No share corrections are necessary, as the share inserters functioned as designed and caught up once the incoming load fell.
The cause of the problem was that a small number of RandomX workers were submitting a large number of shares at the minimum static difficulty for RandomX (128.) These 1% of workers were responsible for half the system's shares over the past few days.
After some research, we determined that most modern hardware can mine at a difficulty higher than 128, so we increased the minimum difficulty to 256 for RandomX. We also changed the share frequency limit to 2 seconds, up from 0.8 seconds. These two changes reduced the number of shares being inserted by half.
No share corrections are necessary, as the share inserters functioned as designed and caught up once the incoming load fell.