# Показатель эффективности ноды **URL:** \ **Category:** Storage Node feature requests - voting\ **Tags:** на-русском\ **Created:** [July 19, 2024, 6:54pm UTC](https://forum.storj.io/t/topic/27190 "2024-07-19T18:54:46Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cav](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/cav/32/7823_2.png) [@cav](https://forum.storj.io/u/cav)\ **Post date:** [July 19, 2024, 6:54pm UTC](https://forum.storj.io/t/topic/27190/1 "2024-07-19T18:54:46Z")
Добрый день. извиняюсь за то что пишу предложение на русском языке, мне так проще излагать мысли. Во многих группах тематики Storj, Я частенько замечал вопросы связанные с тем, что одни ноды получают максимальный трафик, другие минимальный, и объяснению этому нету, но по факту под “капотом” каждый спутник использует свою систему ренжирования имеющихся у него в распоряжении нод. и это правильно, мы всегда оцениваем надежность партнера, я предлагаю чтобы данный показатель был публичный, и каждый спутник совместно с uptime ноды также отображала данный показатель. Динамика изменения данного показателя позволит владельцам нод, ориентируясь на этот показатель, улучшать свои ноды, Ведь вполне возможно что кто то держит у себя огромные ноды, но по показателям спутника, они не интересны для него, лучше сразу сказать об этом владельцу нод, чтобы он не тратил силы на расширение текущего состояния, а думал как можно изменить ситуацию, чтобы его ноды были более востребованы. но для этого нужны четкие и понятные показатели. ---
**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:** [July 20, 2024, 3:57am UTC](https://forum.storj.io/t/topic/27190/2 "2024-07-20T03:57:34Z")
Этот показатель называется “репутация” и состоит из трёх оценок, которые у вас всегда видны на dashboard: - audit score - suspension score - online score Локальная эффективность узла может быть грубо оценена с помощью скрипта > [@Success rate script - Now updated for new delete terminology since v1.29.3](https://forum.storj.io/t/topic/5114/81): > > The original successrate.ps1 script from @Alexey was having problems on my machine with high memory usage whilst running on larger log files. So I rewrote it slightly to read the log one line at a time, calculate all the variables as it goes and then print out at the end. It’s between 10% and 30% faster to run on my machine using an identical log file. param( $Path = "C:\Program Files\Storj\Storage Node\storagenode - Copy.log" ) $auditsSuccess=0 $auditsFailed=0 $auditsFailedCritical=0 $dl… Глобальная статистика, поддерживаемая Операторами в этом треде: > [@Successrate.sh comparison thread](https://forum.storj.io/t/successrate-sh-comparison-thread/1997): > > Hey SNOs slight_smile I know there are lot’s of threads where we talk about successrate.sh results and hardware but it’s comes up when issues are there - I would love to share outputs for comparison, not for hardware geeking… How do you feel about this format: Hardware: Synology DS1019+ (INTEL Celeron J3455, 1.5GHz, 8GB RAM) with 20.9 TB in total SHR Raid Bandwidth: Home ADSL with 40mbit/s down and 16mbit/s up Location: Amsterdam Node Version: v0.21.3 max-concurrent-requests: DEFAULT, s… Других оценок нет. Насколько я понимаю, вам бы хотелось ещё видеть какую-то статистику почему ваш узел был выбран или не был, однако она не статичная, меняется на каждый запрос, это просто огромный объём данных и абсолютно бесполезный сразу после публикации. Что влияет на выбор того или иного узла: 1. Узел должен быть онлайн 2. Репутация (см. выше). 3. Состояние проверки (новые узлы получают не более 1%-3% загрузок от клиентов). 4. Подсеть (для каждого кусочка сегмента выбирается один узел из подсети /24 публичных IP, чтобы не помещать кусочки одного сегмента в одно физическое место и/или того же ISP). Выбор случайный. 5. Динамическое вычисление success rate на спутнике (у вас оно уже есть, см. выше). Оно не статическое, раз в несколько минут пересчитывается. Позволяет не перегружать слабые узлы и в то же время выбирать быстрейшего для этого конкретного клиента. 6. Спутник выбирает по критериям выше 2х набор потенциальных узлов для каждого кусочка каждого сегмента и из них выбирает по одному узлу с наивысшими оценками для каждого кусочка каждого сегмента. В результате клиент получает список узлов для всех кусочков каждого сегмента, на которые он начинает загрузку параллельно. Как только минимально необходимое количество кусочков загружено, остальные загрузки отменяются. ---
**Author:** ![cav](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/cav/32/7823_2.png) [@cav](https://forum.storj.io/u/cav)\ **Post date:** [July 22, 2024, 4:07am UTC](https://forum.storj.io/t/topic/27190/3 "2024-07-22T04:07:56Z")
ну вот, как я вижу тут достаточно четко вырисовывается еще один из достаточно стабильных параметров, это наличие “соседей”, в пространств /24, а также сколько их, чтобы оценивать вероятность деления трафика? я где то видел запрос на получение этой информации, но так с ходу не вспомню. и на сколько я понял наличие двух и более узлов даже на одном адресе /32, в принципе это не особо страшно, если все они принадлежат одному хозяину, для спутника они все вместе будут иметь такой же вес как и если бы это была бы одна большая нода. а вот если узлы расположены в /24 и принадлежат разным хозяевам, то ту получится уже деление трафика между разным хозяевам. Я правильно понимаю? ---
**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:** [July 22, 2024, 6:23am UTC](https://forum.storj.io/t/topic/27190/4 "2024-07-22T06:23:06Z")
Проверка наличия соседей уже имплементировано Сообществом тоже: [Neighbors](https://storjnet.info/neighbors). ---
**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:** [July 23, 2024, 3:15am UTC](https://forum.storj.io/t/topic/27190/5 "2024-07-23T03:15:52Z")
8 posts were split to a new topic: [Node stopped to receive an ingress, but it’s not full](https://forum.storj.io/t/node-stopped-to-receive-an-ingress-but-its-not-full/27237)