All streams
Search
Write a publication
Pull to refresh
1
0

Пользователь

Send message

На самом деле Лайтком/Миландр просто с халтурили потому что добавить ненужный чип так чтобы без него не работало это проще простого и вариантов миллион. Ну например поставить вместо ROM - RAM и загружать туда прошивку Российским чипом при каждом запуске. Без этого чипа 100% ничего работать не будет. Более того, есть и хорошее обоснование - защита прошивки от внешнего воздействия. И все, вообще никто не сможет к этому придраться. И это только один вариант, а их миллионы.

А почему не обратили внимание на JCID AIXUN T3A? По моему, это лучший паяльник для начинающих. Стоит не дорого и можно выбрать тип жала T12/T245/936 по своему желанию. Я в основном использую T245 и он реально нагревается за секунду.

Но даже если код открытый — то где гарантия, что на серверах запущен именно он?

По идее, при наличии открытого кода можно было бы запустить этот код у себя и скормив ему данные из блокчейна получить результаты, которые должны совпасть с официальными. Но тут возникнет другая проблема - где гарантия того что данные не подменят перед тем как положить в блокчейн (по аналогии с атакой "man in the middle" )?

Можете попробовать собрать и протестировать bitbucket.org/ddv2005/tcp_yeah_ext
Для сборки нужен tcp_vegas.h от установленной версии ядра. Модуль имеет несколько параметров которые можно менять на ходу. Минимальное окно меняется от min_cwnd (при min_rtt) до max_min_cwnd (при max_rtt) линейно в зависимости от rtt (round trip time).
У меня тоже стояла задача передачи видео по интернету на дальние расстояния (RTT >100ms) и я пробовал различные реализации через UDP, но по факту они все оказывались хуже TCP. Тогда я решил выбрать tcp congestion protocol на стороне сервера, который бы лучше работал с клиентским Cubic на дальних расстояния… Собрал стенд с задержками и потерей пакетов 1-5% и начал тестировать. По моим тестам лучше всего себя показал Yeah. Поставил его и стало немного лучше, но все равно при потерях >3% скорость одиночного соединения недостаточна для качественного видео. Все потому, что размер окна падает ниже требуемого уровня при таких задержках. Сама сеть может передать поток даже с такими потерями, но размер окна не позволяет ей. Тогда я подумал, а почему просто взять и не ограничить минимальный размер окна? Ведь выбирает его tcp congestion protocol на передающей стороне… максимальный битрейт видео известен, RTT известно, поэтому легко выяснить минимально нужный размер окна. Тогда я просто немного изменил имеющуюся реализацию Yeah и попробовал. Оказалось, что моя реализация отлично работает и может «проглотить» до 15% потерь, хотя стандартная затыкалась уже на 3%. Конечно это не спасает от ситуации когда сеть в принципе не готова пропустить такой поток данных ( например при плохом WiFi соединении).

Information

Rating
5,356-th
Location
New York, New York, США
Registered
Activity