关于无线网桥是否可以用于实时传输的探讨

guko

300M AR9344 芯片  无线网桥。
# y( g( D; y$ v2 E0 R一端设定为ap模式，一端设定为客户端模式（即站点模式）。64字节的报文从ap端发送到客户端时的延时要小于从客户端发送到ap端的延时。
报文的发送与接受是通过FPGA直接控制phy芯片来实现的---即FPGA控制以太网口通过有线分别连接到两个无线模块。
8 a! {9 `9 ]5 a3 ]9 L经过多次实验发现一个奇怪的问题----当我发送IP单播时的数据包延时更小，而发送广播时的数据包延时更大。广播时应该是没有ACK的了吧？
这样就一直发数据包的话不是应该延时更小么？
我试过发纯以太包即把帧类型改为oXFFFF，这样不管物理地址是单播还是广播其延时都不及发送IP包的情况（即把帧类型改为oX0800）
其实本人最核心的想法是：牺牲带宽换取实时性。
根据如下：现在的11.n或者11.ac都是号称300M到1000M的带宽，我们知道无线传输很容易受干扰，重传比较多，这可能就让数据的传输时延收到影响，
5 F5 _# W- X  M/ k. g  M我若不让数据包重传，让数据包的每次传输都把相邻前几个包封装在当前包中一起传输，这样增加了传送包的长度（相邻包传送了重复内容，），
而不让数据包重传，或者减少数据包的重传，一句话来总结就是借增加发送数据包的长度来减少发送数据包的次数，以此达到数据包的实时传输。
最后再附上本人测试的相关数据包延时记录： 有兴趣的可以加好友讨论相关技术的可行性！  
! |3 ?4 B1 }2 N: X' V1 z$ r

发送帧长	发送速率	发送模式	延时	占百分比
64bye	4000/S	以太广播	0-0.25ms	0	0	0
		IP广播	0.25-0.5	0	0	0
丢包十个左右		持续250S	0.5-0.75	0.0026	0.0031	0.0027
		AP-客户	0.75-1.0	5.6353	6.3383	6.422
			1.0-1.25	61.7558	70.7629	70.6974
			1.25-1.5	19.7271	19.1256	19.0386
			1.5-1.75	5.7256	2.241	2.2393
			1.75-2.0	3.7134	1.1032	1.1338
			2.0-2.0+	1.1182	0.4	0.3526
64bye	4000/S	以太单播	0-0.25ms	0	0	0
		IP广播	0.25-0.5	47.2807	47.2649	47.2821
无丢包		持续250S	0.5-0.75	50.2889	50.2776	50.2716
		AP-客户	0.75-1.0	1.7922	1.8164	1.7951
			1.0-1.25	0.4519	0.4539	0.4559
			1.25-1.5	0.1701	0.172	0.1711
			1.5-1.75	0.0119	0.0113	0.0114
			1.75-2.0	0.0008	0.0006	0.0012
			2.0-2.0+	0.0002	0	0.0084
64bye	4000/S	以太单播	0-0.25ms	0
		IP广播	0.25-0.5	0.4002
		持续250S	0.5-0.75	8.8019
		客户-AP	0.75-1.0	12.0882
			1.0-1.25	11.6799
			1.25-1.5	10.8364
			1.5-1.75	10.3553
			1.75-2.0	9.9199
			2.0-2.25	9.6422
			2.25-2.50	3.769
			2.5-2.5+	22.5043

2 w: P! b& w1 d- W4 w
4 M* f. T0 H  r$ O( l* R

ChowLiang

抢沙发。
静候大伙发帖，
笨人认真学习。

guko

这个没人感兴趣么？