# Tuning audit scoring **URL:** \ **Category:** Storage Node feature requests - voting\ **Created:** [May 31, 2021, 7:27pm UTC](https://forum.storj.io/t/tuning-audit-scoring/14084 "2021-05-31T19:27:54Z")\ **Posts on this page:** 20\ **Page:** 4
**Author:** ![BrightSilence](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/brightsilence/32/6048_2.png) [@BrightSilence](https://forum.storj.io/u/BrightSilence)\ **Post date:** [February 14, 2022, 11:21am UTC](https://forum.storj.io/t/tuning-audit-scoring/14084/62 "2022-02-14T11:21:51Z")
> [@elek](#): > > not month, but eg. a week. Well month was just a suggestion, but I can elaborate a little bit on my thinking for that. Younger nodes without much data don’t get that many audits and if it also takes a few days to diagnose and fix the problem, there may not be enough audits / repairs to recover the score above the threshold, especially given that it drops a lot faster than it recovers. On the other hand, while the node is suspended the data is already protected, so there isn’t really a need to rush permanent DQ. So I figured a longer period would spare SNOs from losing their node in those situations and spare the support staff from having to deal with more tickets regarding disqualified nodes that will inevitably come. There’s a balance to be found here. > [@elek](#): > > The goal of _unkown score + suspend period_ is to avoid disqualification in case of any software error (which is not the fault of SNO). With this scheme, one can be unfairly disqualified if software error happens after a suspension period. (But we can argue that these cases should be rare and handled by support manually) I would say this is again a good reason to not use too short a period. It also give you time to fix things software wise if necessary, without permanent impact and the need to manually deal with loads of support tickets. This is also where data could prove valuable. How often do nodes spend more than 30 days in suspension? And those that do, do they ever tend to come back from it now? Because long suspension seems costly if you’re still paying them. And of course there is that elephant in the room, that doesn’t need to be repeated. But this could (and probably eventually will) include nodes that really SHOULD be disqualified despite returning unknown errors only for different reasons. > [@elek](#): > > There should be some motivation to avoid the suspension state. Either avoid using the suspended node for download (-egress payment) or fully stop the accounting during suspension period (-egress/storage/repair payment). All of those options sound reasonable to me. But from user reports here on the forum I can tell you that loss of ingress and data loss to repair is already acting as a good incentive for SNOs to want to get out of that state. Additionally the fear of permanently losing a node that built up reputation and data over time works as a very strong motivator as well. If I could pick I would prefer avoiding egress by excluding these nodes in node selection rather than letting egress happen but not paying for it. Seems a bit more fair and also eases load on nodes that may have gotten into trouble for too high a load to begin with. I think it’s also quite fair to not pay for storage for a node that has not been reliable. This would also perhaps help offset the additional repair cost this triggers on your end. It wouldn’t make much sense to pay for data storage when the node has shown to be unreliable and is actively causing repair costs on the network. ---
**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\ **Post date:** [February 14, 2022, 11:41am UTC](https://forum.storj.io/t/tuning-audit-scoring/14084/63 "2022-02-14T11:41:04Z")
What I was thinking of is a table of audit/repair/suspension/disqualification/becoming vetted events with the following fields: - timestamp (accuracy of 5 mins should be enough for this purpose), - some anonymized node identifier, - satellite, - event type: suspension, un-suspension, disqualification, audit/repair that counts as successful, audit/repair that counts as failed, audit/repair when node was offline, or node graduating to a vetted status. from some reasonable time window, maybe half a year would be enough? Plus some indication of node’s age/maturity if the node is older than the beginning of the selected time window. Though, probably even just successful/failed/offline audits from a single satellite for a subset of nodes would be enough for a basic analysis. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [February 26, 2022, 5:11am UTC](https://forum.storj.io/t/tuning-audit-scoring/14084/64 "2022-02-26T05:11:51Z")
> [@littleskunk](#): > > The timeout is still missing. Storage Nodes will get disqualified if the hard drive is just freezing. I had that situation on my system as well. The writability check will not notice it. The hard drive is still there. You can try to write a file on it. That operation will start but never finish and so the writability check starts but never fails. > > > \