Add license references

Change-Id: I24f1d3445e238a0fe584da2b8c894b6ff8b950b6
This commit is contained in:
Yichen Wang 2015-02-19 14:58:44 -08:00
parent b68f7fd24f
commit 9c128addac
7 changed files with 57 additions and 55 deletions

View File

@ -85,9 +85,16 @@ VMTP will display the results to stdout with the following data:
Detailed results can also be stored in a file in JSON format using the *--json* command line argument.
=====
License
-------
* iperf: BSD License (https://iperf.fr/license.html)
* nuttcp: GPL v2 License (http://nuttcp.net/nuttcp/beta/LICENSE)
Links
=====
-----
* Documentation: http://vmtp.readthedocs.org/en/latest
* Source: http://git.openstack.org/cgit/stackforge/vmtp

View File

@ -0,0 +1,19 @@
==============
Implementation
==============
TCP Throughput Measurement
--------------------------
The TCP throughput reported is measured using the default message size of the test tool (64KB with nuttcp). The TCP MSS (maximum segment size) used is the one suggested by the TCP-IP stack (which is dependent on the MTU).
UDP Throughput Measurement
--------------------------
UDP throughput is tricky because of limitations of the performance tools used, limitations of the Linux kernel used and criteria for finding the throughput to report.
The default setting is to find the "optimal" throughput with packet loss rate within the 2%~5% range. This is achieved by successive iterations at different throughput values.
In some cases, it is not possible to converge with a loss rate within that range and trying to do so may require too many iterations. The algorithm used is empiric and tries to achieve a result within a reasonable and bounded number of iterations. In most cases the optimal throughput is found in less than 30 seconds for any given flow.
**Note:** UDP measurements are only available with nuttcp (not available with iperf).

View File

@ -14,6 +14,8 @@ Contents:
readme
installation
usage
setup
implementation
contributing
.. Indices and tables

7
doc/source/issue.rst Normal file
View File

@ -0,0 +1,7 @@
========================
Caveats and Known Issues
========================
* UDP throughput is not available if iperf is selected (the iperf UDP reported results are not reliable enough for iterating)
* If VMTP hangs for native hosts throughputs, check firewall rules on the hosts to allow TCP/UDP ports 5001 and TCP port 5002

19
doc/source/setup.rst Normal file
View File

@ -0,0 +1,19 @@
=====
Setup
=====
Public Cloud
------------
Public clouds are special because they may not expose all OpenStack APIs and may not allow all types of operations. Some public clouds have limitations in the way virtual networks can be used or require the use of a specific external router. Running VMTP against a public cloud will require a specific configuration file that takes into account those specificities.
Refer to the provided public cloud sample configuration files for more information.
SSH Password-less Access
------------------------
For host throughput (*--host*), VMTP expects the target hosts to be pre-provisioned with a public key in order to allow password-less SSH.
Test VMs are created through OpenStack by VMTP with the appropriate public key to allow password-less ssh. By default, VMTP uses a default VMTP public key located in ssh/id_rsa.pub, simply append the content of that file into the .ssh/authorized_keys file under the host login home directory).
**Note:** This default VMTP public key should only be used for transient test VMs and **MUST NOT** be used to provision native hosts since the corresponding private key is open to anybody! To use alternate key pairs, the 'private_key_file' variable in the configuration file must be overridden to point to the file containing the private key to use to connect with SSH.

View File

@ -268,55 +268,3 @@ The first IP passed (*--host*) is always the one running the server side. Option
python vmtp.py --host localadmin@172.29.87.29:eth5 --host localadmin@172.29.87.30
**Note:** Prior to running, the VMTP public key must be installed on each VM.
======
Setups
======
Public Cloud
------------
Public clouds are special because they may not expose all OpenStack APIs and may not allow all types of operations. Some public clouds have limitations in the way virtual networks can be used or require the use of a specific external router. Running VMTP against a public cloud will require a specific configuration file that takes into account those specificities.
Refer to the provided public cloud sample configuration files for more information.
SSH Password-less Access
------------------------
For host throughput (*--host*), VMTP expects the target hosts to be pre-provisioned with a public key in order to allow password-less SSH.
Test VMs are created through OpenStack by VMTP with the appropriate public key to allow password-less ssh. By default, VMTP uses a default VMTP public key located in ssh/id_rsa.pub, simply append the content of that file into the .ssh/authorized_keys file under the host login home directory).
**Note:** This default VMTP public key should only be used for transient test VMs and **MUST NOT** be used to provision native hosts since the corresponding private key is open to anybody! To use alternate key pairs, the 'private_key_file' variable in the configuration file must be overridden to point to the file containing the private key to use to connect with SSH.
===============
Implementations
===============
TCP Throughput Measurement
--------------------------
The TCP throughput reported is measured using the default message size of the test tool (64KB with nuttcp). The TCP MSS (maximum segment size) used is the one suggested by the TCP-IP stack (which is dependent on the MTU).
UDP Throughput Measurement
--------------------------
UDP throughput is tricky because of limitations of the performance tools used, limitations of the Linux kernel used and criteria for finding the throughput to report.
The default setting is to find the "optimal" throughput with packet loss rate within the 2%~5% range. This is achieved by successive iterations at different throughput values.
In some cases, it is not possible to converge with a loss rate within that range and trying to do so may require too many iterations. The algorithm used is empiric and tries to achieve a result within a reasonable and bounded number of iterations. In most cases the optimal throughput is found in less than 30 seconds for any given flow.
**Note:** UDP measurements are only available with nuttcp (not available with iperf).
========================
Caveats and Known Issues
========================
* UDP throughput is not available if iperf is selected (the iperf UDP reported results are not reliable enough for iterating)
* If VMTP hangs for native hosts throughputs, check firewall rules on the hosts to allow TCP/UDP ports 5001 and TCP port 5002

View File

@ -2,4 +2,4 @@
git-review>=1.24
pylint>=1.3
pep8>=1.5.7
flake8>=2.3.0