英文:
Stuck with the UNET Stack .nam Trace File
问题
我正在尝试编写自己的Python脚本来计算由UNET Stack计算的统计数据。我已经生成了ALOHA示例文件的.nam跟踪文件，正在编写我的脚本来执行以下操作：
计算接收的数据包
计算入队的数据包（已发送）
计算出队的数据包（已发送）
计算丢弃的数据包
根据手册中的描述（https://unetstack.net/handbook/unet-handbook_discrete_event_simulation.html），我的脚本通过检测跟踪文件中的每一行是否以'r'开头来计算接收的数据包数量。同样，如果一行以'd'开头，我会增加丢弃的数据包计数，以及类似的方式计算入队和出队的数据包。
我的统计数据与UNET Stack为每个模拟显示的数值不匹配。
我不明白错误出在哪里，如果有人能帮助我解决问题，我将不胜感激。
我期望获得类似于在UnetSim中运行ALOHA文件时显示的结果，但是使用上述逻辑我得到了不同的结果。我已经附加了.nam文件，以供查看。
.nam文件 -> https://drive.google.com/file/d/15LilwmV2uTOvDy76Y1ZRG2JR1qPa_0Cs/view?usp=sharing
英文:
I am trying to write my own python script to compute the statistics calculated by UNET Stack. I have generated the.nam trace file for the ALOHA sample file and I am writing my script to do the following:
compute received packets
compute enqueued packets (sent)
compute dequeued packets (sent)
compute dropped packets
using what is written in the handbook (https://unetstack.net/handbook/unet-handbook_discrete_event_simulation.html), my script computes received packets by detecting if the line in the trace starts with 'r' and if it does, I increment my counter. Similarly, if a line starts with 'd', I increment the dropped packet count & similarly for enqueued & dequeued packets as well.
My statistics are not matching with the values shown by UNET Stack for each simulation.
I do not understand where the error lies and I would be very glad if anyone could help me out.
I expect to get a similar output to the results shown when I run the ALOHA file in UnetSim but I receive a different result using the logic stated above. I have attached the .nam file incase anyone wants to check it out.
.nam file -> <https://drive.google.com/file/d/15LilwmV2uTOvDy76Y1ZRG2JR1qPa_0Cs/view?usp=sharing>
答案1
得分: 1
-
你似乎考虑到接收到的帧的数量是传输帧的3倍，即可能忽略了目的地址，因此计数多了？
-
预期结果显示的传输次数比你看到的传输次数要少；也许预期结果的计算时间比日志文件中记录的时间短？我认为跟踪器统计数据在统计期间使用了一个热身期，该期间会忽略传输以进行统计（但它们会被记录）。
英文:
A quick look at the stats brings up two things:
-
You seem to be accounting for receiving 3x the number of frames transmitted, i.e., maybe ignoring the destination address and so triple-counting?
-
The number of transmissions shown in the expected results is smaller than the number of transmissions you see; maybe the time over which the expected results were computed is shorter from the time over which the nam file is logged? I believe the tracer stats use a warm-up period during which transmissions are ignored for stats (but they'll be logged).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论