Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

avgDelay is -1 #8

Open
Magnido9 opened this issue Sep 29, 2023 · 4 comments
Open

avgDelay is -1 #8

Magnido9 opened this issue Sep 29, 2023 · 4 comments

Comments

@Magnido9
Copy link

Hello,
we are using this api in our project , and we noticed that some flows in high bandwidth demands get a delay of -1 for some reason,
could you by any chance explain to us why this is happening?
thanks :D

@albert-lopez
Copy link
Contributor

Hello,
This could happen when no packet has reached its destination . Or no packets have been generated for the affected path or all of them have been lost. It could happen specially if you are using Strict Priority scheduling policies.
Regards
Albert

@Magnido9
Copy link
Author

Magnido9 commented Oct 2, 2023

Hello, This could happen when no packet has reached its destination . Or no packets have been generated for the affected path or all of them have been lost. It could happen specially if you are using Strict Priority scheduling policies. Regards Albert

Hi Albert, thank you for your quick response, we checked and for the flows that have -1 delay most packets were lost but not all of them(we calculated it's always 99.8% loss or higher but not 100%), do you by any chance know why it happens then?

@albert-lopez
Copy link
Contributor

Not really, It would be possible to have the data used to generate this sample? The Network_topology.ned, routing.txt and traffic.txt in order to try to reproduce the problem? The API only reads the data generated with the simulator so the problem should come from the simulator.

@albert-lopez
Copy link
Contributor

I have observed a particular behavior in our simulation. Specifically, at the conclusion of a simulation, packets that reside within the queue of devices are indeed removed, but they are not dropped. I'm considering the possibility that the disparity between the number of packets generated and the number of packets dropped may be less than the number of packets present in the buffers of the devices along the path. If this is the case, it could explain the 0.2% discrepancy we're observing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants