Bug 2330 - default device queue size for PointToPointNetDevice
default device queue size for PointToPointNetDevice
Status: PATCH PENDING
Product: ns-3
Classification: Unclassified
Component: point-to-point
unspecified
All All
: P3 normal
Assigned To: ns-bugs
:
Depends on: 1604
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-09 01:59 EST by Tom Henderson
Modified: 2016-11-24 15:23 EST (History)
2 users (show)

See Also:


Attachments
suggested patch (924 bytes, patch)
2016-03-09 01:59 EST, Tom Henderson
Details | Diff
suggested patch r1 (1.22 KB, patch)
2016-11-24 15:21 EST, Tom Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2016-03-09 01:59:29 EST
Created attachment 2334 [details]
suggested patch

Now that we have traffic control integrated with PointToPointNetDevice, it seems that we should consider to shrink the default queue size on the device.  It presently is at 100 packets (ns3::Queue default).  The following patch shrinks it to 3 (which is default for Linux PPP).

Only one test suite fails due to this proposed change:
List of FAILed tests:
    adaptive-red-queue-disc

Documentation would need to be updated with this behavioral change.
Comment 1 Stefano Avallone 2016-05-11 04:18:57 EDT
(In reply to Tom Henderson from comment #0)
> Now that we have traffic control integrated with PointToPointNetDevice, it
> seems that we should consider to shrink the default queue size on the
> device.  It presently is at 100 packets (ns3::Queue default).  The following
> patch shrinks it to 3 (which is default for Linux PPP).

Agreed. Also because some preliminary tests we are doing with our preliminary implementation of BQL show that BQL keeps the device queue size at 3 packets on average. Also, a device queue of 100 packets basically makes AQM algorithms useless.

Regarding the patch: I assume you set the maximum number of bytes because the user might switch the queue mode to bytes and hence you need to set such a limit. Just a question: why did you use 65535? If the user leaves the default mtu, this means that the device queue can store (3 * 65535) / 1500 ~= 130 packets.
 
> Only one test suite fails due to this proposed change:
> List of FAILed tests:
>     adaptive-red-queue-disc

This test fails because of some magic numbers hardcoded in the test. I contacted Mohit because modifying the flow control mechanism (as part of the latest requeue rework) also made this test fail. Mohit is working on fixing this.
Comment 2 natale.patriciello 2016-05-11 04:47:37 EDT
(In reply to Stefano Avallone from comment #1)
> Regarding the patch: I assume you set the maximum number of bytes because
> the user might switch the queue mode to bytes and hence you need to set such
> a limit. Just a question: why did you use 65535? If the user leaves the
> default mtu, this means that the device queue can store (3 * 65535) / 1500
> ~= 130 packets.

IMHO we can check the MTU to set the bytes amount, i.e. (3 * GetMtu ()).
Also, instead of raw number 3, we can use a constant uint declared in the class.
Comment 3 Tom Henderson 2016-11-24 15:21:08 EST
Created attachment 2685 [details]
suggested patch r1

incorporating Natale's suggestions
Comment 4 Tom Henderson 2016-11-24 15:23:48 EST
(In reply to Tom Henderson from comment #3)
> Created attachment 2685 [details]
> suggested patch r1
> 
> incorporating Natale's suggestions

it would be a good time to resolve bug 1604 so we can more easily access the default MTU, so I marked as a dependency.