Shouldn’t long tail cancellation take care of slow performance?
And we also know customer experience can differ depending on the location. Audits are just one location out of many possible locations where customers download from.
From the 75% overall download success rate I would say the node serves customers well enough on the majority of downloads otherwise the transfers would get long tail canceled.
AFAIK you cannot limit download requests.
I have seen slow storage on many different situations. Starting from massive up- and downloads, endless filewalkers of different kinds, slow devices, copy and transfer actions, Raid rebuild and many other. Storj should take into account that it does not necessarily have exclusive access to the storage so there also reasons outside of its scope but on which it depends on.
It is interesting that we can have minutes for read and write checks but can get disqualified when for example a Raid a node is running on gets rebuilt or a node gets moved to another location. This does not align well for me. For me audits are for proving that the data is correct not how fast they get delivered despite the readability checks in place.
BTW:
In the past you have made clear the link between these settings and the audit timeouts:
You may increase a timeout, but please be careful - do not put more than 5 minutes, otherwise you will risk to start to fail audits.