Processing delay

[noel.fa...@gmail.com]

Hi All,

I have a simple PointToPoint link between two nodes and I am transmitting 13 bytes of data using a UDP socket.

The PointToPoint link has a data rate of 0.25Mbps and a delay of 0ms. Using PCAP tracing I determined that the

total packet size is equal to 33 bytes (13 bytes data + 30 bytes header). I am using the PointToPointHelper to

create the necessary links.

Doing a quick calculation using the 0.25Mbps value I determined that to transmit 33 bytes, 1,056,000ns are required.

However, the destination was receiving the packet at 1,376,000ns; a difference of 0.32ms.

Is this delay due to some processing delay introduced by ns-3? If so, how can I turn it off so that I get "instant"

reception?

Thanks a lot for your time.

Kind Regards,

Noel

[Tommaso Pecorella]

Hi Noel,

mind to send the script so we can check it ?

Cheers,

T.

[noel.fa...@gmail.com]

Hi Tommaso,

It's quite a long and complex script, because I'm using external libraries for encoding and decoding, so it might take you some time to understand it.

Do you think it would be better if I create a simpler working example and attach that instead?

Cheers,

Noel

[Tommaso Pecorella]

Hi,

the shorter and simpler, the better.

Cheers,

T.

[noel.fa...@gmail.com]

Hi,

I've attached the script. Basically what I'm trying to do is build a line topology and forward one packet from one node to the next.

The current simulation file will only transmits one packet which is enough to get the desired output.

To build this you can just copy the attached folder in the examples directory and it should work fine :).

Thanks a lot for your time and help.

Cheers,

Noel

[Tommaso Pecorella]

Hi,

I'm sorry but I can't use KODO on my Mac.
My best suggestion is to enable the PointToPoint logs and look for a line like this:

  Schedule TransmitCompleteEvent in xxxx sec

The time is calculated in PointToPointNetDevice::TransmitStart. You can also add more debug output there to double check the packet length. Most probably it's slightly longer than expected.

Cheers,

T.

[noel.fa...@gmail.com]

Hi,

I'll do that. Thank you very much for your help :-).

Cheers,

Noel