《关于各种长度的以太包在MSTP电路中传输效率的分 析》由会员分享，可在线阅读，更多相关《关于各种长度的以太包在MSTP电路中传输效率的分 析（8页珍藏版）》请在金锄头文库上搜索。
1、关于各种长度的以太包在 MSTP 电路中传输效率的分析本文主要说明各种长度的以太包在 MSTP 电路中传输效率的高低，以及计算出哪种长度的以太包的传输效率是最优。一、SDH容器带宽说明：（表一）2 23 39 96 61 16 60 02 24 40 05 53 37 76 6V VCC- -4 4- -1 16 6c c5 59 99 90 04 40 06 60 01 13 30 04 4V VCC- -4 4- -4 4c c1 14 49 97 76 60 01 15 50 03 33 36 6V VCC4 44 48 83 38 84 44 48 89 96 60 0V VCC3 3
2、2 21 17 76 62 22 24 40 0V VCC1 12 22 20 04 48 82 20 04 48 8E E1 1容容器器净净负负荷荷带带宽宽( (k kb bp ps s) )容容器器带带宽宽( (k kb bp ps s) )容容器器类类型型2 23 39 96 61 16 60 02 24 40 05 53 37 76 6V VCC- -4 4- -1 16 6c c5 59 99 90 04 40 06 60 01 13 30 04 4V VCC- -4 4- -4 4c c1 14 49 97 76 60 01 15 50 03 33 36 6V VCC4 44 48
3、 83 38 84 44 48 89 96 60 0V VCC3 32 21 17 76 62 22 24 40 0V VCC1 12 22 20 04 48 82 20 04 48 8E E1 1容容器器净净负负荷荷带带宽宽( (k kb bp ps s) )容容器器带带宽宽( (k kb bp ps s) )容容器器类类型型注：只有老的ET1单板才是按照E1来承载的，OSN系列产品都是按照VC12或更高的容器承载，实际上传输侧所分的带宽一个VC12多余2Mbps二、协议介绍1、GFP封装协议GFP Core Header为4bytes，Playload Header为4bytes，CRC为
4、4bytes，所以GFP的封装开销正常为12bytes，当不使用CRC时，封装开销为8bytes。（GFP帧通过字节间插复用到相应的虚级联成员中）2、LAPS封装协议LAPS封装中，封装开销为9bytes，带4字节的CRC。3、ML-PPP封装协议对于ET1（V1&V2）系列单板，采用了ML-PPP封装，开销为6*L/64（L为包长）字节。（ET1的帧的处理过程和EFGS单板存在差异，主要表现在ML-PPP封装协议需要对封装的数据按照64字节进行切片，最终数据放入的容器是E1，非VC12。）这里的一个核心思路是，MAC帧在接口速率100Mbps的情况下，存在包间隙、前导码、帧定界等开销，进入以
5、太网单板后，原来的开销没有了，增加了EOS的封装开销，且封装开销一般都小于网口的开销。三、帧结构示意帧结构示意图：（图一）四、计算网络层净负荷的速度1、如何计算网络层净负荷的速度根据上面的内容，我们就可以计算出以太网单板在绑定某一个VCG通道情况下，理论上的吞吐量是多少。下面以MAC帧为64字节，VCG为绑定1个VC12（1个2M）的情况为例，相应的最大帧转发速率为：2176K/(64+4+12)/8=3400帧/秒（FPS） 2176K为上表一中所提供的带宽值其中，4Byte为数据帧处理部分增加的VLAN，12Byte为EOS部分增加的GFP封装。其中1个VC12中，真正传送的用户业务为34
6、00*64*8=1741Kbps，VCG带宽利用率为：1741K/2176K=80%或64/(64+4+12)=80%在1000Mbps以太网接口中，最大的64字节帧转发速率为148810帧/秒，吞吐量常用的表示方法是实际的帧转发速率与该接口下最高帧的转发速率的比值，所以吞吐量的理论值是3400/148810=2.28%。另外当EFGS单板在EPL业务下、GFP封装，SDH侧提供的容器带宽大于148810*(64+4+12)*8=95.24Mbps时，64字节的吞吐量测试结果就应该在100%，类似，对应512字节的吞吐量。如果提供打带宽大于23496（512+4+12）=99.25Mbps时，
7、该字节的吞吐量测试结果就是100%，对于1518字节，需要提供8127*(1518+4+12)=99.73Mbps带宽，吞吐量测试结果就是100%、理论情况下，提供46个VC12即可使所有字节的吞吐量测试结果为100%。五、计算如何计算各种长度的以太包，在同一带宽下的传输速率：在(绑1个VC12的实测值，可作为参考）的每秒帧率代入公式（容器带宽K/(包长+4+12)/8=XX帧/秒（FPS）就可以求出理论传送值，比如:1518的MAC帧长计算出来就是1518*180（上面公式计算得出）*8=2185920bps1280的MAC帧长计算出来就是1280*213（上面公式计算得出）*8=21811
8、20bps1024的MAC帧长计算出来就是1024*269（上面公式计算得出）*8=2203648bps512的MAC帧长计算出来就是512*528（上面公式计算得出）*8=2162688bps256的MAC帧长计算出来就是256*1019（上面公式计算得出）*8=2086912bps128的MAC帧长计算出来就是128*1926（上面公式计算得出）*8=1972224bps64的MAC帧长计算出来就是64*3400（上面公式计算得出）*8=1740344bps从以上计算中可以看出理论值：64 字节的包长传输速率最低，VCG 带宽利用率为 1740/2176=80%1024 字节的包长传输速率
9、最高，VCG 带宽利用率为 2204/2176100%案例分析：案例一 速率慢两台 2500设备点对点组链型网，在每个站点都配置了 EFS 单板，每个单板绑定了两个 VC3 的带宽，配置的 EPL 业务。业务配置完毕后测试业务是通的，但是使用两台电脑进行 FTP 速率只有 8M 左右，和所绑定的带宽相差很大。EFS 单板配置了两个 VC3 的带宽，但是使用两台电脑进行 FTP 大概只有 8M 速率。1、单板故障2、数据特性测试步骤1、使用两台电脑直接相连进行 FTP,发现最大速率也大概为 8M 左右。2、将 EFS 单板绑定的带宽由两个 VC3 改为 5 个 2M，进行 FTP，发现还是 8M
10、 左右，说明我们的单板已经发挥了最大作用。3、为什么直接进行 FTP 速率比较慢呢？经过查找资料发现：FTP 采用 TCP 方式进行传输，即需要在传输一定量的数据包后，需要对端发送一个响应，才进行下一次的数据传输。也就是常说的滑动窗口协议，对于不同的软件，滑动窗口协议细节上并不相同。因此，通过计算链路延时和软件的响应时间，还有电脑的硬件原因。得出结论两台电脑直接 FTP 大概就在 8M 左右，因此通过我们设备进行 FTP 速率比较低的原因是由于FTP 软件本身和电脑的问题，并不是设备处理问题。4、正确的测试方法：使用专业的测试仪表比如 smartbits 600，在没有仪表的情况下，可以采用开
11、启多服务器端和多客户端同时进行数据下载，将传送速率求和，充分利用空闲带宽进行传送，得出一个总的极限值（考虑到计算机的处理能力，在网络传输速率较大的情况下，尤其是网卡到硬盘的传输速率是一个瓶颈）案例二：用户以太网设备通过 ET1 板透传的速率问题现象描述1、两个 Metro1000 设备组成点对点，开 100M 快速以太网业务，捆绑全部 48 个2M，IP 口之间的带宽为 96Mbit/S。2、中间距离很长，约 1200 公里，经过多个设备，包括我司的几个 2500+设备，N公司的多个波分设备，还有 Z 公司的几个 SDH 设备。3、业务开起来之后，因一端的以太网交换机没有装，无法进行实际的业务
12、测试，应用户要求在两端用服务器进行 ping 包和文件传输测试。4、测试中发现，ping 包的回应时间为 26ms 左右，而用 ftp 进行文件传输速度最高值只有 1.3Mbyte/s 左右，而在本地两台类似配置的服务器直接互连速率能够达到10Mbyte/s；同时两端分别进行 ftp 的速率不一样，另一端只有 800kbyte/s 左右，用户要求解释。【告警信息】由于中间有 Z 公司的 SDH 设备，对接时出现 HP-TIM 和 HP-SLM 告警，但对端设备对此不进行处理，我司 155/622H 设备也不进行处理，故告警无影响，业务能通。【原因分析】1、经过对 ftp 的传输机制，实际的传输
13、距离和 ping 包时延的分析，造成该现象的可能原因如下：用 ftp 进行传输时，根据 TCP 协议的传输机制，发送端按一定的速率向接收端发包，接收端在接收到一定数量的包后，会向发送端发一个回应帧，而发送端只有在接收到这个回应帧后，才会继续发出下一个包；至于接收端在接收多少包后才会发回应帧给发送端，具体的数量是根据实际情况变化的，这就是所谓的 TCP 简单确认及滑动窗口机制。2、这样，当传输距离很长，数据传输的时延很大的时候，发送端会花很多的时间在等待回应帧的到来，这样每一个 ftp 进程会表现为的速率很慢。同时，不同的以太网设备，特别是计算机的网卡，对 ET1 板的适配程度不同，所以不同的计
14、算机测试的结果也不一致，有可能还差别较大。【处理过程】1、刚开始测试的时候，ping 包的时延为 26ms 左右，单个 ftp 进程速率最高为1.3Mbyte/s 左右，而在本地用两台近似配置的服务器直联测试，时延为 1ms，最高速率可以达到 10Mbyte/s；按照 ET1 板标准的 80的吞吐量计算，捆绑 48 个 2M的理想速率应该是 10Mbyte/s 左右；于是怀疑是两边设备的端口适配不好，但是查询传输性能和以太网性能，误码、丢包和流控帧都没有；尝试更改端口属性，但所有的组合都没有更好的结果。2、更改捆绑 2M 的数量，发现一个奇怪的现象，绑 10 个 2M 和 48 个 2M，ft
15、p 的速率没有变化。3、怀疑 ET1 指标板指标不好，申请 SmartBit 仪表进行现场测试，测试结果吞吐量、丢包率和时延都是合格的；将测试结果拿给用户看，用户表示不能完全接收，表示不管指标如何，实际速率就是慢，还是要求解决。4、查看组网情况，因为中间经过的设备较多，怀疑是对接对此有影响，波分对于SDH 是透传，所以估计波分的问题不大；全程最后有一段 300 公里走的是 Z 公司的SDH 设备，怀疑与其对接有问题，拿一台新的 Metro1000 设备到与 Z 公司设备对接的现场，甩开他们的设备，只用我们的进行测试，结果速率稍微比原来好一些，多了200kbyte/s，这样看，也不是对接的问题。
16、5、但从上面的测试结果看，距离缩短了一些，速率就上来一些；咨询相关人员和查看TCP/IP 的传输原理文档，初步判断为传输距离过长，造成时延过大，所以单个 ftp 的速率变慢；刚好中间走的 SDH 和波分设备是成环的，有另外一段路由，这一段路由距离比原来使用的要短，于是尝试将中间的 SDH 业务配置更改为新的路由；这时候ping 包测试时延为 15ms 左右，用 ftp 传输最高速率达到 3.6Mbyte/s 左右；这时候向用户解释时延的原因和 TCP 协议的传输机制，用户在一定程度上可以接受。6、但用户随后在一端的服务器上安装软件；安装完后再测试，速率又变为 1Mbyte/s左右，这种情况下，怎么也找不到速率突然下降原因；只好让用户重新安装系统，装好后再测试，速率又恢复到 3.6Mbyte/s 左右，这样看，计算机的系统问题也会大大的影响测试的结果。7、为进一步说服用户，在两边的 Metro1000 设备上都接上以太网交换机，各用 4 台高性能的服务器同时进行多个 ftp 文件传输，每一台服务器的速率都不一样，但都能达到 2Mbyte/s 左右；这时候从 ET1 板的性能数据
