Bug 1766 - throughput calculation based on wrong durations
throughput calculation based on wrong durations
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: examples
ns-3.18
PC Linux
: P5 trivial
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-30 14:24 UTC by jrinas
Modified: 2014-03-03 22:20 UTC (History)
2 users (show)

See Also:


Attachments
patch to fix (1.15 KB, patch)
2013-09-30 14:24 UTC, jrinas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description jrinas 2013-09-30 14:24:25 UTC
Created attachment 1675 [details]
patch to fix

The throughput calculation the duration should be adjusted from 10 to 9 seconds,
since the StartTime of the OnOffApplication is at about "second 1"
  and 
Simulator::Stops at "second 10".
Comment 1 Tom Henderson 2013-10-01 00:17:50 UTC
I agree with the patch, but I wonder about the output of this example:

Hidden station experiment with RTS/CTS disabled:
Flow 1 (10.0.0.1 -> 10.0.0.2)
  Tx Bytes:   3847500
  Rx Bytes:   356136
  Throughput: 0.284909 Mbps
Flow 2 (10.0.0.3 -> 10.0.0.2)
  Tx Bytes:   3848412
  Rx Bytes:   303468
  Throughput: 0.242774 Mbps
------------------------------------------------
Hidden station experiment with RTS/CTS enabled:
Flow 1 (10.0.0.1 -> 10.0.0.2)
  Tx Bytes:   3847500
  Rx Bytes:   296400
  Throughput: 0.23712 Mbps
Flow 2 (10.0.0.3 -> 10.0.0.2)
  Tx Bytes:   3848412
  Rx Bytes:   277020
  Throughput: 0.221616 Mbps

In what sense is RTS/CTS improving things (as the example suggests that it should)?

Also, I enabled pcap to look at what was being observed for UDP receptions on node 1.  In the basic case from node 10.0.0.1 (first one above) I count 1300 UDP datagrams of 200 bytes each.   1300*200*8/10 = 0.208 Mb/s.  Even if I account for UDP/IP header, I would expect 1300*228*8/10 = 0.237 Mb/s.  So perhaps the flow monitor count needs to be checked here also.
Comment 2 jrinas 2013-10-01 02:11:55 UTC
(In reply to comment #1)
> I agree with the patch, but I wonder about the output of this example:
> 
> Hidden station experiment with RTS/CTS disabled:
> Flow 1 (10.0.0.1 -> 10.0.0.2)
>   Tx Bytes:   3847500
>   Rx Bytes:   356136
>   Throughput: 0.284909 Mbps
> Flow 2 (10.0.0.3 -> 10.0.0.2)
>   Tx Bytes:   3848412
>   Rx Bytes:   303468
>   Throughput: 0.242774 Mbps
> ------------------------------------------------
> Hidden station experiment with RTS/CTS enabled:
> Flow 1 (10.0.0.1 -> 10.0.0.2)
>   Tx Bytes:   3847500
>   Rx Bytes:   296400
>   Throughput: 0.23712 Mbps
> Flow 2 (10.0.0.3 -> 10.0.0.2)
>   Tx Bytes:   3848412
>   Rx Bytes:   277020
>   Throughput: 0.221616 Mbps
> 
> In what sense is RTS/CTS improving things (as the example suggests that it
> should)?
To see a significant improvement, please increase the PacketSize (line 102)
from 200 bytes to something much larger (1400 worked for me).
The reason seems to bee: overhead vs. improvement due to the RTS/CTS handshake pushed the results in the other direction.


with the following changes wrt. ns-3.18:
a.) applied patch wireless_wifi-hidden-terminal_duration.diff
b.) PacketSize to 1400
I get the results:

Hidden station experiment with RTS/CTS disabled:
Flow 1 (10.0.0.1 -> 10.0.0.2)
  Tx Bytes:   3441480
  Rx Bytes:   302736
  Throughput: 0.269099 Mbps
Flow 2 (10.0.0.3 -> 10.0.0.2)
  Tx Bytes:   3442908
  Rx Bytes:   355572
  Throughput: 0.316064 Mbps
------------------------------------------------
Hidden station experiment with RTS/CTS enabled:
Flow 1 (10.0.0.1 -> 10.0.0.2)
  Tx Bytes:   3441480
  Rx Bytes:   725424
  Throughput: 0.644821 Mbps
Flow 2 (10.0.0.3 -> 10.0.0.2)
  Tx Bytes:   3442908
  Rx Bytes:   776832
  Throughput: 0.690517 Mbps



> Also, I enabled pcap to look at what was being observed for UDP receptions on
> node 1.  In the basic case from node 10.0.0.1 (first one above) I count 1300
> UDP datagrams of 200 bytes each.   1300*200*8/10 = 0.208 Mb/s.  Even if I
> account for UDP/IP header, I would expect 1300*228*8/10 = 0.237 Mb/s.  So
> perhaps the flow monitor count needs to be checked here also.
Can there be a difference between what pcap is counting and
what the FlowMonitor is doing?
Comment 3 jrinas 2013-10-01 17:05:24 UTC
I've just compared the behavior of the pcap trace and the FlowMonitor:

I'm getting somehow consistent results comparing pcap trace and the
FlowMonitor output:
1.) uncomment: line88: "wifiPhy.EnablePcap..."
2.) ./waf --run wifi-hidden-terminal
3.) loading the
      *-pcap-node-1-0.pcap
    into wireshark.
    (!!! I'm using the destination node 1 ==  10.0.0.2,
     since FlowMonitor monitors  successfully receive bytes)
4.) applying a wireshark filter
      Analyze => Display Filter
         "udp && not icmp && ip.src == 10.0.0.1"
5.) reading the "Displayed" Packets <Packet count>
6.) (200+28)*<Packet count>  *8 /9 
    corresponds to the Throughput in bit/s


observation:
  There is a difference when counting the UDP packets transmitted in
  *-pcap-node-0-0.pcap whith the number of received packets 
  in *-pcap-node-1-0.pcap.
  This can be the modeled packet loss due to overlapping packets in the phy...


one more bug:
  The filenames for pcap and athstats seem to be exchanged?

  Syntax for the condition operator ist:
  http://www.cplusplus.com/doc/tutorial/operators/ :
  " 
    condition ? result1 : result2
    If condition is true the expression will return result1,
    if it is not it will return result2.
  "
Comment 4 Tom Henderson 2013-10-08 09:35:44 UTC
fix committed in changeset 5c232e60cef4

Changes wrt. ns-allinone-3.18/ns-3.18/examples/wireless/wifi-hidden-terminal.cc
* Division by 9 /seconds)
* increased packteSize from 200 to 1400 Bytes
* corrected filenames of log output  ("?:"-operator)
* added some more more outputs (TxPacket, TxOffered, Rx Packtes)
  (see attached output: wifi-hidden-terminal.cc.PacketSize1400.txt)