Hello, your description is kind of vague, could you provide more technical details?

- When you say "I've tried making the default time units to seconds, but a segmentation fault core dump results."

Did you mean a call to:  void ns3::Time::SetResolution ( enum Unit resolution )? or did you try to mess with the internals of the Time class somehow?

The first (SetResolution) should be the proper way to go.

- When you say "Ive also tried manually convertion to seconds, but the internal variable changes before this."

I assume that you have been trying to change the FlowStats struct variables in the ns3::FlowMonitor class? What do you mean by a manual conversion? Changing the (Time::m_data) value?

Sir! Thanks a lot for your response to my query.

Let me clarify my query.  I have tried out Time::SetResolution (Time::S);  When the Simulator::Run() function is executed, it gives me a floating point core dumped error.  Sorry that I have mentioned it as segmentation fault.

The second trial was,

Delay=(i->second.timeLastRxPacket.GetSeconds()-i->second.timeFirstTxPacket.GetSeconds());

Delaysum=i->second.delaySum;

JitterSum=i->second.jitterSum;

i being the iterator of the flow monitor.

 The following results are encountered.

Delay:162.002 Delaysum=+2795592540.0ns JitterSum=+1021274024.0ns

For the next flow

Delay:178.924 Delaysum=+1023489076.0ns JitterSum=+1017200020.0ns

For the next flow

Delay:0.00773556 Delaysum=+7735558.0ns JitterSum=+0.0ns

Similarly it reduces towards zero and then to negative values.

Can you suggest me to overcome this? 

Thank you again for your response!

Hello,

In normal working conditions using Time::SetResolution (Time::S); should not result in a crash. I'm more inclined to think that some non-related changes in your code may be producing it. Although without seeing any actual code I can only guess...

Here is a working example that uses flowmonitor with several different time resolutions: http://pastebin.com/BCGRKt1v

In regards of your manual computation of the delay :

i->second.timeLastRxPacket.GetSeconds()-i->second.timeFirstTxPacket.GetSeconds();

should be equal to:

i->second.delaySum;

And from your pasted results this is only true for the third flow, which is weird.

I would suggest to check if the packets are being properly tracked. What kind of tranmission mechanism are you using? are you broadcasting? (flowmonitor does not classify broadcast messages). I would examine the characteristics of the flows (number of transmitted packets, origin, destination, losses) and adjust your computation accordingly.

Without seeing any code this is pretty much all the suggestions I can provide.

Thanks for your time and response sir.  I am using this transmission currently to unicast video.  I'll try with the code sample (pastebin) and get back to you Sir.