4ADA2 and 4ADA3 blocks were produced flawlessly. We made some changes to increase the number of connections in the network, in order to increase our chances of winning slot and fork battles, however for 4ADA we unfortunately ran a few hours with a configuration error, which made us lose half the blocks during that period. Our tuning efforts do seem to pay off, as we already notice improved, tighter tracking of our pools.
For epoch 77 we were assigned a nice quantity for 4ADA, however for both 4ADA2 and 4ADA3 it is absolutely disappointing to see we are not getting enough blocks day after day.
This is indeed extremely frustrating, as it totally defies all of our efforts to deliver a great performance. Even up to the point where we seriously question the quality of the Ouroboros protocol. It is simply impossible for 4ADA3 to get assigned only 11 blocks during a 4 epoch period, where we actually should have gotten at least 17!!! Simply rediculous and in our opinion not justifiable by simply pointing at the randomness and long term statistical balancing capability of the protocal…
Keep up the great work! I know i SUPER appreciate everything your doing and the daily updates.
Stake strong 🙂
Agreed Mac!!!! Your updates and candid assessment of the situation is appreciated.
Maybe a 4 epoch period is too short to rate the quality of Oroborous?
You are probably right. Problem is that many delegators are even more impatient than I am. If they don’t see great results within a few days, they move on… This is why I think the degree of randomness should be proportionate to pool size. For small pools the impact of coincidence is currently far greater than the actual pool performance (successfully completing all block tasks assigned).
But ok, you got me, I will try to be more patient 🙂
The good news is that people who have been switching state pools are getting the idea that you need a little time. If you switch quickly you don’t gain the benefit of a great pool