TTCP is a benchmarking tool for determining TCP and UDP performance between 2 systems.
There are 2 programs, one of them (ttcp1.c) is the transmitter and the other (ttcp2.c) is the receiver.However, it appears the code (from www.cup.hp.com/netperf) is no longer available.
But, for the brave, our development version. This is no longer maintained. We use iperf for this kind of test.
$ gcc -o tcp1 tcp1.c
$ gcc -o tcp2 tcp2.c
$ gcc -o tcp1 tcp1.c -lsocket -lnsl
$ gcc -o tcp2 tcp2.c -lsocket -lnsl
2 new features have been added to the already existing code. They are
Once the codes are compiled and executed, we get tcp1 and tcp2 as the executable files. The options are
Usage: tcp1 [-options] host
-p ## port number to send to or listen at (default 5500)
-t ## test period in seconds
-u ## use UDP instead of TCP
-w ## tcp buffer size in bytes
-b ## buffer length
-i ## reporting interval in seconds
-g <ip> LSR via this gateway
Usage: ./tcp2 [-dv] [-b bytes] [-u] [-p port] [-w bytes]
-d: enable debug mode
-p: port number
-v: enable verbose mode
-w: max tcp window in bytes
-b: buffer length in bytes
The transmitter was installed on Nereus.slac.stanford.edu and the receiver was installed on Nocdev1-qos.es.net, both on port 5500. UDP packets of buffer length 300 bytes were transmitted with the maximum window size kept at 20000 bytes at both ends. The line was loaded for 5 sec. The receiver has to be installed before the loading is started.
$ ./tcp2 -u -w 20000 -p 5500
Datasink 1.03: Installed (Window size = 20000 bytes)
$ ./tcp1 -u -w 20000 -b 300 -t 5 -p 5500 nocdev1-qos.es.net
TCPwatch 3.1: udp : Max Window = 20000: bufferlength = 300
speed (average) = 8099 kb/sec
-w [window size]:
The maximum no of packets that can unacknowledged at any given time is constrained by the Window size. The sliding window concept makes stream transmission efficient. To, achieve reliability, the sender transmits a packet and then waits for an acknowledgement before transmitting another. The sliding window technique is a more complex form positive acknowledgement and retransmission.
Sliding window protocols allow the sender to transmit multiple packets before waiting for an acknowledgement. The easiest way to envision sliding window operation is to think of a sequence of packets to be transmitted. Say we have 10 packets to be transmitted. If the window size is set to 8 packets, then the 1st 8 packets will be transmitted before any acknowledgement can be received. Once the acknowledgement for the 1st packet is received, the window slides forward covering packet 2 to packet 9. Once the acknowledgement for the 2nd packet is received, the window slides further covering packets 3 to 10, and so onů
TCP views the data stream as a sequence of octets or bytes that it divides into segments for transmission. The acknowledgement of a TCP sliding window protocol contains a window advertisement that specifies how many additional octets of data the receiver is prepared to accept.
Because a well-tuned sliding window protocol keeps the network completely saturated with packets, it obtains substantially higher throughput than a simple positive acknowledgement protocol. Increasing the window size increases the throughput, as a greater number of packets can be placed in the buffer unacknowledged.
Since there are no acknowledgements in a UDP protocol, the concept of sliding window protocols does not exist. This parameter affects the maximum UDP packet length. It may not be possible to set this parameter on some systems (for example, 4.2BSD). Setting the maximum packet length constrains the throughput, as the number of data bytes that can be placed in a packet is restricted. Hence for transmitting a certain number of data bytes, if the max. Packet length is reduced, more packets have to be transferred which results in congestion of the line bottlenecks resulting in reduced throughputs. But the reduction in throughput using UDP transmission is not as steep as that in TCP transmission.
-b [buffer/packet length]:
This option represents the length of buffers in bytes. It indicates that the caller will always receive data from the connection in that size of buffers. In transmit mode, a certain number of buffers of this length are transmitted. In receive mode, this is the length of each receive buffer.
Each packet taking part in a UDP transmission contains has a certain number of bytes it can carry. This value is the packet length. The system limits the maximum packet length.
Each UDP message is called a user datagram. Conceptually, a user datagram consists of 2 parts: a UDP header and a UDP data area. The header is divided into 4 16-bit fields that specify the port from which the message was sent, the port to which the message is destined, the message length and a UDP checksum. The length field contains a count of octets in the UDP datagram, including the UDP header and the user data. Thus, the minimum value for LENGTH is eight, the length of the header alone.
Varying the packet length affects the throughput significantly. Increasing the packet length increases the throughput as more data bytes can be accommodated in a packet. But the variation of throughput with packet length is not linear.
Back to Top
Revised April 21, 2003.
Comments to firstname.lastname@example.org