F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: sphinx warnings in Models book

Browse Source
This commit is contained in:
Peter D. Barnes, Jr
2020-04-28 15:52:24 -07:00
parent 5f8291006d
commit fe8981f2c9
6 changed files with 61 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
doc/models/Makefile
View File

@@ -86,6 +86,7 @@ SOURCES = \
$(SRC)/traffic-control/doc/tbf.rst \
$(SRC)/traffic-control/doc/red.rst \
$(SRC)/traffic-control/doc/codel.rst \
$(SRC)/traffic-control/doc/cobalt.rst \
$(SRC)/traffic-control/doc/fq-codel.rst \
$(SRC)/traffic-control/doc/pie.rst \
$(SRC)/traffic-control/doc/mq.rst \

10
src/internet/doc/tcp.rst
View File

@@ -722,7 +722,7 @@ As a first approximation, the LEDBAT sender operates as shown below:
On receipt of an ACK:
.. math::
::
currentdelay = acknowledgement.delay
basedelay = min (basedelay, currentdelay)
queuingdelay = currentdelay - basedelay
@@ -812,7 +812,7 @@ latency, and high throughput with shallow-buffered switches.
* Sender functionality: The sender makes use of the modified receiver ECE semantics to maintain an average of fraction of packets marked (α) by using the exponential weighted moving average as shown below:
::
.. math::
α = (1 - g) x α + g x F
@@ -825,13 +825,13 @@ For windows in which at least one ACK was received with ECE set,
the sender should respond by reducing the congestion
window as follows, once for every window of data:
::
.. math::
cwnd = cwnd * (1 - α / 2)
Following the recommendation of RFC 8257, the default values of the parameters are:
::
.. math::
g = 0.0625 (i.e., 1/16)
@@ -1326,7 +1326,7 @@ Writing TCP tests
The TCP subsystem supports automated test
cases on both socket functions and congestion control algorithms. To show
how to write tests for TCP, here we explain the process of creating a test
case that reproduces the `Bug #1571<https://www.nsnam.org/bugzilla/show_bug.cgi?id=1571>`_.
case that reproduces the `Bug #1571 <https://www.nsnam.org/bugzilla/show_bug.cgi?id=1571>`_.
The bug concerns the zero window situation, which happens when the receiver
cannot handle more data. In this case, it advertises a zero window, which causes

2
src/lte/doc/source/lte-design.rst
View File

@@ -4714,7 +4714,7 @@ various components. These objects are:
the implementation is delegated to the child classes in order to allow for different
EPC network models.
A third helper object is used to configure the :ref:`_sec-carrier-aggregation` functionality:
A third helper object is used to configure the :ref:`sec-carrier-aggregation` functionality:
* ``CcHelper``, which takes care of the configuration of the ``LteEnbComponentCarrierMap``,
basically, it creates a user specified number of ``LteEnbComponentCarrier``.

2
src/propagation/doc/propagation.rst
View File

@@ -712,7 +712,7 @@ implementing the 3GPP propagation loss models.
The test cases :cpp:class:`ThreeGppRmaPropagationLossModelTestCase`,
:cpp:class:`ThreeGppUmaPropagationLossModelTestCase`,
:cpp:class:`ThreeGppUmiPropagationLossModelTestCase` and
:cpp:class:`ThreeGppIndoorOfficePropagationLossModelTestCas`e compute the path loss between two nodes and compares it with the value obtained using the formulas in 3GPP TR 38.901 [38901]_, Table 7.4.1-1.
:cpp:class:`ThreeGppIndoorOfficePropagationLossModelTestCase` compute the path loss between two nodes and compares it with the value obtained using the formulas in 3GPP TR 38.901 [38901]_, Table 7.4.1-1.
The test case :cpp:class:`ThreeGppShadowingTestCase` checks if the shadowing is correctly computed by testing the deviation of the overall propagation loss from the path loss. The test is carried out for all the scenarios, both in LOS and NLOS condition.
ChannelConditionModel

90
src/traffic-control/doc/cobalt.rst
View File

@@ -27,57 +27,60 @@ COBALT model in |ns3| by comparing the results obtained from it to those obtaine
from the Linux model of COBALT. A detailed comparison of ns-3 model of COBALT with
Linux model of COBALT is provided in ([Cobalt19]_).
* class :cpp:class:`CobaltQueueDisc`: This class implements the main Cobalt algorithm:
* ``CobaltQueueDisc::DoEnqueue ()``: This routine tags a packet with the
current time before pushing it into the queue. The timestamp tag is used by
``CobaltQueue::DoDequeue()`` to compute the packet's sojourn time. If the
queue is full upon the packet arrival, this routine will drop the packet and
record the number of drops due to queue overflow, which is stored in
`m_stats.qLimDrop`.
* ``CobaltQueueDisc::ShouldDrop ()``: This routine is
``CobaltQueueDisc::DoDequeue()``'s helper routine that determines whether a
packet should be dropped or not based on its sojourn time. If the sojourn time
goes above `m_target` and remains above continuously for at least `m_interval`,
the routine returns ``true`` indicating that it is OK to drop the packet.
``Otherwise, it returns ``false``. This routine decides if a packet should be
dropped based on the dropping state of CoDel and drop probability of BLUE.
The idea is to have both algorithms running in parallel and their effectiveness
is decided by their respective parameters (Pdrop of BLUE and dropping state of
CoDel). If either of them decide to drop the packet, the packet is dropped.
* ``CobaltQueueDisc::DoDequeue ()``: This routine performs the actual packet
``drop based on ``CobaltQueueDisc::ShouldDrop ()``'s return value and schedules
the next drop. Cobalt will decrease BLUE's drop probability if the queue is
empty. This will ensure that the queue does not underflow. Otherwise Cobalt will
take the next packet from the queue and calculate its drop state by running
CoDel and BLUE in parallel till there are none left to drop.
* class :cpp:class:`CobaltQueueDisc`: This class implements the main
Cobalt algorithm:
* ``CobaltQueueDisc::DoEnqueue ()``: This routine tags a packet with the
current time before pushing it into the queue. The timestamp tag is used by
``CobaltQueue::DoDequeue()`` to compute the packet's sojourn time. If the
queue is full upon the packet arrival, this routine will drop the packet and
record the number of drops due to queue overflow, which is stored in
`m_stats.qLimDrop`.
* ``CobaltQueueDisc::ShouldDrop ()``: This routine is
``CobaltQueueDisc::DoDequeue()``'s helper routine that determines whether a
packet should be dropped or not based on its sojourn time. If the sojourn
time goes above `m_target` and remains above continuously for at least
`m_interval`, the routine returns ``true`` indicating that it is OK
to drop the packet. ``Otherwise, it returns ``false``. This routine
decides if a packet should be dropped based on the dropping state of
CoDel and drop probability of BLUE. The idea is to have both algorithms
running in parallel and their effectiveness is decided by their respective
parameters (Pdrop of BLUE and dropping state of CoDel). If either of them
decide to drop the packet, the packet is dropped.
* ``CobaltQueueDisc::DoDequeue ()``: This routine performs the actual packet
``drop based on ``CobaltQueueDisc::ShouldDrop ()``'s return value and
schedules the next drop. Cobalt will decrease BLUE's drop probability
if the queue is empty. This will ensure that the queue does not underflow.
Otherwise Cobalt will take the next packet from the queue and calculate
its drop state by running CoDel and BLUE in parallel till there are none
left to drop.
* class :cpp:class:`CobaltTimestampTag`: This class implements the timestamp
tagging for a packet. This tag is used to compute the packet's sojourn time
(the difference between the time the packet is dequeued and the time it is
pushed into the queue).
tagging for a packet. This tag is used to compute the packet's sojourn time
(the difference between the time the packet is dequeued and the time it is
pushed into the queue).
References
==========
[Cake16] Linux implementation of Cobalt as a part of the cake framework.
Available online at `<https://github.com/dtaht/sch_cake/blob/master/cobalt.c>`_.
.. [Cake16] Linux implementation of Cobalt as a part of the cake framework.
Available online at
`<https://github.com/dtaht/sch_cake/blob/master/cobalt.c>`_.
[Kath17] Controlled Delay Active Queue Management (draft-ietf-aqm-fq-codel-07)
Available online at `<https://tools.ietf.org/html/draft-ietf-aqm-codel-07>`_.
.. [Kath17] Controlled Delay Active Queue Management
(draft-ietf-aqm-fq-codel-07)
Available online at
`<https://tools.ietf.org/html/draft-ietf-aqm-codel-07>`_.
[BLUE02] Feng, W. C., Shin, K. G., Kandlur, D. D., & Saha, D. (2002). The BLUE
Active Queue Management Algorithms. IEEE/ACM Transactions on Networking (ToN),
10(4), 513-528.
.. [BLUE02] Feng, W. C., Shin, K. G., Kandlur, D. D., & Saha, D. (2002).
The BLUE
Active Queue Management Algorithms. IEEE/ACM Transactions on Networking
(ToN), 10(4), 513-528.
[Cobalt19] Jendaipou Palmei, Shefali Gupta, Pasquale Imputato, Jonathan Morton,
Mohit P. Tahiliani, Stefano Avallone and Dave Taht (2019). Design and Evaluation
of COBALT Queue Discipline. IEEE International Symposium on Local and
Metropolitan Area Networks (LANMAN), July 2019.
.. [Cobalt19] Jendaipou Palmei, Shefali Gupta, Pasquale Imputato, Jonathan
Morton, Mohit P. Tahiliani, Stefano Avallone and Dave Taht (2019).
Design and Evaluation of COBALT Queue Discipline. IEEE International
Symposium on Local and Metropolitan Area Networks (LANMAN), July 2019.
Attributes
@@ -87,8 +90,7 @@ The key attributes that the CobaltQueue Disc class holds include the following:
* ``MaxSize:`` The maximum number of packets/bytes accepted by this queue disc.
* ``Interval:`` The sliding-minimum window. The default value is 100 ms.
* ``Target:`` The Cobalt algorithm target queue delay. The default value is
5 ms.
* ``Target:`` The Cobalt algorithm target queue delay. The default value is 5 ms.
* ``Pdrop:`` Value of drop probability.
* ``Increment:`` Increment value of drop probability. Default value is 1./256 .
* ``Decrement:`` Decrement value of drop probability. Default value is 1./4096 .
@@ -117,7 +119,7 @@ The suite includes 2 test cases:
* Test 1: Simple enqueue/dequeue with no drops.
* Test 2: Change of BLUE's drop probability upon queue full
(Activation of Blue).
(Activation of Blue).
The test suite can be run using the following commands:

14
src/uan/doc/uan.rst
View File

@@ -287,7 +287,7 @@ A user should take into account that, if the power consumption handling is enabl
Li-Ion batteries model
^^^^^^^^^^^^^^^^^^^^^^
A generic Li-Ion battery model has been implemented based on [7][8]. The model can be fitted to any type of Li-Ion battery simply changing the model's parameters The default values are fitted for the Panasonic CGR18650DA Li-Ion Battery [9].
A generic Li-Ion battery model has been implemented based on [7]_ [8]_. The model can be fitted to any type of Li-Ion battery simply changing the model's parameters The default values are fitted for the Panasonic CGR18650DA Li-Ion Battery [9]_.
[TODO insert figure]
As shown in figure the model approximates very well the Li-Ion cells.
Regarding Seagliders, the batteries used into the AUV are Electrochem 3B36 Lithium / Sulfuryl Chloride cells [10]_. Also with this cell type, the model seems to approximates the different discharge curves pretty well, as shown in the figure.
@@ -304,8 +304,8 @@ The communications stack, associated with the AUV, can be modified depending on
Regarding the AUV energy consumption, the user should be aware that the level of accuracy differs for the two classes:
* Seaglider, high level of accuracy, thanks to the availability of detailed information on AUV's components and behaviour [5] [10]. Have been modeled both the navigation power consumption and the Li battery packs (according to [5]).
* REMUS, medium level of accuracy, due to the lack of publicly available information on AUV's components. We have approximated the power consumption of the AUV's motor with a linear behaviour and, the energy source uses an ideal model (BasicEnergySource) with a power capacity equal to that specified in [4].
* Seaglider, high level of accuracy, thanks to the availability of detailed information on AUV's components and behaviour [5]_ [10]_. Have been modeled both the navigation power consumption and the Li battery packs (according to [5]_).
* REMUS, medium level of accuracy, due to the lack of publicly available information on AUV's components. We have approximated the power consumption of the AUV's motor with a linear behaviour and, the energy source uses an ideal model (BasicEnergySource) with a power capacity equal to that specified in [4]_.
Future Work
===========
@@ -392,7 +392,7 @@ UAN Examples
* ``li-ion-energy-source``
In this simple example, we show how to create and drain energy from a LiIonEnergySource.
We make a series of discharge calls to the energy source class, with different current drain and durations, until all the energy is depleted from the cell (i.e. the voltage of the cell goes below the threshold level).
Every 20 seconds we print out the actual cell voltage to verify that it follows the discharge curve [9].
Every 20 seconds we print out the actual cell voltage to verify that it follows the discharge curve [9]_.
At the end of the example it is verified that after the energy depletion call, the cell voltage is below the threshold voltage.
@@ -435,7 +435,7 @@ The glider mobility model is the GliderMobilityModel with default parameters.
The glider energy model is the GliderEnergyModel with default parameters.
Regarding the energy source, the Seaglider features two battery packs, one for motor power and one for digital-analog power.
Each pack is composed of 12 (10V) and 42 (24V) lithium chloride DD-cell batteries, respectively [5]. The total power capacity is around 17.5 MJ (3.9 MJ + 13.6 MJ).
Each pack is composed of 12 (10V) and 42 (24V) lithium chloride DD-cell batteries, respectively [5]_. The total power capacity is around 17.5 MJ (3.9 MJ + 13.6 MJ).
In the original version of the Seaglider there was 18 + 63 D-cell with a total power capacity of 10MJ.
The packs design is as follows:
@@ -465,7 +465,7 @@ Install into a node (or set of nodes) the REMUS features:
The REMUS mobility model is the RemusMobilityModel with default parameters.
The REMUS energy model is the RemusEnergyModel with default parameters.
Regarding the energy source, the REMUS features a rechargeable lithium ion battery pack rated 1.1 kWh @ 27 V (40 Ah) in operating conditions (specifications from [3] and Hydroinc European salesman).
Regarding the energy source, the REMUS features a rechargeable lithium ion battery pack rated 1.1 kWh @ 27 V (40 Ah) in operating conditions (specifications from [3]_ and Hydroinc European salesman).
Since more detailed information about battery pack were not publicly available, the energy source used is a BasicEnergySource.
The micro modem energy model is the MicroModemEnergyModel with default parameters.
@@ -566,5 +566,5 @@ Li-Ion Energy Source
Includes test case for Li-Ion energy source.
The unit test can be found in ``src/energy/test/li-ion-energy-source-test.cc``.
The test case verify that after a well-known discharge time with constant current drain, the cell voltage has followed the datasheet discharge curve [9].
The test case verify that after a well-known discharge time with constant current drain, the cell voltage has followed the datasheet discharge curve [9]_.