Добрый день. извиняюсь за то что пишу предложение на русском языке, мне так проще излагать мысли.
Во многих группах тематики Storj, Я частенько замечал вопросы связанные с тем, что одни ноды получают максимальный трафик, другие минимальный, и объяснению этому нету, но по факту под “капотом” каждый спутник использует свою систему ренжирования имеющихся у него в распоряжении нод. и это правильно, мы всегда оцениваем надежность партнера, я предлагаю чтобы данный показатель был публичный, и каждый спутник совместно с uptime ноды также отображала данный показатель. Динамика изменения данного показателя позволит владельцам нод, ориентируясь на этот показатель, улучшать свои ноды, Ведь вполне возможно что кто то держит у себя огромные ноды, но по показателям спутника, они не интересны для него, лучше сразу сказать об этом владельцу нод, чтобы он не тратил силы на расширение текущего состояния, а думал как можно изменить ситуацию, чтобы его ноды были более востребованы. но для этого нужны четкие и понятные показатели.
Этот показатель называется “репутация” и состоит из трёх оценок, которые у вас всегда видны на dashboard:
- audit score
- suspension score
- online score
Локальная эффективность узла может быть грубо оценена с помощью скрипта
Глобальная статистика, поддерживаемая Операторами в этом треде:
Других оценок нет.
Насколько я понимаю, вам бы хотелось ещё видеть какую-то статистику почему ваш узел был выбран или не был, однако она не статичная, меняется на каждый запрос, это просто огромный объём данных и абсолютно бесполезный сразу после публикации.
Что влияет на выбор того или иного узла:
- Узел должен быть онлайн
- Репутация (см. выше).
- Состояние проверки (новые узлы получают не более 1%-3% загрузок от клиентов).
- Подсеть (для каждого кусочка сегмента выбирается один узел из подсети /24 публичных IP, чтобы не помещать кусочки одного сегмента в одно физическое место и/или того же ISP). Выбор случайный.
- Динамическое вычисление success rate на спутнике (у вас оно уже есть, см. выше). Оно не статическое, раз в несколько минут пересчитывается. Позволяет не перегружать слабые узлы и в то же время выбирать быстрейшего для этого конкретного клиента.
- Спутник выбирает по критериям выше 2х набор потенциальных узлов для каждого кусочка каждого сегмента и из них выбирает по одному узлу с наивысшими оценками для каждого кусочка каждого сегмента.
В результате клиент получает список узлов для всех кусочков каждого сегмента, на которые он начинает загрузку параллельно. Как только минимально необходимое количество кусочков загружено, остальные загрузки отменяются.
ну вот, как я вижу тут достаточно четко вырисовывается еще один из достаточно стабильных параметров, это наличие “соседей”, в пространств /24, а также сколько их, чтобы оценивать вероятность деления трафика? я где то видел запрос на получение этой информации, но так с ходу не вспомню.
и на сколько я понял наличие двух и более узлов даже на одном адресе /32, в принципе это не особо страшно, если все они принадлежат одному хозяину, для спутника они все вместе будут иметь такой же вес как и если бы это была бы одна большая нода.
а вот если узлы расположены в /24 и принадлежат разным хозяевам, то ту получится уже деление трафика между разным хозяевам.
Я правильно понимаю?
Проверка наличия соседей уже имплементировано Сообществом тоже: Neighbors.
8 posts were split to a new topic: Node stopped to receive an ingress, but it’s not full