Buffer Scheduling

[Arvind Mahla]

Sir,

I have rewritten the report. The arguments and points have been modified and may not correspond to the points in older report.

- Page 5: The difference between tests in Fig 1-4 from Fig 5 is not clear. You should give more details for each figure or draw a diagram of the setup. I think I understood point 1, point 2 isn't clear, point 3 definitely isn't clear. 

The RTT values at a dongle were showing an increasing trend when parallel uploads were carried out. The reason for this can be that either the uplink buffers are of very large size or parallel uploads on other Dongles do have a direct effect on RTT. Fig 5 represents tests (for different packet sizes) with upload being carried out only on one Dongle. It was the test to actually confirm the argument that parallel uploads do affect uplink RTT.

- Page 5: Point 6 of ping packets being treated differently from UDP packets is a very strong claim. Think how will you validate this directly?

No answers yet.

- Page 12: Same problem as above. For point 1, the graphs for uplink and downlink look similar to me, can't understand the difference you are identifying. Point 2 saying "use of per buffer for downloads" has missing words.

In Uplink graphs, RTT keeps on increasing with increased in number of parallel uploads, while in case of downlink graphs, RTT  almost remains constant. It is not affected by other parallel downloads. 

[Aaditeshwar Seth]

Arvind, You need to improve your presentation even more. Is this what you are saying:

1. For upload, as you start more and more connections, the RTT increases and the throughput decreases. But for download, as you start more and more connections, the RTT does not increase but the throughput decreases.

2. Common sense sanity check that you should do: During upload, when you have dongle 1 and 2 both uploading, are both getting similar delays? Similarly, when all dongle-1 and dongle-2 and dongle-3 are uploading, are they getting similar delays? You should draw per connection CDFs for delays during these three phases

3. Common sense throughput test validation: Repeat these tests at least 20 times to see if the throughput gets divided fairly across the connections or not. Table-1 thoughput test 1 has D3 getting a much higher throughput than others

4. Figure 5 is still not clear. Are you showing what happens when you start multiple connections on the same dongle?

5. Section 3, trying different packet sizes on different connections. Saying that Fig 11 ~ Fig 1 is of no value unless you show CDFs side by side.

6. Checking whether ping packets are being treated differently from UDP packets was a question for you. Need an answer. How will you check?

--
You received this message because you are subscribed to the Google Groups "ruralnet-act4d" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ruralnet-act4...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
Aaditeshwar Seth
Co-founder, Gram Vaani Community Media

http://gramvaani.org
http://www.linkedin.com/company/gram-vaani-community-media

[Asheesh Sharma]

Sir,

Q. Checking whether ping packets are being treated differently from UDP packets was a question for you. Need an answer. How will you check?

Arvind sir said that this may be due to following reasons:
1) Different buffers for ping and UDP packets
2) Some queue management algorithm

I ran a test to measure the buffers size of individual flows(UDP and ping), which were different. I think it can be a evidence for different buffers as: if a single buffer was in act, the buffer size must have been same irrespective of UDP or ping.

Regards,
Asheesh