Привет! Возможно, немного не в той теме, но программировать буду на Си 

Вопрос чисто теоритический. Как измеряют пропускную способность канала/сети/сегмента сети? К примеру, есть канал 12 Мбит/c. 
Какие размеры кадров при какой пропускной способности канала лучше слать. Зависимость размера пакетов от пропускной способности. Процент загруженности канала? Какие есть формулы по этому вопросу?
Не знаю вообще, в какую сторону смотреть, как правильно задать вопросы на эту тему, как ввести запрос в google (на все мои запросы выводит инструменты для измерения пропускной способности канала. кстати, как они работают?). 
Могу только считать количество отправленных байт за секунду/минуту и выводить это количество   

максимальные, которые поддерживают передающий и принимающий интерфейс (для сокращения служебной информации), но не больше (для предотвращения фрагментации). см. mtu

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

пропускная способность "канала", состоящая из грузовика, перевозящего dvd, гораздо выше существующих сетей, но задержка велика   

Не понимаю работу сети при ограниченном канале.
Допустим есть стандратные сетевые устройства 100 Мбит/с. Выделил мне провайдер канал 12 Мбит/с. Пользуюсь каналом не только я. 
12 Мбит/c = 1.43 МБ/c
Допустим, кто-то качает с торрента со скоростью 500 КБ/c. Возьмем издержки 20% (служебная информация, потеря пакетов, повторная отправка и т.п.). В итоге канал загружен на 600 КБ/с.
Я отправляю какой-то пакет. Стандартный MTU сейчас в основном 1500 байт + ethernet header (+ VLAN header, + преамбула и еще некоторые заголовки в зависимости от сети). 

1)Сначала рассмотрим простой случай, где от отправителя до получателя все сети поддерживают MTU = 1500 байт. Возникающие вопросы: что будет происходить с моим пакетом? При каком размере пакета я смогу загрузить канал до предела, т.е. отправлять максимальные пакеты или делить их например по 750 байт.

2) А если где-то MTU на пути пакета будет, к примеру, 500 байт. Как узнать, что пакет был фрагментирован? Что лучше, отправлять все равно пакеты по 1500 байт, или делить их по 500 байт.

И тому подобные вопросы:)

Добавлено через 7 минут и 1 секунду
Выдержки из Википедии, которые меня не устраивают:

1) Как правило, фрагментацию выполняют более медленные процессоры, нежели те, что обрабатывают транзитный трафик. В некоторых случаях задержки, которые вызовет фрагментация всех пакетов, могут быть сочтены неприемлемыми.
2) Увеличивается нагрузка на процессоры промежуточных маршрутизаторов и машины адресата.
3) Некоторые межсетевые экраны могут блокировать фрагменты.
4) Из-за копии IP-заголовка для каждого фрагмента неэффективно используется полоса пропускания.
5) Протоколам маршрутизации, например OSPF, требуется согласованный MTU для корректной работы.

Пропускную способность канала в 12 МБит/с измеряют путём вычисления количества переданных бит за некоторое время, и делению его на количество секунд в это время.

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

То есть для физики -- это можэт оказаться частота передачи символов умножэнная на размер символа. Дажэ несмотря на то, что там 25% будет использовано на самосинхронизацыю этой физики, заголовки и error correction (как оно, в общем, в WiFi и есть -- только по факту не ровно 25%, а всё очень сложно). Или без error correction -- в Ethernet скорость как раз выдают с учётом кодирования 8b/10b, т.е. 125 однобитных мегасимволов в секунду после декодирования 8b/10b дают как раз 100Mbit/s. А межпакетные интэрвалы всякие -- это вашы проблемы.

С другой стороны, типичная провайдэрская резалка даёт в скорости суммарный размер IP-пакетов если это типа роутер и суммарный размер Ethernet-пакетов если это типа свитч. С разницэй на размер Ethernet-заголовка.



Практически независит. То есть есть некоторые варианты -- например, когда у вас 128kbit/s, и нужэн какой-нибудь realtime (да хотя бы голос), то на этом интэрфейса надо зарезать MTU, а то каждый пакет будет его задержывать на 100ms. Но вообще -- чем большэ, тем быстрее дойдёт, и обычно размер кадра ограничен внешними факторами.

PS Да, некоторая банальность: производители, когда хвастаются достижэниями своих жэлезок -- обычно выдают пиковую пропускную способность. Если это в Mbit/s -- то это будет на самом большом размере пакета, и тупейшый роутинг без особых фильтров. Если это будет в pps (packets per second) -- то, соответственно, скорее всего наоборот такое достигается только на самом маленьком размере пакета.
В общем, везде сплошной обман.
PPS В lartc.org есть большой раздел, посвящённый шэйпингу. Он, во многом, херовый, и мнение Кузнецова о том, какой должэн быть правильный шэйпинг откровенно говоря оказалось не слишком адэкватно: его шэйпером как минимум мало кто можэт пользоваться. Как максимум -- выставленные наружу ручки управляют совсем не тем, чем хотелось бы, и правильный результат получается разве что случайно.
Однако хотя бы некоторые основные понятия там вводятся, да и в любом случае если стоит линукс и ты ковыряешь на нём сеть -- то эту информацыю стоит знать.
PPPS Да, ещё стОит прочесть документацыи по Cisco IOS по поводу traffic shaping. Всякие правила классификацыи там тебе будут неинтересны, а вот что такое cir, burst и пр -- есть смысл узнать.



Очевидно, при любом. Ну, если у тебя не 20 гигабит/с канал, который не смогут нагрузить доступные внешние источники. Правда, полезный результат этой нагрузки до предела можэт быть разным.

на первый вопрос есть прямой ответ в вики


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


у меня тоже есть претензии: зарплата маленькая, солнце тусклое, жизнь короткая)))

Добавлено через 10 минут и 29 секунд

а что там не так?

konshyn, вообще, для измерения параметров сегмента, доступного с обоих концов физически, используется измерительное оборудование (параметры канала) и нагрузочные тесты (параметры сети/приложения).
для измерения скорости "в интернет" максимум что можно сделать - стучаться на известный сервер на быстром канале.
в обоих случаях в основном измеряется задержка и пропускная способность, а так же стабильность этих параметров (в простейшем случае - min, max, avg).