Changes between Version 22 and Version 23 of Internal/DesignNotes
- Timestamp:
- Apr 10, 2006, 5:00:46 AM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/DesignNotes
v22 v23 13 13 === Experiment 1 === 14 14 15 [[Image(Internal/DesignNotes:num-pkts-lost.png)]]16 15 [[Image(Internal/DesignNotes:num-pkts-recvd.png)]] 17 16 [[Image(Internal/DesignNotes:total-time.png)]] 18 17 19 10000 packets were sent with an interval of 10ms between consecutive packets. The figure above(on the left) shows the number of packets lost per 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. This seems to indicate that there might be something wrong with node14-3. The figure (on the right) shows the number of packets successfully received at each receiver.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. 20 19 21 We also saw the same behavior when we used 5000 packets instead of 10000.20 The figure above (on the right) shows the number of seconds it takes each receiver to receive all files. 22 21 23 22 === Experiment 2 === … … 25 24 [[Image(Internal/DesignNotes:num-pkts-lost.3.png)]] 26 25 [[Image(Internal/DesignNotes:num-pkts-recvd.3.png)]] 26 [[Image(Internal/DesignNotes:total-time.3.png)]] 27 27 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 (on the left) and the number of successful packet receptions (on the right). It is unclear from current experiments as to where this loss is occurring. Some sources of this loss could be 29 * buffer (between user-space and kernel-space, between kernel and driver, between driver and card) overflows at the sender or receiver? 30 * the switches in the network cannot handle the load? Seems unlikely. 31 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. A way to test this hypothesis would be to increase the size of the socket buffer and re-run the same experiment. 29 32 30 === Experiment 3 === 33 31 34 32 [[Image(Internal/DesignNotes:num-pkts-lost.2.png)]] 35 33 [[Image(Internal/DesignNotes:num-pkts-recvd.2.png)]] 34 [[Image(Internal/DesignNotes:total-time.2.png)]] 36 35 37 5000 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 ( on the left) and the number of successful packet receptions (on the right). It is unclear from current experiments as to where this loss is occurring.36 5000 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). It is unclear from current experiments as to where this loss is occurring. The figure on the bottom left shows the total time taken to receive all packets at each receiver from the sender. 38 37 39 38 = Design Notes for nodehandler =
