SLIP каналы с дозвоном (Dialup)

При использовании SLIP каналов с дозвоном существуют некоторые отличия, так как на каждом конце канала присутствуют модемы. Модемы, которые используются между системами netb и sun, предоставляют то, что называется модуляцией V.32 (9600 бит/сек), контроль ошибок V.42 (также иногда называемый LAP-M) и сжатие данных V.42bis. Это означает, что наши простые вычисления, которые были достаточно точны для выделенного канала, где известны все параметры, в таких условиях практически неверны.

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

В следующем примере мы послали ping на хост gemini с хоста sun.

sun % ping gemini
PING gemini: 56 data bytes
64 bytes from gemini (140.252.1.11): icmp_seq=0. time=373. ms
64 bytes from gemini (140.252.1.11): icmp_seq=1. time=360. ms
64 bytes from gemini (140.252.1.11): icmp_seq=2. time=340. ms
64 bytes from gemini (140.252.1.11): icmp_seq=3. time=320. ms
64 bytes from gemini (140.252.1.11): icmp_seq=4. time=330. ms
64 bytes from gemini (140.252.1.11): icmp_seq=5. time=310. ms
64 bytes from gemini (140.252.1.11): icmp_seq=6. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=7. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=8. time=280. ms
64 bytes from gemini (140.252.1.11): icmp_seq=9. time=290. ms
64 bytes from gemini (140.252.1.11): icmp_seq=10. time=300. ms
64 bytes from gemini (140.252.1.11): icmp_seq=11. time=280. ms
----gemini PING Statistics----
12 packets transmitted, 12 packets received, 0% packet loss
round-trip (ms) min/avg/max = 280/314/373

Обратите внимание на то, что в первой строке RTT не кратен 10 миллисекундам, однако в остальных строках значение RTT кратно 10 миллисекундам. Если запустить этот пример несколько раз, то можно заметить, что подобное поведение сохранится. (Это вызвано точностью часов хоста sun - они предоставляют разрешение в одну миллисекунду. Это было проверено тестами, которые приведены в приложении В.)

Также обратите внимание на то, что первый RTT больше чем следующие, а остальные уменьшаются в процессе работы команды и их диапазон находится между 280 и 300 мс. Если не останавливать программу примерно минуту или две, RTT останутся в этом диапазоне, никогда не уменьшаясь меньше чем 260 мс. Если рассчитать ожидаемый RTT для скорости 9600 бит/сек (упражнение 2 главы 7), величина составит 180 миллисекунд, таким образом мы ошиблись в расчете примерно в 1,5 раза от реального значения.

Если программа ping будет работать в течение 60 секунд, то среднее RTT при использовании V.42 и V.42bis составит 277 миллисекунд. (Это лучше, чем значение, полученное в предыдущем примере, так как программа работала долше, при этом значение RTT застабилизировались в определенном диапазоне.) Если выключить сжатие данных V.42bis, то среднее значение составит 330 миллисекунд. Если выключить контроль ошибок V.42 (который также выключается при выключении сжатия данных V.42bis), среднее значение составит 300 миллисекунд. Эти параметры модемов влияют на RTT, однако все же лучше использовать контроль ошибкок и сжатие данных.

Содержание раздела