Оценка занятости сетевого канала

apt-get install nload

или

yum install nload

Показывает что-нибудь навроде

Curr: 573.86 kBit/s
Avg: 558.82 kBit/s
Min: 527.72 kBit/s
Max: 579.96 kBit/s
Ttl: 126.77 MByte

Замеряй rtt, он может увеличиться при забитом канале. Также смотри потери пакетов. Все это можно проверять пингом.

Пускаешь ping до какого-либо ресурса. Смотришь средний результат(RTT). Забиваешь канал. Пускаешь ping снова. Он должен быть гораздо более хреновым. Смотришь загрузку канала - вот твой условный максимум.

Учти, что повышение RTT может начаться при загрузке более 80%-85% физического канала. По крайней мере большинство провайдеров в межпровайдерских договорах указывают именно такую границу. То есть если у тебя физика - 100Mbit/sec, до дать по ней больше 80-85 Мегабит если и получится, то без особых гарантий.

Хотя судя по твоему выхлопу nload это не твой случай.

Ну и традиционно, если на канале даже в отсутствии нагрузки(при перегруженном канале потери пакетов - вполне себе норма) есть потери больше 2-3%, то скорость мерять на нём бессмысленно - она будет фиговой, да еще и «плавать».

А что за железка на канале? А то же можно просто состояние и статистику порта посмотреть.

забей, WAN это называется не просто так, а потому, что там может происходить всякое от тебя не зависящее и растянутое по времени.
то, что ты намеряешь сейчас, любым способом — через пять минут может стать не актуальным.
раз твоя мерилка будет генератором рандомных чисел — забей.

Забиваешь канал

Хотелось бы обойтись без этого шага, мне не нужно точное значение скорости, а только узнать, канал полностью используется или нет.

Канал - это спутниковый линк, установленный на корабле, находящемся на высоких широтах, соотвественно скорость низкая и плавает в зависимости от погоды. Но интересует меня трафик внутри тоннеля OpenVPN. Хочется иметь индикацию, полностью канал используется или нет, ну или хотя бы информацию вроде «в канале большие потери, но трафик идёт» без создания дополнительной нагрузки на канал.

через пять минут

Ну да, весь смысл - предоставлять информацию на данный момент времени. Как уже говорил, речь о спутниковом линке с корабля, само собой там всё меняется каждую минуту.

Это нужно знать просто для галочки, или есть какие нибудь симптомы плохого канала которые пешают работать? Если второе, то при появлении симптомов ты уже знаешь что с каналом плохо. Узнать загруженность канала без доступа к оборудованию практически невозможно. Можно лишь мерять такие вещи как latency, rtt, jitter и делать выводы

Нужно для показометра, примерно оценить на глаз, насколько велик шанс, к примеру, что почта, отправленная сейчас, уйдёт достаточно быстро. Никаких программных мер предпринято не будет, чтобы что-то изменить.

Эм, так не получится. Не попытавшись забив канал полностью ты не узнаешь может ли он использоваться полностью или нет(пардон за тавтологию).

Я теперь уже вообще не понимаю что ты хочешь измерить? Ты понимаешь, что в условиях плавающей верхней планки скорости нельзя сказать насколько хорошо используется канал? По крайней мере в IP-сетях.

информацию вроде «в канале большие потери, но трафик идёт» без создания дополнительной нагрузки на канал.

Регулярный пинг доверенного ресурса. Тебе мониторинг нужен скорее всего.

Хочется иметь индикацию, полностью канал используется или нет
без создания дополнительной нагрузки на канал.

Если скорость плавает - задача нерешаема. Можно только промониторить насколько нагружен канал(но не в процентах от плавающего неизвестного, а в абсолютных значениях скорости - Мбит/сек)

Построй на двух смежных графиках те параметры, которые ты можешь собирать пассивно или с минимальными нагрузками на канал (типа пинга раз в 10 секунд)

На первом графике загрузка канала, а на втором минимальное/максимальное время пинга и процен потерь.

Посмотри кто из них будет индикаторм перегрузки. Уж больно специфический у тебя канал.

Теоретически, через ss можно мониторить rto/rtt в tcp-соединении Если у тебя ovpn использует tcp то его можно мониторить примерно так

ss -4ti state established '( dport = :1194 )'

Почему не узнаю? Ведь если есть соединение по TCP, как-то же оно подстраивается под максимальную пропускную способность, если данных достаточно? Я понимаю, что используются метрики внутри соединения, но может быть есть какой-то внешний способ померять что-нибудь навроде процента недошедших пакетов?

Спасибо, попробую завтра.

Хорошим индикатором в данном случае оказался счётчик дропа пакетов.

уровень сигнала измеряй/показывай, он с со скоростью очень даже кореллирует

Пользуюсь iftop -m(макс скорость) как только индикатор доходит до конца, все канал забит, начинаю фильтровать :)