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

Replace formatted apostrophe (’) by simple one (') in docs

Browse Source
This commit is contained in:
Eduardo Almeida
2024-09-30 17:38:56 +01:00
parent 401da89a1e
commit 463e1e4371
13 changed files with 21 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/tutorial/source/getting-started.rst
View File

@@ -728,7 +728,7 @@ For instance, ns-3.28 was released prior to Fedora 28, which included
a new major version of gcc (gcc-8). Building ns-3.28 or older releases
on Fedora 28, when GTK+2 is installed, will result in an error such as::
/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: error: unnecessary parentheses in declaration of ‘__gtk_reserved1’ [-Werror=parentheses]
/usr/include/gtk-2.0/gtk/gtkfilechooserbutton.h:59:8: error: unnecessary parentheses in declaration of '__gtk_reserved1' [-Werror=parentheses]
void (*__gtk_reserved1);
In releases starting with ns-3.28.1, an option is available in CMake to work

4
src/fd-net-device/doc/dpdk-net-device.rst
View File

@@ -13,7 +13,7 @@ DPDK NetDevice
Data Plane Development Kit (DPDK) is a library hosted by The Linux Foundation
to accelerate packet processing workloads (https://www.dpdk.org/).
The ``DpdkNetDevice`` class provides the implementation of a network device which uses DPDK’s fast packet processing abilities and bypasses the kernel. This class is included in the ``src/fd-net-device model``. The ``DpdkNetDevice`` class inherits the ``FdNetDevice`` class and overrides the functions which are required by |ns3| to interact with DPDK environment.
The ``DpdkNetDevice`` class provides the implementation of a network device which uses DPDK's fast packet processing abilities and bypasses the kernel. This class is included in the ``src/fd-net-device model``. The ``DpdkNetDevice`` class inherits the ``FdNetDevice`` class and overrides the functions which are required by |ns3| to interact with DPDK environment.
The ``DpdkNetDevice`` for |ns3| [Patel2019]_ was developed by Harsh Patel,
Hrishikesh Hiraskar and Mohit P. Tahiliani. They were supported by Intel
@@ -306,4 +306,4 @@ Examples
The following examples are provided:
* ``fd-emu-ping.cc``: This example can be configured to use the ``DpdkNetDevice`` to send ICMP traffic bypassing the kernel over a real channel.
* ``fd-emu-onoff.cc``: This example can be configured to measure the throughput of the ``DpdkNetDevice`` by sending traffic from the simulated node to a real device using the ``ns3::OnOffApplication`` while leveraging DPDK’s fast packet processing abilities. This is achieved by saturating the channel with TCP/UDP traffic.
* ``fd-emu-onoff.cc``: This example can be configured to measure the throughput of the ``DpdkNetDevice`` by sending traffic from the simulated node to a real device using the ``ns3::OnOffApplication`` while leveraging DPDK's fast packet processing abilities. This is achieved by saturating the channel with TCP/UDP traffic.

2
src/fd-net-device/doc/netmap-net-device.rst
View File

@@ -68,7 +68,7 @@ amount of bytes that have been transferred to the network device.
The read method is called by the reading thread to retrieve new incoming
packets stored in the netmap receiver ring and pass them to the appropriate
|ns3| protocol handler for further processing within the simulator’s network
|ns3| protocol handler for further processing within the simulator's network
stack. After retrieving packets, the reading thread also synchronizes
the netmap receiver ring, so that the retrieved packets can be removed
from the netmap receiver ring.

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

@@ -1005,7 +1005,7 @@ The following unit tests have been written to validate the implementation of DCT
* ECT flags should be set for SYN, SYN+ACK, ACK and data packets for DCTCP traffic
* ECT flags should not be set for SYN, SYN+ACK and pure ACK packets, but should be set on data packets for ECN enabled traditional TCP flows
* ECE should be set only when CE flags are received at receiver and even if sender doesn’t send CWR, receiver should not send ECE if it doesn’t receive packets with CE flags
* ECE should be set only when CE flags are received at receiver and even if sender doesn't send CWR, receiver should not send ECE if it doesn't receive packets with CE flags
An example program, ``examples/tcp/tcp-validation.cc``, can be used to
experiment with DCTCP for long-running flows with different bottleneck

2
src/internet/model/tcp-socket-base.cc
View File

@@ -1553,7 +1553,7 @@ TcpSocketBase::ProcessEstablished(Ptr<Packet> packet, const TcpHeader& tcpHeader
NS_LOG_WARN("Ignored ack of " << tcpHeader.GetAckNumber()
<< " HighTxMark = " << m_tcb->m_highTxMark);
// Receiver sets ECE flags when it receives a packet with CE bit on or sender hasn’t
// Receiver sets ECE flags when it receives a packet with CE bit on or sender hasn't
// responded to ECN echo sent by receiver
if (m_tcb->m_ecnState == TcpSocketState::ECN_CE_RCVD ||
m_tcb->m_ecnState == TcpSocketState::ECN_SENDING_ECE)

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

@@ -136,7 +136,7 @@ References
Scheduler to enhance the capacity of Voice over LTE systems"
<https://ieeexplore.ieee.org/document/6808890>`_,
in Proceedings of 11th International Multi-Conference on Systems,
Signals & Devices (SSD’14), Castelldefels, 11-14 February 2014,
Signals & Devices (SSD'14), Castelldefels, 11-14 February 2014,
Castelldefels (Spain).
.. [Baldo2014] N. Baldo, R. Martínez, P. Dini, R. Vilalta, M. Miozzo,

4
src/lte/doc/source/lte-testing.rst
View File

@@ -118,7 +118,7 @@ System Tests
Dedicated Bearer Deactivation Tests
-----------------------------------
The test suite ‘lte-test-deactivate-bearer’ creates test case with single EnodeB and Three UE’s.
The test suite 'lte-test-deactivate-bearer' creates test case with single EnodeB and Three UE's.
Each UE consists of one Default and one Dedicated EPS bearer with same bearer specification but with different ARP.
Test Case Flow is as follows:
Attach UE -> Create Default+Dedicated Bearer -> Deactivate one of the Dedicated bearer
@@ -134,7 +134,7 @@ Once the test case execution ends it will create ``DlRlcStats.txt`` and ``UlRlcS
Test case executes in three epochs:
#. In first Epoch (0.04s-1.04s) All UE’s and corresponding bearers gets attached and packet flow over the dedicated bearers activated.
#. In first Epoch (0.04s-1.04s) All UE's and corresponding bearers gets attached and packet flow over the dedicated bearers activated.
#. In second Epoch (1.04s-2.04s), bearer deactivation is instantiated, hence User can see relatively less number of TxBytes on UE_ID=1 and LCID=4 as compared to other bearers.
#. In third Epoch (2.04s-3.04s) since bearer deactivation of UE_ID=1 and LCID=4 is completed, user will not see any logging related to LCID=4.

6
src/spectrum/doc/spectrum.rst
View File

@@ -506,7 +506,7 @@ standard, COFDM (Coded Orthogonal Frequency Division Multiplexing) which is
notably used in the DVB-T and ISDB-T digital television standards adopted by
various countries around the world, and analog modulation which is a legacy
technology but is still being used by some countries today. To accomplish
realistic PSD models for these modulation types, the signals’ PSDs were
realistic PSD models for these modulation types, the signals' PSDs were
approximated from real standards and developed into models that are scalable by
frequency and power. The COFDM PSD is approximated from Figure 12 (8k mode) of
[KoppCOFDM]_, the 8-VSB PSD is approximated from Figure 3 of [Baron8VSB]_, and the
@@ -560,13 +560,13 @@ channel for each these regions are provided.
:align: center
Plot from MATLAB implementation of CreateRegionalTvTransmitters method in
``TvSpectrumTransmitterHelper``. Shows 100 random points on Earth’s surface
``TvSpectrumTransmitterHelper``. Shows 100 random points on Earth's surface
(with altitude 0) corresponding to TV transmitter locations within a 2000 km
radius of 35° latitude and -100° longitude.
A method (CreateRegionalTvTransmitters) is provided that enables users to
randomly generate multiple TV transmitters from a specified region with a given
density within a chosen radius around a point on Earth’s surface. The region,
density within a chosen radius around a point on Earth's surface. The region,
which determines the channel frequencies of the generated TV transmitters, can
be specified to be one of the three provided, while the density determines the
amount of transmitters generated. The TV transmitters' antenna heights

2
src/traffic-control/doc/fq-codel.rst
View File

@@ -48,7 +48,7 @@ as described below.
* ``FqCoDelQueueDisc::DoEnqueue()``: If no packet filter has been configured, this routine calls the QueueDiscItem::Hash() method to classify the given packet into an appropriate queue. Otherwise, the configured filters are used to classify the packet. If the filters are unable to classify the packet, the packet is dropped. Otherwise, an option is provided if set associative hashing is to be used.The packet is now handed over to the CoDel algorithm for timestamping. Then, if the queue is not currently active (i.e., if it is not in either the list of new or the list of old queues), it is added to the end of the list of new queues, and its deficit is initiated to the configured quantum. Otherwise, the queue is left in its current queue list. Finally, the total number of enqueued packets is compared with the configured limit, and if it is above this value (which can happen since a packet was just enqueued), packets are dropped from the head of the queue with the largest current byte count until the number of dropped packets reaches the configured drop batch size or the backlog of the queue has been halved. Note that this in most cases means that the packet that was just enqueued is not among the packets that get dropped, which may even be from a different queue.
* ``FqCoDelQueueDisc::SetAssociativeHash()``: An outer hash is identified for the given packet. This corresponds to the set into which the packet is to be enqueued. A set consists of a group of queues. The set determined by outer hash is enumerated; if a queue corresponding to this packet's flow is found (we use per-queue tags to achieve this), or in case of an inactive queue, or if a new queue can be created for this set without exceeding the maximum limit, the index of this queue is returned. Otherwise, all queues of this full set are active and correspond to flows different from the current packet's flow. In such cases, the index of first queue of this set is returned. We don’t consider creating new queues for the packet in these cases, since this approach may waste resources in the long run. The situation highlighted is a guaranteed collision and cannot be avoided without increasing the overall number of queues.
* ``FqCoDelQueueDisc::SetAssociativeHash()``: An outer hash is identified for the given packet. This corresponds to the set into which the packet is to be enqueued. A set consists of a group of queues. The set determined by outer hash is enumerated; if a queue corresponding to this packet's flow is found (we use per-queue tags to achieve this), or in case of an inactive queue, or if a new queue can be created for this set without exceeding the maximum limit, the index of this queue is returned. Otherwise, all queues of this full set are active and correspond to flows different from the current packet's flow. In such cases, the index of first queue of this set is returned. We don't consider creating new queues for the packet in these cases, since this approach may waste resources in the long run. The situation highlighted is a guaranteed collision and cannot be avoided without increasing the overall number of queues.
* ``FqCoDelQueueDisc::DoDequeue()``: The first task performed by this routine is selecting a queue from which to dequeue a packet. To this end, the scheduler first looks at the list of new queues; for the queue at the head of that list, if that queue has a negative deficit (i.e., it has already dequeued at least a quantum of bytes), it is given an additional amount of deficit, the queue is put onto the end of the list of old queues, and the routine selects the next queue and starts again. Otherwise, that queue is selected for dequeue. If the list of new queues is empty, the scheduler proceeds down the list of old queues in the same fashion (checking the deficit, and either selecting the queue for dequeuing, or increasing deficit and putting the queue back at the end of the list). After having selected a queue from which to dequeue a packet, the CoDel algorithm is invoked on that queue. As a result of this, one or more packets may be discarded from the head of the selected queue, before the packet that should be dequeued is returned (or nothing is returned if the queue is or becomes empty while being handled by the CoDel algorithm). Finally, if the CoDel algorithm does not return a packet, then the queue must be empty, and the scheduler does one of two things: if the queue selected for dequeue came from the list of new queues, it is moved to the end of the list of old queues. If instead it came from the list of old queues, that queue is removed from the list, to be added back (as a new queue) the next time a packet for that queue arrives. Then (since no packet was available for dequeue), the whole dequeue process is restarted from the beginning. If, instead, the scheduler did get a packet back from the CoDel algorithm, it subtracts the size of the packet from the byte deficit for the selected queue and returns the packet as the result of the dequeue operation.

4
src/wifi/model/frame-exchange-manager.cc
View File

@@ -1235,13 +1235,13 @@ FrameExchangeManager::UpdateNav(Ptr<const WifiPsdu> psdu, const WifiTxVector& tx
if (psdu->GetAddr1() == m_self)
{
// When the received frame’s RA is equal to the STA’s own MAC address, the STA
// When the received frame's RA is equal to the STA's own MAC address, the STA
// shall not update its NAV (IEEE 802.11-2016, sec. 10.3.2.4)
return;
}
// For all other received frames the STA shall update its NAV when the received
// Duration is greater than the STA’s current NAV value (IEEE 802.11-2016 sec. 10.3.2.4)
// Duration is greater than the STA's current NAV value (IEEE 802.11-2016 sec. 10.3.2.4)
Time navEnd = Simulator::Now() + duration;
if (navEnd > m_navEnd)
{

4
src/wifi/model/he/he-frame-exchange-manager.cc
View File

@@ -2005,7 +2005,7 @@ HeFrameExchangeManager::UpdateNav(Ptr<const WifiPsdu> psdu, const WifiTxVector&
if (psdu->GetAddr1() == m_self)
{
// When the received frame’s RA is equal to the STA’s own MAC address, the STA
// When the received frame's RA is equal to the STA's own MAC address, the STA
// shall not update its NAV (IEEE 802.11-2020, sec. 10.3.2.4)
return;
}
@@ -2036,7 +2036,7 @@ HeFrameExchangeManager::UpdateNav(Ptr<const WifiPsdu> psdu, const WifiTxVector&
}
// For all other received frames the STA shall update its NAV when the received
// Duration is greater than the STA’s current NAV value (IEEE 802.11-2020 sec. 10.3.2.4)
// Duration is greater than the STA's current NAV value (IEEE 802.11-2020 sec. 10.3.2.4)
auto intraBssNavEnd = Simulator::Now() + duration;
if (intraBssNavEnd > m_intraBssNavEnd)
{

6
src/wifi/test/wifi-phy-cca-test.cc
View File

@@ -1682,7 +1682,7 @@ WifiPhyCcaIndicationTest::RunOne()
// Verify PHY notifies CCA-BUSY for the S40 as long as a signal above the energy detection
// threshold occupies the first 20 MHz subchannel of the S40: 27.3.20.6.4: Any signal within
// the secondary 40 MHz channel at or above a threshold of –59 dBm within a period of
// aCCATime after the signal arrives at the receiver’s antenna(s).
// aCCATime after the signal arrives at the receiver's antenna(s).
Simulator::Schedule(delay,
&WifiPhyCcaIndicationTest::LogScenario,
this,
@@ -1740,7 +1740,7 @@ WifiPhyCcaIndicationTest::RunOne()
// Verify PHY notifies CCA-BUSY for the S40 as long as a signal above the energy detection
// threshold occupies the second 20 MHz subchannel of the S40: 27.3.20.6.4: Any signal
// within the secondary 40 MHz channel at or above a threshold of –59 dBm within a period of
// aCCATime after the signal arrives at the receiver’s antenna(s).
// aCCATime after the signal arrives at the receiver's antenna(s).
Simulator::Schedule(delay,
&WifiPhyCcaIndicationTest::LogScenario,
this,
@@ -1797,7 +1797,7 @@ WifiPhyCcaIndicationTest::RunOne()
// Verify PHY notifies CCA-BUSY for the S40 as long as a signal above the energy detection
// threshold occupies S40: 27.3.20.6.4: Any signal within the secondary 40 MHz channel at or
// above a threshold of –59 dBm within a period of aCCATime after the signal arrives at the
// receiver’s antenna(s).
// receiver's antenna(s).
Simulator::Schedule(delay,
&WifiPhyCcaIndicationTest::LogScenario,
this,

2
utils/tests/README.md
View File

@@ -67,7 +67,7 @@ When you fork ns-3-dev on Gitlab, you get access to some free hours of execution
To customize the path:
1. Go to the project’s **Settings > CI / CD**.
1. Go to the project's **Settings > CI / CD**.
2. Expand the **General pipelines** section.
3. Provide `utils/tests/gitlab-ci.yml` as a value in the **Custom CI configuration path** field.
4. Click **Save changes**.