# Low volume of incoming traffic on nodes

**URL:** <https://forum.storj.io/t/low-volume-of-incoming-traffic-on-nodes/28890>\
**Category:** Node Operators\
**Created:** [December 23, 2024, 11:17am UTC](https://forum.storj.io/t/low-volume-of-incoming-traffic-on-nodes/28890 "2024-12-23T11:17:57Z")\
**Posts on this page:** 1\
**Showing post:** 17

<div class="post-metadata">

**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:** [December 26, 2024, 4:14am UTC](https://forum.storj.io/t/low-volume-of-incoming-traffic-on-nodes/28890/17 "2024-12-26T04:14:32Z")

</div>

The traffic is flowing directly between the customers and nodes bypassing satellites completely. Thus ping doesn’t matter. The only matter is a speed between your node and the customer.  
If your node is slower than other 109 from the selection, the upload will be canceled.

> **на русском**
>
> Трафик идёт напрямую между клиентами и узлами, минуя сателлиты. Поэтому Ping не влияет, влияет только скорость между клиентом и вашим узлом. Если ваш узел медленнее, чем другие 109, загрузка будет отменена.

> [@AiS1972](#):
>
> > [@dmp](#):
> >
> > Как раз все пошло именно “так”. Они же перенастроили систему, “хвосты” там какие-то и систему рейтинга.
> 
> Что за хвосты ? Что за рейтинг ? Где четкое и открытое описание этого волшебства в стакане молока ?

They meaning that we implemented a choice of n rule, described there:

> [@Updates on Test Data](https://forum.storj.io/t/updates-on-test-data/26034/313):
>
> Ok while you are removing any concurrency limit you might have set I will explain how the node selection actually works. When a segment gets commited to the database it will contain the nodes that have been fast enough and it will be missing the nodes that got long tail canceld. The satellite calculates a success rate for each node with that. The node selection takes that success rate. Instead of 110 total nodes it selectes 220 nodes at first and compares them in pairs and pick the one with th…

It uses success rate score to determine which one from `n` would be selected for uploads. So this is an additional rule to the /24 subnet selection and reputation scores. This additional rule is used to increase the upload speed for the customers even more. The side effect - now VPN nodes on the same server have a worse success rate than the same nodes without VPN. It’s not a final solution, but it helps.  
“Tails” likely a reference to a “long tail cancelation”, which was here from day 1. The libuplink select 110 nodes and then start uploads in parallel, when the first 80 are finished, all remained got canceled. These canceled uploads are called “cut the long tail”.

> **на русском**
>
> Они имеют в виду, что мы реализовали правило выбора n, описанное здесь:  
> [Updates on Test Data - #313 by littleskunk](https://forum.storj.io/t/updates-on-test-data/26034/313)
> 
> Оно использует оценку успешности, чтобы определить, какой из `n` будет выбран для загрузки. Таким образом, это дополнительное правило к выбору подсети /24 и оценкам репутации. Это дополнительное правило используется для еще большего увеличения скорости загрузки для клиентов. Побочный эффект - теперь узлы VPN на том же сервере имеют худшую оценку успешности, чем те же узлы без VPN. Это не окончательное решение, но оно помогает.  
> “Хвосты”, вероятно, отсылка к “отмене длинного хвоста”, которая была здесь с первого дня. Libuplink выбирает 110 узлов, а затем начинает выгрузки параллельно, когда первые 80 завершаются, все оставшиеся отменяются. Эти отмененные выгрузки называются “отрезанием длинного хвоста”.

---

_[View the full topic](https://forum.storj.io/t/low-volume-of-incoming-traffic-on-nodes/28890)._
