模板
教程
環境
性能
功能
管理
撥號SLIP鏈路
對于拔號SLIP鏈路來說，情況有些變化，因為在鏈路的兩端增加了調制解調器。用在sun和netb系統之間的調制解調器提供的是V.32調制方式（9600b/s）、V.42錯誤控制方式（也稱作LAP-M）以及V.42bis數據壓縮方式。這表明我們針對線路鏈路參數進行的簡單計算不再準確了。
很多因素都有可能影響。調制解調器帶來了時延。隨著數據的壓縮，分組長度可能會減小，但是由于使用了錯誤控制協議，分組長度又可能會增加。另外，接收端的調制解調器只能在驗證了循環檢驗字符（檢驗和）后才能釋放收到的數據。最后，我們還要處理每一端的計算機異步串行接口，許多操作系統只能在固定的時間間隔內，或者收到若干字符后才去讀這些接口。
作為一個例子，我們在sun主機上ping主機gemini，輸出結果如下：
注意，第1個RTT不是10ms的整數倍，但是其他行都是10ms的整數倍。如果我們運行該程序若干次，發現每次結果都是這樣（這并不是由sun主機上的時鐘分辨率造成的結果，因為根據附錄B中的測試結果可以知道它的時鐘能提供毫秒級的分辨率）。<br>
另外還要注意，第1個RTT要比其他的大，而且依次遞減，然后徘徊在280～300ms之間。我們讓它運行1~
2分鐘，RTT一直處于這個范圍，不會低于260ms。如果我們以9600b/s的速率計算RTT，那么觀察到的值應該大約是估計值的1.5倍。<br>
如果運行ping程序60秒鐘并計算觀察到的RTT的平均值，我們發現在V.42和V.42bis模式下平均值為277ms（這比上個例子打印出來的平均值要好，因為運行時間較長，這樣就把開始較長的時間平攤了）。如果我們關閉V.42bis數據壓縮方式，平均值為330ms。如果我們關閉V.42錯誤控制方式（它同時也關閉了V.42bis數據壓縮方式），平均值為300ms。這些調制解調器的參數對RTT的影響很大，使用錯誤控制和數據壓縮方式似乎效果最好。
