For two months, incoming traffic has been around 300 GB per node. The nodes are located in different places, but on approximately the same equipment, territorially in the Rostov region in Russia. Is this normal traffic or do I have some problems? I apologize for my English in advance.
Sounds pretty good to me. But you are missing a lot of back info.
The volume of nodes is about 7-9TB, 1-2 nodes per ip. 100Mbps Channel
I dunno then, you sound similar in size to Alexey, and he stated the other day on a recent post (or today) about 1.2TB for his 2 (for sure), 3 or maybe 4 nodes (often testing for the benefit of the forum) - unsure of his /24 status/setup.
Nonetheless, it’s often about latency to market.
.2 cents,
Julio
Forum is broken or @DAMELDOR has a time machine.
1 Like
It was over 1.5 years ago: so they must round up I guess?
1 Like
Yes these 3 nodes behind the same /24 subnet, located in Saint Petersburg, so they are close to Europe, thus perhaps win more races.
They received 1.49TB ingress so far, the total usage is 7.79TB/9.28TB, the net grow is approximately 300GB since the last month, the difference in ingress maybe greater, however, there are also were deletions about 1TB last month.
1 Like
How critical is disk fragmentation?
1 Like
For NTFS? Significant, it could become slower in several times, you may also start to see these errors:
So, regular defragmentation for NTFS is highly recommended. It’s also enabled by default, unless you disable it.
However, if you see a high defragmentation, it’s advisable to run it manually.
Maybe with a new hashstore backend it may become a not required, see hashstore
Please be aware, this an experimental feature, so it’s not recommended to run on a production node, unless you are ready that it may be lost or disqualified and agreed with that.
2 Likes
Thank you for the answer, I will take action to defragment
1 Like
I never did a defrag for my windows nodes. The oldest one is four years old now. 
There is an automatic defrag job added automatically for every connected disk. You can disable it of course, but then a fragmentation will kill IOPS of your drive.
Ингрес на сейчас примерно 1.2-1.3 тб на /24 в Московской области.
Так что Алексей Ваше нахождение в Спб бонусов за собой не несет.
А вот в южных регионах России трафик в 2-3 раза на /24 меньше, хотя пинг всего на 20-25 мс хуже Москвы. И это безобразие на юге началось примерно с середины сентября. Не знаю что это, но возможно фильтрующее оборудование ркн залагало трафик, возможно суверенный интернет, а возможно в сторже пошло что-то не так.
Как раз все пошло именно “так”. Они же перенастроили систему, “хвосты” там какие-то и систему рейтинга. Так что трафик теперь перекособочило - кому-то сотнями льет а кому-то по 10 гиг дай бог, хотя разница в десяток - другой мс. Вот тебе и децентрализация…
Что за хвосты ? Что за рейтинг ? Где четкое и открытое описание этого волшебства в стакане молока ? В США так то пинги могут и по 30-40 мс различаться между исткоаст и весткоаст, изи. Неплохо бы оттуда тоже поиметь отклик на предмет залипания ингреса в определенных зонах.
У себя в логах не вижу особой разницы что в Москве, что на юге. Процент успешности аплоадов 99.95%+. При разнице в ингресе в 2-3 раза на /24.
Defragmenting doesn’t help at all if it’s deleted every day. Then hard drives fail even earlier. I used to defragment all the time too. But then I let it go because it didn’t help and the process never ended.
3 Likes
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, загрузка будет отменена.
They meaning that we implemented a choice of n rule, described there:
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
Оно использует оценку успешности, чтобы определить, какой из n будет выбран для загрузки. Таким образом, это дополнительное правило к выбору подсети /24 и оценкам репутации. Это дополнительное правило используется для еще большего увеличения скорости загрузки для клиентов. Побочный эффект - теперь узлы VPN на том же сервере имеют худшую оценку успешности, чем те же узлы без VPN. Это не окончательное решение, но оно помогает.
“Хвосты”, вероятно, отсылка к “отмене длинного хвоста”, которая была здесь с первого дня. Libuplink выбирает 110 узлов, а затем начинает выгрузки параллельно, когда первые 80 завершаются, все оставшиеся отменяются. Эти отмененные выгрузки называются “отрезанием длинного хвоста”.
Is it possible to see the rating of the node? if not, it would be nice to add it to the control panel to understand where the problems have appeared
1 Like
Алексей! Давайте выражаться более понятно для большинства… Ни какого трафика напрямую от клиентов можно сказать не существует, за исключением включения пару раз в сутки бакапов тривана. 99%+ ингрес - трафик от прокладок сторжа, вероятнее всего s3. Ни кто в здравом уме таки не переписывает готовый код под нативного клиента сторжа, вместо исправления настроек s3 для приложения. Потому можно говорить проще - трафик в основном с американских IP адресов datapacket.com.
Я повторюсь - у меня нет отмен загрузок, ни каких гонок я не проиграл. Мне тупо спутник не дал загрузки.
А раз загрузок не дал спутник, то хотелось бы знать на основании чего он не дал ?
Где обещанные гонки ? И это прямой IP от провайдера на юге России в 20-25мс от Москвы. Однако на сейчас этот IP получил 10.67 ГБ, а нода в МО 21.7 ГБ. Разница в 2 раза. То есть если бы спутник мне давал загрузки, я бы имел половину отмен. IP в МО - vpn. Так что алгоритм при котором наваливают на впн, и не наваливают на прямой IP домашнего провайдера мне не понятен.
На счет впн… У меня на многих локациях провайдер не предоставляет выделенных IP , потому впн для меня единственный вариант приземлить туда сторжа. На других локациях выделенный IP стоит 600р/мес, приземление порта через впн стоит не более 100р. Для сторжа разница в 5 долларов - принципиальна. Вся эта непонятная попытка бороться с впн, если таковая конечно была сделана целенаправлено… Тут сторжу надо быть аккуратнее и не выплеснуть вместе с водой ребёнка. Есть понятие гонки - все остальное от лукавого.
1 Like
Just a digression
the only thing to defrag what maters seems to be MFT zone. it can be in 100-200GB size, imagine those records being thrown all over the 16TB disk, because as soon as it goes past default windows size, its starting to be written wherever the space is, and thats can get really nasty. Im still postponing experimenting with that, as its not priority unfortunately right now for me. I read that some PerfectDisk by raxco patented some super duper cool anti-defrag mechanics that prevent fragmentation, but i need to find time to experiment with that.