opnet之csma_2node事件列表
2017-01-05 17:32
197 查看
csma_2node模型链接
lmz:
仿真时间在gen模块发包(随机时间)和tx模块结束发送时推进(推进1秒)。
包在总线上传播不花费时间。
lmz:
发包时间设置为均值为5的指数分布。
如果设置为常数,则每个包都生碰撞,收集不到统计量!
lmz:
第一次发包都在10s
下一次发包的时间才是随机函数
第一次发包永远存在碰撞,除非修改第一次发包时间
begin sim intrpt的产生者是仿真核心。
仿真开始中断产生后立即被目的进程接收,进入状态机的init状态,执行入口相关代码。
如果init是强制状态,接着就会执行出口代码。
接着跳转到下一个状态,执行其入口代码。
下一个状态一般都是非强制状态,所以停滞,等待下一个事件的发生。
代码的执行不消耗仿真时间。
node_0的gen
node_0的tx_proc
node_0的sink
node_1的gen
node_1的tx_proc
node_1的sink
node_2的rx_proc
node_0的模块gen开始发包(自中断)
node_1的模块gen开始发包(自中断)
node_0的模块tx_proc接收包(流中断)
node_1的模块tx_proc接收包(流中断)
node_0的模块bus_tx接收包(流中断)
node_1的模块bus_tx接收包(流中断)
lmz:
仿真时间并没有推进。
个人觉得一切的中断本质上都类似自中断或者远程中断。
这两个中断设置中断事件。
因为通过包流链接,其中断的到达不花费时间,所以仿真时间不推进。
发射机接收包后会发射包,每一个接收机发射包后会在此场景下的每一个接收机设置一个远程中断。
图为node_0的发射机为node_0、node_1、node_2的接收机预设了远程中断。仿真时间不推进。
图为node_1的发射机为node_0、node_1、node_2的接收机预设了远程中断。仿真时间不推进。
由下图可以看出,两个节点的发射机同时发送了第一个包,且同时监听到信道繁忙。
两个包会碰撞,不会被node_2接收。
包的大小是1024比特,发包是1024比特/秒。
所以在10+1时包发送数据结束。
node_0结束发射中断。
node_1结束发射中断。
node_1发射结束会在node_0、node_1、node_2节点的接收机产生接收结束中断。
lmz:
下一个事件是什么?
包在总线上传输需要时间,下一个事件的仿真时间会推进。
因为node_0与node_1同时发包,数据包在链路上碰撞,所以包不会进入node_2的接收机,便不会再node_2的rx_proc模块产生流中断。
下一个事件应该是重新发包!!!
lmz:
此时下一个事件才是发包!!!!!
而且仿真时间推进!!!!!
lmz:
下一个事件应该是数据中断!!!
lmz:
下一个事件应该是node_1的发射机结束传输中断!!!
而且仿真时间推进1秒!!!!!
lmz:
紧接着就是三个节点的接收机的结束接收中断!!!
lmz:
因为只有一个节点发包,所以node_2可以成功接收数据包。
所以下一个事件是node_2的rx_proc的流中断!!!
仿真时间推进!!!!!
同时产生数据中断,因为信道又空闲!!!
lmz:
下一个事件node_2接受包!!!
lmz:
下一个事件是重新发包!!!!!
仿真时间推进!!!!!
事件64后面有点奇怪!!!
tags:opnet
lmz:
仿真时间在gen模块发包(随机时间)和tx模块结束发送时推进(推进1秒)。
包在总线上传播不花费时间。
lmz:
发包时间设置为均值为5的指数分布。
如果设置为常数,则每个包都生碰撞,收集不到统计量!
lmz:
第一次发包都在10s
下一次发包的时间才是随机函数
第一次发包永远存在碰撞,除非修改第一次发包时间
begin sim intrpt
每一个事件,也即是中断都有产生者与接收者。begin sim intrpt的产生者是仿真核心。
仿真开始中断产生后立即被目的进程接收,进入状态机的init状态,执行入口相关代码。
如果init是强制状态,接着就会执行出口代码。
接着跳转到下一个状态,执行其入口代码。
下一个状态一般都是非强制状态,所以停滞,等待下一个事件的发生。
代码的执行不消耗仿真时间。
仿真时间
0时刻,有7个仿真开始中断
图略。node_0的gen
node_0的tx_proc
node_0的sink
node_1的gen
node_1的tx_proc
node_1的sink
node_2的rx_proc
10时刻,开始发包
图略。node_0的模块gen开始发包(自中断)
node_1的模块gen开始发包(自中断)
node_0的模块tx_proc接收包(流中断)
node_1的模块tx_proc接收包(流中断)
node_0的模块bus_tx接收包(流中断)
node_1的模块bus_tx接收包(流中断)
lmz:
仿真时间并没有推进。
个人觉得一切的中断本质上都类似自中断或者远程中断。
这两个中断设置中断事件。
因为通过包流链接,其中断的到达不花费时间,所以仿真时间不推进。
tx为每一个rx设置了远程中断
最关键的来了:发射机接收包后会发射包,每一个接收机发射包后会在此场景下的每一个接收机设置一个远程中断。
图为node_0的发射机为node_0、node_1、node_2的接收机预设了远程中断。仿真时间不推进。
图为node_1的发射机为node_0、node_1、node_2的接收机预设了远程中断。仿真时间不推进。
信道忙(两次数据中断,可能跟进程有关系)
因为发射机已经发包,所以信道忙,此时产生数据中断。仿真时间不推进。由下图可以看出,两个节点的发射机同时发送了第一个包,且同时监听到信道繁忙。
两个包会碰撞,不会被node_2接收。
tx结束发包的自中断
发射机发设包需要时间。包的大小是1024比特,发包是1024比特/秒。
所以在10+1时包发送数据结束。
node_0结束发射中断。
rx结束收包远程中断
node_0发射结束会在node_0、node_1、node_2节点的接收机产生接收结束中断。node_1结束发射中断。
node_1发射结束会在node_0、node_1、node_2节点的接收机产生接收结束中断。
lmz:
下一个事件是什么?
包在总线上传输需要时间,下一个事件的仿真时间会推进。
因为node_0与node_1同时发包,数据包在链路上碰撞,所以包不会进入node_2的接收机,便不会再node_2的rx_proc模块产生流中断。
下一个事件应该是重新发包!!!
数据中断
预测错了,下一个事件是数据中断。因为结束发包,所以链路空闲,两个节点会产生数据中断。lmz:
此时下一个事件才是发包!!!!!
而且仿真时间推进!!!!!
再次发包
因为发包时间是随机函数,此时是node_1发包。三个rx处远程中断
紧接着node_1的发射机会在三个节点的接收机处产生远程中断。lmz:
下一个事件应该是数据中断!!!
数据中断
node_0与node_1产生数据中断。lmz:
下一个事件应该是node_1的发射机结束传输中断!!!
而且仿真时间推进1秒!!!!!
tx结束发包
lmz:
紧接着就是三个节点的接收机的结束接收中断!!!
三个rx结束收包
lmz:
因为只有一个节点发包,所以node_2可以成功接收数据包。
所以下一个事件是node_2的rx_proc的流中断!!!
仿真时间推进!!!!!
node_0和node_1的sink收包
忽略了node_0与node_1的sink模块也可以接收数据包!!!!!同时产生数据中断,因为信道又空闲!!!
lmz:
下一个事件node_2接受包!!!
node_2的rx_proc收包
lmz:
下一个事件是重新发包!!!!!
仿真时间推进!!!!!
再次发包
node_0发包。事件64后面有点奇怪!!!
仿真结束
40s时是结束中断!tags:opnet
相关文章推荐
- opnet之事件列表
- SP2010开发和VS2010专家"食谱"--第一章节--列表和事件接收器(5)--添加Application Page到事件接收器
- SP2010开发和VS2010专家"食谱"--第一章节--列表和事件Receiver(9)--调试Feature Receiver
- js代码触发事件 函数列表
- CListCtrl控件主要事件及LVN_ITEMCHANGED消息和鼠标双击列表项事件的处理
- wxPython 键盘事件列表
- 利用RecycleView实现类似ListView的Item点击,长按等操作事件以及点击后每一项在添加一个列表
- javascript 触发事件列表
- opnet核心函数-事件类
- Android实现RecyclerView自定义列表、点击事件以及下拉刷新
- javascript事件列表解说
- documentsUI下载列表点击事件流程
- Oracle诊断事件列表
- javascript 触发事件列表
- Javascript事件列表
- 使用ContentObserver监听事件变化并及时刷新列表效果
- CListCtrl控件主要事件及LVN_ITEMCHANGED消息和鼠标双击列表项事件的处理
- Extjs4.1:由json数据生成icon列表并对单击事件弹出提示
- javascript事件列表解说(转)
- Android Studio 实现下拉列表刷新并嵌套轮播图(自动轮播+手动轮播+点击事件)