У меня дома по проводам иногда так тормозит, что по минуте страничка обновляется. Не знаю, насколько это неудобно, 15% потерь. Там ведь в случае потерянного пакета переспрашивает действующий сейчас протокол? Собственно, кто решение принимает по дальнейшему развитию системы должен этим интересоваться. Поглядим что дальше будет. Через год планируют голосовую связь. В этом году СМС. Голосовой канал среднего уровня качества 32 кбит/с. Это без сложного кодирования. То есть пиковая емкость сейчас - до 500 разговорных каналов. Но это пиковая без учета потерь.15% потерь - это не связь
потребуется разработка специальных протоколов, которые смогут (ли?) работать при таком чудовищном уровне потерь
если не критична низкая задержка, то и с 80% потерь работать можно15% потерь - это не связь
TCP при 15% потерь работать не будет вообще. Ни с какой скоростью - потому что в каждом окне пакетов будет хотя бы один битый пакет - все окно будет перепосылаться - а там снова хотя бы один битый - связи не будет.У меня дома по проводам иногда так тормозит, что по минуте страничка обновляется. Не знаю, насколько это неудобно, 15% потерь. Там ведь в случае потерянного пакета переспрашивает действующий сейчас протокол? Собственно, кто решение принимает по дальнейшему развитию системы должен этим интересоваться. Поглядим что дальше будет. Через год планируют голосовую связь. В этом году СМС. Голосовой канал среднего уровня качества 32 кбит/с. Это без сложного кодирования. То есть пиковая емкость сейчас - до 500 разговорных каналов. Но это пиковая без учета потерь.
According to a QoS tutorial by Cisco, packet loss on VoIP traffic should be kept below 1% and between 0.05% and 5% depending on the type of video
В общем это какой-то треш. Лучше 1 мбит и 0%, чем 17 мбит и 15%VoIP is not tolerant of packet loss. Even 3% packet loss can "significantly degrade" a VoIP call using the default codec of G.711 (or G.722). G.729 codec requires packet loss of far less than 1 percent to avoid audible errors. Ideally, there should be no packet loss for VoIP.
Как-то данные передают. Хорошо бы они озвучили наряду с пиковой среднюю скорость передачи. Понятно, что она не выше пиковой за вычетом потерь. Собственно голос можно передавать при любом уровне потерь. Но конечно не VoIP. Задержки будут при потерях, что крайне неприятно. Можно обмениваться голосовыми сообщениями, напишут программу, что-то вроде Вайбера.TCP при 15% потерь работать не будет вообще. Ни с какой скоростью - потому что в каждом окне пакетов будет хотя бы один битый пакет - все окно будет перепосылаться - а там снова хотя бы один битый - связи не будет.
По умолчанию TCP стартует с размера окна в 16 КБ и постепенно разгоняется до 64КБ. При таком сценарии связь не установится - потому что 16 КБ слишком много - это условно 16 пакетов и при 15% потерь обязательно будет хотябы один битый пакет и прием окна не подтвердится.
Ну или надо будет как-то настраивать чтобы размер окна был равен 1 пакету. Правда тут всплывет другая проблема - при необходимости подтверждать прием каждого пакета скорость связи упадет катастрофически.
Голос можно еще передать по UDP конечно. Но
В общем это какой-то треш. Лучше 1 мбит и 0%, чем 17 мбит и 15%
Сорри за оффтоп, вспомнил студенческую суету с сетями в том числе и по не очень надежным (лазерным) (0,1% потерь) каналам связи
#ау
есть два варианта:Как-то данные передают. Хорошо бы они озвучили наряду с пиковой среднюю скорость передачи. Понятно, что она не выше пиковой за вычетом потерь. Собственно голос можно передавать при любом уровне потерь. Но конечно не VoIP. Задержки будут при потерях, что крайне неприятно. Можно обмениваться голосовыми сообщениями, напишут программу, что-то вроде Вайбера.
Для протокола поддерживающего подтверждение и повтор передачи потери - это просто уменьшение реальной скорости передачи. По крайней мере до какого-то уровня.15% потерь - это не связь
Цель же вроде работа с обычными телефонами, а в них менять что-то вряд ли будут. Но деле если используемые в телефонах протоколы не могут переварить 15% потерь это не проблема: не обязательно использовать максимально достигнутую на испытаниях скорость, можно снизить.потребуется разработка специальных протоколов, которые смогут (ли?) работать при таком чудовищном уровне потерь
именно такнаписать протокол канального уровня что-то типа UDP туннеля с избыточностью
в телефоне ничего менять не надо будет, это чисто программная обработка получаемых/отправляемых данныхЦель же вроде работа с обычными телефонами, а в них менять что-то вряд ли будут.
Это если в лесу. Сейчас в городе плотно стоят станции сотовой связи, сигнал сильный практически всегда. Если только иногда в подвале каком-нибудь, трудно но можно найти такое место. И попробовать связаться Скайпом - Вайбером голосом посредством интернета. У меня в деревне интернет беспроводный довольно слабый, попробую на досуге.Для сотовых работа с очень слабым сигналом является обычным делом.
Потери достигали и 19%Чтобы закончить споры я копнул чего и как они проверяли. Они установили 4G связь с обычным телефоном и передали файл 60,3 Мбайт. Скорость передачи была между 15.6Mbps to 17.2Mbps. Ну и 15% потерь, то есть файл передавался на 15% дольше, чем мог бы без потерь.
Соответвенно эксперимент даёт и ответ на наш вопрос: может ли 4G связь работать при таком количестве потерь? Смогла и не подавилась.
Судя по тому, что в первую секунду доставка 100%, а потом стабильно проседает, они тестировали толщину канала, которая оказалась чуть меньше передаваемых ими 20Мбит/с.Потери достигали и 19%
Судя по картинке по ссылке они запустили iperf и по протоколу UPD 30 секунд передавали данные (задали пропускную способность 20Мбит/сек)
Никакого файла они не передали
Ну или у вас есть ссылка на другое описание этого теста?
Увы, я читал какое-то более попсовое описание, ваше получше будетНу или у вас есть ссылка на другое описание этого теста?
Для передачи голоса на скорости 17 мегабит можно потерять и 99% пакетов15% потерь - это не связь
потребуется разработка специальных протоколов, которые смогут (ли?) работать при таком чудовищном уровне потерь
Страдающий краб в норе14 марта в 15:00 мск — предварительная дата третьего запуска Старшипа. Это следующий четверг.
(SpaceX сделала официальный анонс в соцсетях).
Мы же люди технически образованные и понимаем, что процесс высадки на Луну технически никак не зависит от страдания крабов и степени прожаренности лягушек, камни пофиксили, а плитки для высадки на Луну вообще значения не имеют, пусть хоть все отвалятся. Так что все будет хорошо)Страдающий краб в норе
Жареные лягушки
Запотевшая нержавейка, поржавевшая на сварных швах
Камни из под табуретки
Изолирующие плитки ... ой да кого эта мелочь интересует
В конце шоу бабах...
И вот это всё должно скоро высадится с людьми на Луну