Комментарии 12
Тю
Надо было просто сказать, что провайдер считает, что 1 мегабит это 1000 килобит, а в действительности все же знаю, что 1024 килобита.
Сделать speedtest на UDP?
Дело не только в невозможности утилизировать полосу одной сессией, а еще и в overhead стеков протоколов. В данном случае, ethernet, ip. Если трафик в gre, то gre. В общем, если клиент подключен в гигабитный порт ethernet свитча, 1000 мбит/с он в tcp не увидит.
Единого стандарта измерения пропускной способности нет, а следовательно мерить можно не только пейлоады, а спокойно прибавлять к ним всю служебку.
Что и происходит в большинстве случаев, так что момент с оверхедом протоколов очень скользкий.
Во всяком случае я пока не встречал договоров, что даём канал с эффективной пропускной способностью такой-то т.к. это практически лишено смысла.
Что и происходит в большинстве случаев, так что момент с оверхедом протоколов очень скользкий.
Во всяком случае я пока не встречал договоров, что даём канал с эффективной пропускной способностью такой-то т.к. это практически лишено смысла.
Отдельную радость доставляет согласование канальной скорости подключения и контрактной скорости передачи по каналу. Видел много разногласий по этому поводу когда в условный канал 128kbit/s клиенты плевали данными на скости 1Gb/s объемом с отскейленное окно.
Этот подход не user-friendly. В большинстве случаев пользовательский трафик шейпится/полисится на третьем уровне по ip. У вас же на первом, физ. скорость подключения.
Вот клиент и недоволен. Около 5% недобирает.
В межоператорских соединениях (если они за деньги) такой трюк не пройдет.
Де-факто, 99% клиентов измеряют скорость с помощью speedtest.net.
Вот клиент и недоволен. Около 5% недобирает.
В межоператорских соединениях (если они за деньги) такой трюк не пройдет.
Де-факто, 99% клиентов измеряют скорость с помощью speedtest.net.
Не… я не о том, просто хотел обозначить еще одну потенциальную проблему возникновения потерь, разрешение которой обычно не регламентирует договор. Это скорее взгляд со стороны, такие ситуации мне иногда приходится разбирать.
Речь исключительно про каналы второго уровня с большой разницей между контрактной скоростью и физической, в этом случае клиент (обычно это сервер или сервера) кратковременно выдают в канал данные на физической скорости, при этом токен буфер (где бы и на каком-уровне он не находился) переполняется очень быстро. Формально в этой ситуации никто не виноват, а фактически никто не остается довольным. Эта проблема имеет что-то общее с проблемой переполнения буффером коммутаторов в ЦОД, когда источник выдает данные на 40G, а потребитель находится за портом 10G, надеюсь так будет понятнее на что я хотел обратить внимание.
Речь исключительно про каналы второго уровня с большой разницей между контрактной скоростью и физической, в этом случае клиент (обычно это сервер или сервера) кратковременно выдают в канал данные на физической скорости, при этом токен буфер (где бы и на каком-уровне он не находился) переполняется очень быстро. Формально в этой ситуации никто не виноват, а фактически никто не остается довольным. Эта проблема имеет что-то общее с проблемой переполнения буффером коммутаторов в ЦОД, когда источник выдает данные на 40G, а потребитель находится за портом 10G, надеюсь так будет понятнее на что я хотел обратить внимание.
Ошибки приема/передачи = ошибки провайдера как бы, например, из-за качества канала (использование «дешевого» оптоволокна из китая, «дешевых» рабочих рук, «дешевых» иструментов из икеи, «дешевый» ай-ти персонал и тд).
Правильно было бы, если бы провайдер снифферил протокол, чтобы «честно» считать переданные без ошибок и оверхеда байты. Хорошая идея для стартапа? «Вы платите только за переданные байты! Самый честный провайдер ChestniyProvider!»
Правильно было бы, если бы провайдер снифферил протокол, чтобы «честно» считать переданные без ошибок и оверхеда байты. Хорошая идея для стартапа? «Вы платите только за переданные байты! Самый честный провайдер ChestniyProvider!»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В поисках утерянного гигабита или немного про окна в TCP