Internals
-b <int>
Option -b let you specify the size of netsends transmit/receive buffer. Valid values are in the range from 1 till ...(some limits come into game: available memory, max of size_t, so it is your turn to look for your limitations). If you don't touch this argument netsend will select a preferred size (8k for read/write and the size of the file to transfer in mmap/sendfile mode).
The following graph reflect the timing impact. Worst case if you select 1 as the chunksize: then for every byte netsend execute a systemcall. The graph doesn't show this effect because for a 40MB file the transmission takes 1573 seconds via sendfile(2) - and this is is far beyond the mapped image.
Protocol Specific Options (dccp, tcp, tipc, udp, udp-lite, sctp)
Specify your transport layer protocol: After the generic netsend options you can specify the appropriate transport level protocol. This decision has farreaching effects for the transport of data and concern things like reliable and in-order delivery of data, CPU utilization is affected and many other things too. But if you use netsend, we know™ that you are familar with network protocols (unlike us ;-).
The next to figures compare the different transport level protocols. Throughput at a given chunk size for TCP, UDP, UDPLITE and SCTP. The second figure compare and illuminates the consumed CPU time. Note that the Y axis is a logarithmic scale.
DCCP - Datagram Congestion Control Protocol
"The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability." (RFC quote)TCP - Transmission Control Protocol
"The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol suite, often simply referred to as TCP/IP. Using TCP, applications on networked hosts can create connections to one another, over which they can exchange streams of data using Stream Sockets. The protocol guarantees reliable and in-order delivery of data from sender to receiver. TCP also distinguishes data for multiple connections by concurrent applications (e.g., Web server and e-mail server) running on the same host." (Wikipedia quot)UDP - User Datagram Protocol
"UDP does not guarantee reliability or ordering in the way that TCP does. Datagrams may arrive out of order, appear duplicated, or go missing without notice. Avoiding the overhead of checking whether every packet actually arrived makes UDP faster and more efficient, at least for applications that do not need guaranteed delivery." (Wikipedia quot)SCTP - Stream Control Transmission Protocol
"As a transport protocol, SCTP operates analogously to TCP or UDP. Indeed it provides some similar services as TCP - ensuring reliable, in-sequence transport of messages with congestion control. (In the absence of native SCTP support, it may sometimes be desirable to tunnel SCTP over UDP." (Wikipedia quot)UDP LITE - User Datagram Protocol - LITE
"UDP Lite is a connectionless protocol, a variant form of UDP, that will deliver packets even if their checksum is invalid. It is particularly useful for multimedia protocols, such as voice over IP. In these applications, receiving a packet with some damaged portion is better than receiving no packet at all." (Wikipedia quot)Examples
A straight forward example to send and receive /etc/fstab via UDPLite:
# receiver
netsend udplite receive -
# transmiter
netsend -u rw udplite transmit /etc/fstab localhost
A more sophisticated example is where the user select the bytes which
are covered through the checksums mechanism. In the following example, the user
select the first 20 bytes. This means that the UDPLite header (8 Byte)
checked plus additional 12 byte data. One example is RTP where the
first 12 bytes are reserved for the header:
# receiver
netsend udplite receive -
# transmiter (this time via splice(2))
netsend -u splice udplite transmit -C 20 /etc/fstab localhost
It is also possible to enforce a header checksum of a specified
length for the receiver. In the following example the first 30 bytes
must be covered through an proper checksum. Therefore you pass an
additional option to netsend:
# receiver
netsend udplite receive -C 30 -
If the receiver receives an packet which isn't covered properply (e.g.
a checksum only over the first 8 bytes), then the kernel will not
notity the application about new data and drop it in kernel space.
The application will not experience any kind of notification - it
still block in read until the first with a proper checksum coverage
reach the host.
If no checksum coverage is selected the kernel will explicit cover the UDPLite header by themself. This means the first 8 byte are covered. A value of 0 (-C 0) indicate that the whole package should be covered.
TIPC - Transparent Inter-process Communication
"Transparent Inter-process Communication (TIPC) is a communications protocol for inter-process communication (IPC) that was specially designed for intra-cluster communication. This protocol was originally developed by Jon Paul Maloy at Ericsson, and has been used by that company in carrier-grade cluster applications for many years, before subsequently being released to the open source community." (wikipedia quote)
Tips:
Flush Caches (2.6.16 or newer)
# flush pagecache, inodes and dentries
echo 3 > /proc/sys/vm/drop_caches
Don't cache tcp metrics
# don't cache ssthresh from previous connection
sysctl -w net.ipv4.tcp_no_metrics_save=1
Generate a large file
# generate a 40960000 byte file
dd if=/dev/zero of=largefile bs=4k count=10000