Network Performance Notes
Part 1 - Theoretical Estimates

Network Performance

These notes discuss two aspects of network performance:

This is a theoretical discussion that can only provide estimates of performance. These estimates are but one part of the design and development of NDIS packet monitor software. It should be understood that:

Experimentation, instrumentation and measurement is the only way to actually understand the performance of computer systems.

TCP Performance

TCP performance is a measure of the ability of a network to transport TCP user data. The performance calculations account for data link and IP/TCP protocol overhead associated with transporting TCP user data for various packet sizes.

These estimates are adapted from Section 24 of TCP/IP Illustrated Volume 1 - The Protocols, by W. Richard Stevens. Published 1994 by Addison-Wesley Publishing, Inc. They are extended to include information of interest to developers of network software for the Windows platform.

The bulk of the performance calculations are based on operation on a 10Mbps Ethernet LAN. Simple scaling is used in the summary to extrapolate to 100Mbps FastEthernet and 1000Mbps Gigabit Ethernet LANs.

In calculating network performance it is convenient to represent inter-packet gap in terms of the time it takes to transmit one "real" network byte. For example, the Ethernet inter-packet gap is 9.6 microseconds, which is the time it takes to transmit 12 "real" network bytes. Where appropriate these "virtual" bytes are enclosed on parentheses "()".

NDIS Performance

NDIS Performance is a measure of the required capability for a NDIS-based packet monitor to collect packets on the network  - theoretically without loss. There are two (2) parameters of interest:

In calculating NDIS performance understand that NDIS does not provide a way to observe the 8-byte Ethernet preamble nor the 4-byte Ethernet CRC. Of course, NDIS does not  directly observe the inter-packet gap as received bytes.

These notes provide an estimate of the performance of a hypothetical loss-less packet monitor. No consideration is given to the demands of application or driver packet data processing, bandwidth of logging facilities, network adapter capabilities, etc.

Performance Summary

The Tables below provide a summary of the performance estimates:

10Mbps Ethernet Performance Summary

Conclusions

There are two fairly obvious conclusions that can be distilled from the performance estimates:

1. NDIS Throughput Requirement - This varies so little that the NDIS throughput design goal is basically the theoretical performance of the network media.
    
2. Runt Packet Frequency Support Requirement - The packet frequency of minimum size ("runt") packets places significant demands on the design and implementation of a packet monitor.

The runt packet frequency is particularly intimidating. On the slowest 10Mbps LAN the run packet frequency is 14,880 packets/second. If each runt packet is lifted from kernel-space to user-space, then there would be 14,880 kernel-user transitions per second. Even if this could be achieved on high-performance systems it is clear that a goal of an NDIS packet monitor would be to reduce the number of these transitions.

Performance For MTU 1500, MSS 1460

This is the performance on a 10Mbps local area network.

TCP Throughput

If the TCP window is opened to its maximum size (65535, not using the window scale option), this allows a window of 44 1460-byte segments. It the receiver sends an ACK every 22nd segment the throughput calculation becomes:

NDIS Throughput

Under the same conditions a NDIS-based network monitor would observe 1514 bytes of each TCP data packet and 60 bytes of each ACK packet. The corresponding NDIS throughput would be:

Here is an estimate of the packet frequency that NDIS would observe during an interval where the 22 TCP data packets and the ACK were exchanged:

Performance for MTU 576, MSS 536

This is the performance observed when accessing the Internet using a 10Mbps local area network where the remote MTU is throttled to the traditional 576-byte limit.

TCP Throughput

If the TCP window is opened to its maximum size (65535, not using the window scale option), this allows a window of 122 536-byte segments. It the receiver sends an ACK every 61th segment the throughput calculation becomes:

Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List
· Privacy Statement · 

WinDis 32 is a trademark of Printing Communications Assoc., Inc. (PCAUSA).
Rawether for Windows and Rawether .NET are trademarks of Printing Communications Assoc., Inc. (PCAUSA).
Microsoft, MS, Windows, Windows 95, Windows 98, Windows Millennium, Windows 2000, Windows XP, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Send mail to rawether-webmaster@pcausa.com with questions or comments about this web site.
Copyright © 1996-2012 Printing Communications Assoc., Inc. (PCAUSA).
All rights reserved.
Last modified: January 01, 2012