params.json

{"name":"Flowgrind","tagline":"Advanced TCP traffic generator for Linux, FreeBSD, and Mac OS X","body":"Flowgrind - TCP traffic generator\r\n=================================\r\n\r\n[![Build Status](https://travis-ci.org/flowgrind/flowgrind.png?branch=master)](https://travis-ci.org/flowgrind/flowgrind)\r\n\r\nFlowgrind is an advanced TCP traffic generator for testing and benchmarking **Linux**, **FreeBSD**, and **Mac OS X** TCP/IP stacks. In contrast to similar tools like iperf or netperf it features a distributed architecture, where throughput and other metrics are measured between arbitrary flowgrind server processes.\r\n\r\n* Website: [www.flowgrind.net](http://www.flowgrind.net)\r\n* Issues: [GitHub Issues](https://github.com/flowgrind/flowgrind/issues)\r\n* API documentation: [Doxygen](http://flowgrind.github.io/flowgrind)\r\n\r\n\r\nWhat It Can Do?\r\n===============\r\n\r\nFlowgrind measures besides **goodput** (throughput), the application layer **interarrival time** (IAT) and **round-trip time** (RTT), **blockcount** and network **transactions/s**. Unlike most cross-platform testing tools, flowgrind can output some transport layer information, which are usually internal to the TCP/IP stack. For example, on Linux and FreeBSD this includes among others the kernel's estimation of the end-to-end RTT, the size of the TCP congestion window (CWND) and slow start threshold (SSTHRESH).\r\n\r\nFlowgrind has a distributed architecture. It is split into two components: the *flowgrind daemon* and the *flowgrind controller*. Using the controller, flows between any two systems running the flowgrind daemon can be setup (third party tests). At regular intervals during the test the controller collects and displays the measured results from the daemons. It can run multiple flows at once with the same or different settings and individually schedule every one. Test and control connection can optionally be diverted to different interfaces.\r\n\r\nThe traffic generation itself is either bulk transfer, rate-limited, or sophisticated request/response tests. Flowgrind uses libpcap to automatically dump traffic for qualitative analysis.\r\n\r\n\r\nBuilding flowgrind\r\n==================\r\n\r\nFlowgrind builds cleanly on *Linux*, *FreeBSD*, and *Mac OS X*. Other operating systems are currently not planned to be supported. Flowgrind expects `libxmlrpc-c` to be available. Additionally, for the optional advanced traffic generation and automatic dump support `libgsl ` an `libpcap` should be installed.\r\n\r\nFlowgrind is built using GNU autotools on all supported platforms. You can build it using the following commands:\r\n\r\n\t# cd flowgrind\r\n\t# autoreconf -i\r\n\t# ./configure\r\n\t# make\r\n\r\nFor more information see INSTALL.\r\n\r\n\r\nInstructions to run a test\r\n==========================\r\n\r\n1. Start `flowgrindd` on all machines that should be the endpoint of a flow.\r\n2. Execute `flowgrind` on some machine (not necessarily one of the endpoints) with the host names of the endpoints passed through the -H option.\r\n\r\nAssume we have 4 machines, host0, host1, host2 and host3 and flowgrind has been installed on all of them. We want to measure flows from host1 to host2 and from host1 to host3 in parallel, controlled from host0. First, we start `flowgrindd` on host1 to host3. On host0 we execute:\r\n\r\n\t# flowgrind -n 2 -F 0 -H s=host1,d=host2 -F 1 -H s=host1,d=host3\r\n\r\nIn order to not influence the test connection with control traffic, flowgrind allows to setup the RPC control connection over a different interface. A typical scenario would be to test a WiFi connection and run the control traffic over a wired connection.\r\n\r\nAssume two machines running `flowgrindd`, each having two network adapters, one wired, one wireless. We run `flowgrind` on a machine that is connected by wire to the test machines. First machine has addresses 10.0.0.1 and 192.168.0.1, the other has addresses 10.0.0.2 and 192.168.0.1. So our host argument will be this:\r\n\r\n\t# flowgrind -H s=192.168.0.1/10.0.0.1,d=192.168.0.2/10.0.0.2\r\n\r\nIn words: test from 192.168.0.1 to 192.168.0.2 on the nodes identified by 10.0.0.1 and 10.0.0.2 respectively.\r\n","google":"","note":"Don't delete this file! It's used internally to help with page regeneration."}