Changes between Version 25 and Version 26 of Internal/DesignNotes


Ignore:
Timestamp:
Apr 10, 2006, 5:06:16 AM (18 years ago)
Author:
kishore
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Internal/DesignNotes

    v25 v26  
    1616[[Image(Internal/DesignNotes:total-time.png)]]
    1717
    18 10000 packets were sent with an interval of 10ms between consecutive packets. The figure (on the left) shows the number of packets successfully received at each receiver. From the figure, all receivers except for one (node14-3) receives all 10000 packets. The same behavior was exhibited in another run of the same experiment. There seems to be a problem with node14-3. We also saw the same behavior when we used 5000 packets instead of 10000.
     1810000 packets were sent with an interval of 10ms between consecutive packets. The figure (on the left) shows the number of packets successfully received at each receiver. From the figure, all receivers except for one (node14-3) receive all 10000 packets. The same behavior was exhibited in another run of the same experiment. There seems to be a problem with node14-3. We also saw the same behavior when we used 5000 packets instead of 10000.
    1919
    20 The figure above (on the right) shows the number of seconds it takes each receiver to receive all files.
     20The figure above (on the right) shows the number of seconds it takes each receiver to receive all packets.
    2121
    2222=== Experiment 2 ===
    … …  
    2626[[Image(Internal/DesignNotes:total-time.3.png)]]
    2727
    28 10000 packets were sent "as fast as possible". There was no "sleep" statement between two consecutive send events at the sender. The figures above show the number of packets lost per receiver (top left) and the number of successful packet receptions (top right). The figure on the bottom left shows the total time taken to receive all packets at each receiver from the sender. Although it is unclear from these results as to what the source of this loss is but we surmise that it is due to buffer overflows at the sender. Our argument in favor of this hypothesis is as follows:
     2810000 packets were sent "as fast as possible". There was no "sleep" statement between two consecutive send events at the sender. The figures above show the number of packets lost per receiver (top left) and the number of successful packet receptions (top right). The figure on the bottom left shows the total time taken to receive all packets at each receiver from the sender. Although it is inconclusive from these results as to what the source of this loss is, we surmise that it is due to buffer overflows at the sender. Our argument in favor of this hypothesis is as follows:
    2929''We waited 5 minutes after the sender terminated before terminating the tcpdump application on each receiver. Hence we waited "long enough" for each sent packet to arrive at each receiver. Another observation is that each receiver is receiving the same number of packets.''
    3030