如果線路速率是9600b/s，而一個字節有8bit，加上一個起始比特和一個停止比特，那么線路的速率就是960B/s（字節/秒）。以這個速率傳輸一個1024字節的分組需要1066ms。如果用SLIP鏈接運行一個交互式應用程序，同時還運行另一個應用程序如FTP發送或接收1024字節的數據，那么一般來說就必須等待一半的時間（533ms）才能把交互式應用程序的分組數據發送出去。 假定交互分組數據可以在其他“大塊”分組數據發送之前被發送出去。大多數的SLIP實現確實提供這類服務排隊方法，把交互數據放在大塊的數據前面。交互通信一般有Telnet、Rlogin以及FTP的控制部分（用戶的命令，而不是數據）。 這種服務排隊方法是不完善的。它不能影響已經進入下游（如串行驅動程序）隊列的非交互數據。同時，新型的調制解調器具有很大的緩沖區，因此非交互數據可能已經進入該緩沖區了。 對于交互應用來說，等待533ms是不能接受的。關于人的有關研究表明，交互響應時間超過100～200 ms就被認為是不好的[Jacobson 1990a]。這是發送一份交互報文出去后，直到接收到響應信息（通常是出現一個回顯字符）為止的往返時間。把SLIP的MTU縮短到256就意味著鏈路傳輸一幀最長需要266ms，它的一半是133ms（這是一般需要等待的時間）。這樣情況會好一些，但仍然不完美。我們選擇它的原因（與64或128相比）是因為大塊數據提供良好的線路利用率（如大文件傳輸）。假設CSLIP的報文首部是5個字節，數據幀總長為261個字節，256個字節的數據使線路的利用率為98.1%，幀頭占1.9%，這樣的利用率是很不錯的。如果把MTU降到256以下，那么將降低傳輸大塊數據的最大吞吐量。 在圖2-5列出的MTU值中，點對點鏈路的MTU是296個字節。假設數據為256字節，TCP和IP首部占40個字節。由于MTU是IP向鏈路層查詢的結果，因此該值必須包括通常的TCP和IP首部。這樣就會導致IP如何進行分片的決策。IP對于CSLIP的壓縮情況一無所知。 我們對平均等待時間的計算（傳輸最大數據幀所需時間的一半）只適用于SLIP鏈路（或PPP鏈路）在交互通信和大塊數據傳輸這兩種情況下。當只有交互通信時，如果線路速率是9600b/s，那么任何方向上的1字節數據（假設有5個字節的壓縮幀頭）往返一次都大約需要12.5ms。它比前面提到的100~200ms要小得多。需要注意的是，由于幀頭從40個字節壓縮到5個字節，使得1字節數據往返時間從85ms減到12.5ms。不幸的是，當使用新型的糾錯和壓縮調制解調器時，這樣的計算就更難了。這些調制解調器所采用的壓縮方法使得在線路上傳輸的字節數大大減少，但糾錯機制又會增加傳輸的時間。不過，這些計算是我們進行合理決策的入口點。 在后面的章節中，我們將用這些串行線路吞吐量的計算來驗證數據從串行線路上通過的時間。