Oppose - I understand goodput to be a term of the art which is pretty much unknown outside a small networking community. I believe there is room for both articles. In my opinion, the edits to what was Measuring data throughput have made the article less accessible, and less easy to understand. Goodput also encompasses more than simply the maximum throughput of data (less overheads), but includes packet loss; whereas people attempting to measure throughput are often attempting to determine the maximum possible data throughput under ideal conditions and may not appreciate just how large some overheads may be, before even beginning to consider items like serialisation delay, packet loss and other items. WLD22:32, 5 November 2006 (UTC)[reply]
Okay. I have withdrawn my own merge suggestion. However, the "measuring network throughput" article needs to be rewritten in many ways. Perhaps it was good once uppon a time. Protocol overhead and kibiByte/kByte confusion only affects the throughput calculation a few percent as is not important. Protocol overhead calculations may be moved into the goodput article, or to a new article on protocol overhead. The focus of the "measuring network throughput" article should be on the key factors why the achieved throughput some times differ very much from the maximum throughput. Examples are TCP flow control and that the network capacity is shared with other users. These factors are described in the throughput article, but may be more pedagogically explained. (limited TCPSome of the details on protocol overhead may be moved to the goodput article. Mange0108:42, 10 November 2006 (UTC)[reply]
