关于无线网桥是否可以用于实时传输的探讨
300M AR9344 芯片无线网桥。一端设定为ap模式，一端设定为客户端模式（即站点模式）。64字节的报文从ap端发送到客户端时的延时要小于从客户端发送到ap端的延时。
报文的发送与接受是通过FPGA直接控制phy芯片来实现的---即FPGA控制以太网口通过有线分别连接到两个无线模块。
经过多次实验发现一个奇怪的问题----当我发送IP单播时的数据包延时更小，而发送广播时的数据包延时更大。广播时应该是没有ACK的了吧？
这样就一直发数据包的话不是应该延时更小么？
我试过发纯以太包即把帧类型改为oXFFFF，这样不管物理地址是单播还是广播其延时都不及发送IP包的情况（即把帧类型改为oX0800）
其实本人最核心的想法是：牺牲带宽换取实时性。
根据如下：现在的11.n或者11.ac都是号称300M到1000M的带宽，我们知道无线传输很容易受干扰，重传比较多，这可能就让数据的传输时延收到影响，
我若不让数据包重传，让数据包的每次传输都把相邻前几个包封装在当前包中一起传输，这样增加了传送包的长度（相邻包传送了重复内容，），
而不让数据包重传，或者减少数据包的重传，一句话来总结就是借增加发送数据包的长度来减少发送数据包的次数，以此达到数据包的实时传输。
最后再附上本人测试的相关数据包延时记录： 有兴趣的可以加好友讨论相关技术的可行性！
发送帧长发送速率发送模式延时占百分比
64bye4000/S以太广播0-0.25ms000
IP广播0.25-0.5000
丢包十个左右持续250S0.5-0.750.00260.00310.0027
AP-客户0.75-1.05.63536.33836.422
1.0-1.2561.755870.762970.6974
1.25-1.519.727119.125619.0386
1.5-1.755.72562.2412.2393
1.75-2.03.71341.10321.1338
2.0-2.0+1.11820.40.3526
64bye4000/S以太单播0-0.25ms000
IP广播0.25-0.547.280747.264947.2821
无丢包持续250S0.5-0.7550.288950.277650.2716
AP-客户0.75-1.01.79221.81641.7951
1.0-1.250.45190.45390.4559
1.25-1.50.17010.1720.1711
1.5-1.750.01190.01130.0114
1.75-2.00.00080.00060.0012
2.0-2.0+0.000200.0084
64bye4000/S以太单播0-0.25ms0
IP广播0.25-0.50.4002
持续250S0.5-0.758.8019
客户-AP0.75-1.012.0882
1.0-1.2511.6799
1.25-1.510.8364
1.5-1.7510.3553
1.75-2.09.9199
2.0-2.259.6422
2.25-2.503.769
2.5-2.5+22.5043
抢沙发。
静候大伙发帖，{:5_242:}
笨人认真学习。{:5_238:} 这个没人感兴趣么？
页:
[1]