1

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

my output expected result

tim_yates
  • 167,322
  • 27
  • 342
  • 338
Uday
  • 11
  • 2

1 Answers1

1

A quick look at the stats brings up two things:

  1. You seem to be accounting for receiving 3x the number of frames transmitted, i.e., maybe ignoring the destination address and so triple-counting?

  2. 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).

Mandar Chitre
  • 2,110
  • 6
  • 14
  • 1) I understand. So I need to modify the code to ensure that I do not double count? Will adding a check for destination address & packet ID be the correct way? Because after doing that, I am getting 569 packets instead of the 506 mentioned. 2) So for that, do I need to work simultaneously with the log file? How do I account for this warm-up period in my own calculations? – Uday Apr 13 '23 at 09:23
  • Yes, filter on destination address. Also ignore the packets that were transmitted during the warm-up period (settable in Tracer, but defaults to 15 mins iirc). – Mandar Chitre Apr 14 '23 at 10:26
  • I understand sir. After making the necessary changes, I have arrived at the following stats for 2 simulations: [sim1 stats by unet stack](https://imgur.com/a/tDe7kys) [my stats for sim1](https://imgur.com/0odf3NB) [my stats for sim2](https://imgur.com/oRSu2zD) [sim2 stats by unet stack](https://imgur.com/DaLhWQK) There is still an error in the dropped packet count which gets more enhanced as the number of packets increase. I was wondering if it's because we are considering the dropped packets which were created before the warm-up time? – Uday Apr 17 '23 at 06:16
  • The effect of warm-up should be smaller when you increase the duration of the simulation. – Mandar Chitre Apr 18 '23 at 08:06