一位客户通过卫星接入Internet,带宽为2M，连接方式如下:下行链路为卫星小站接LNB再接RCR，然后用RJ45接口接到以太网；上行链路是路由器V.35接MOD再接ODU，然后通过卫星小站发送出去。
路由器配置如下：
interface FastEthernet0/0 ip address 202.101.111.1 255.255.255.0 no ip directed-broadcast ! interface Serial0/0 bandwidth 2048 ip address 10.1.1.2 255.255.255.252 no ip directed-broadcast no keepalive ignore-dcd
ip route 0.0.0.0 0.0.0.0 10.1.1.1
由于Serial 0/0 只发送不接收，对端无DCD信号，无keepalive信号，所以要设置no keepalive和ignore-dcd.
RCR (由卫星施工人员设置)的以太网地址与路由器F0/0同一子网，默认网关设为:202.101.111.1(路由器的以太网口地址).
设置完成后，测试发现：首先，ping 对端主机延时大,一个来回约为690ms。
由于卫星距地面约3.8万公里，信号往返约为3.8 x 4 =15.2 万公里，除以光速 30万公里每秒，约为0.5s，即500ms,所以延时基本正常。呵呵，这样算对吗?
还有一个让用户无法接受的测试结果是：用FTP从对端服务器下载文件，速率只能达到32k/s!
照理说线路的传输速率是2M bps，约等于250k 字节每秒才对，就算减掉协议的损耗，也该有个200k/s吧？
这个问题的揭示更有意思，它让我们发现延时是如何地影响了数据传输的速率。
我们知道FTP基于TCP，TCP在传输数据的时候接收方要进行应答，发送方在发送w个数据包后必须要收到一个应答包表明这些数据包已经送到，才能继续发送。如果线路的传输误码率很低，则w可以增大，反之要减少，这就是窗口机制。
本例中假设因线路质量极好，w达到16,MTU=1500,则发送方发送16 x 1500 = 24000 字节之后等待接收方的一个应答包(更正：Windows值为字节数，即发送n个字节后应等待一个应答，最大值：65535，故在此应为假设w=24000)，忽略建立连接的时间（三步握手建立连就用了 345 ms x 3 = 1035 ms 呢 ）,忽略字节流的传输时间，这24000个字节经过卫星链路到达接收方时花了345ms(690 ms / 2),接收发的应答包在345ms后亦传到了接收方处，则在这次传输中 24000 字节花了 690 ms, 速率为33.97k 字节每秒。
照此计算，在一般局域网中，如果延时为10 ms, 则在同样 n=16 MTU=1500的条件下速率可达2344k 字节每秒。当然，这要求你的线路带宽大于2344k 字节每秒(即18.3M bps)，否则网络将出现阻塞，速度下降。
由于速率只有32k/s，故上述的一个FTP会话其实只占了带宽的大约1/8.如果使用多线程的FTP工具，如netants,由可以充分利用带宽，使下载速度达到200k/s左右,实验证明了这一点。
==带宽延时如何产生？如何进行计算？==
现在，我们对带宽延时及计算方法开始进行讨论，大家基本确定，带宽延时就是串行延时。会后偶再查阅相关也资料表明，这个结论是正确的。那么什么是串行延迟？确切的讲，串行延迟产生的根本原因是将数字数据放到传输线路中的串行化的结果，所以，其延迟大小取决于传送线路的速度。也就是说，无论我数据包大小如何，把它放到线路上串行化传输所花的时间，跟带宽是有真接关系的。
当我们明白这个定义后，对于计算带宽延迟和精确计算带宽是多少就有了理论依据。其结果就是，在特定条件下，我们只要一个数据包，就可以得出带宽延迟及精确计算出这条线路的带宽。当然，这个数据包最好的满负荷的，也就是1500字节左右。 下面我们通过实例来求证：
偶测试的环境是10M的小区宽带，当前状况下没有其他网络应用，偶通过IE到本地电信最近的一个测试网站，下载一下大文件，同时进行抓包，并进行分析。结果如下：
大家可以看到红色方框中的数据。我们先来给出计算方法： 1. 每个红色方框中的两个数据包的延时，下面的减去上面的，就是这个带宽的延时，也就是串行延迟。比如第二个方框：0.017009-0.015850=0.001159，也就是说，带宽延迟约1MS。大家可以每个都计算下，得出结果的约值是一样的。 2. 当我们计算出传送这个数据包后的时候，通过这个数据包的大小，除以这个延迟，那么就可以得到带宽。还是比如第二个方框：(1438+8+12)*8/0.001159=10063848.144952545297670405522002 =10 M，这个结果相当精确！
相信大家觉得这里面还有一些问题，如下：
1. 这样计算延时，其实里面还包含有其他延时，比如距离延时、交换延时、服务器的响应延时，所以这个值并不精确！
答：OK，这个值确实不精确。但是据有关资料显示，光速是300000公里/S，对于陆地电缆连接来说，延迟大约是200公里/MS，那么从偶所在位置，到本地电信的的距离，而且是光纤到楼的，那么这个延迟会是多少呢？基本上，个人以为，城内到电信的距离延时可以人为不计^-^;另外就是交换延时，现在交换机性能越来越好，更何况到本地电信，也不会有太多交换，那这个值是不是也可以人为不计呢？^-^;倒是服务器响应延时，这个是比较有影响的一个重要因素，必竟就这一块就包含了数据库查寻时间，应用本身响应的延时等，还跟服务器当前硬件负荷有关，所以不可不查！因此，我们在选择数据包时，可以选择连续过来的两个数据包，因为第二个数据块跟第一个数据块已经都同时在服务器的发用队列的缓冲里面，只不过第一个先发，第二个立即接着发送，这样，基本就不用考虑服务器的响应时间了。（这其实是已经可以考虑到的最为精确的了）
2. 带宽可能还会被其他数据暂用，你如何确定这个数据包上没有其他数据？
答：这个就要回到理论，看串行延迟了。所谓串行延迟，就说明数据包是串着发出来的，也就是说，当我们有足够的时间细粒度观察，那么可以发现，线缆上有一个数据包时，就不会有另一个数据包，所以数据包是一个接着一个串着发送过来的。也就是说，一个数据包就可以暂用整个电缆的频率。
