Talk:Goodput

Terminology

I know wikipedia is a slave to convention (eg, using existing common terms rather than inventing it's own) but the term "goodput" sounds like an "appealing placement" rather than describing what it's actually about, such as "application level throughput"/"application layer throughput" (relating to the OSI model of network layers) or just "useful throughput". How commonly used is "goodput" really? Also the term "good" is subjective; high application layer/level throughput for malware isn't a good thing for the owner of an infected computer — Lee Carré 23:27, 7 July 2007 (UTC)

Goodput is a fairly established term in the network testing profession, but as far as I can see not widely used even amongst (regular) network professionals. The term is not for describing the content of the data (like stated above, it well could be malware), but the data which is successfully transfered (as opposed to the data in packets that are lost or mangled). Eseim (talk) 15:54, 24 September 2008 (UTC)

Every network layer adds its overhead. Goodput looks very specific to the "TCP-testing" profession. Marchash (talk) 13:40, 20 July 2009 (UTC)

'Goodput' may come from Queuing Theory. The earliest reference I've found is this 1984 abstract: the customer, unknown to the system, turns 'bad' at a random time after its arrival ... the performance of such systems is measured by the rate at which it serves good customers ('goodput'). Also, the term appears to be in declining use.

(Update:) Found another in a 1983 economics book: Actually, the firm's output is comprised of both "goodput" and "badput," the "goodput" being the obvious, productive output---the "badput" being that output's ill effects; pollution, accidents and illness, and so on.. - DLeonard (talk) 12:16, 24 April 2018 (UTC)

References

Maximum goodput of Fast Ethernet

The article states

maximum goodput is 1460/1526 × 100 Mbit/s which is 95.67 megabits per second

which is simply incorrect. It ignores the mandatory interpacket gap of 12 bytes, increasing the total bytes on wire to 1538. Accordingly, the maximum achievable goodput for TCP over IPv4 over Fast Ethernet is 94.93 Mbit/s. See also Jumbo frame#Bandwidth efficiency for the complete calculation. --Zac67 (talk) 22:08, 12 January 2026 (UTC)

@Zac67: I'll start by declaring that I'm no expert on this topic. I tagged this article nearly ten years ago for lacking inline references, and that's still very much an issue. It doesn't appear the article is heavily trafficked. My expectations are further lowered by the fact that the calculation of concern is within a section labeled "Example". Examples on Wikipedia are often created in-house, and therefore less likely to be cited.

That said, there is an existed parenthetical note that mentions the 12-byte gap (though it calls it a timestamp...?); it just says that it pertains to Linux and macOS. So even taking the example calculation literally, it's a generic example that doesn't pertain to Linux or macOS specifically. — voidxor 23:06, 12 January 2026 (UTC)

That 12-byte timestamp is in the application layer (AFP and possibly NFS), completely unrelated. Any application-layer headers/overhead further reduce the maximum goodput for anything on top of TCP. The article does mention IFG without actually considering them (and outdated collisions which we should skip here). TCP adds the overhead of acknowledgements is factually wrong as well: TCP ACKs are inline, adding no overhead in excess to TCP's segment header, and they flow in the opposite direction, only relevant for outdated half-duplex links. I suppose reworking the example for basic TCP would be the best idea. Beyond that (e.g. for HTTP), it really gets fuzzy since there's no easily computable size for the overhead. --Zac67 (talk) 13:31, 13 January 2026 (UTC)

I'd say "be bold" and rework that section. It sounds like you're the best one to tackle that. It's an uncited example (except for that one parenthetical note), so the bar is pretty low. I agree that keeping the example as simplistic and universal as possible would be best course of action. — voidxor 14:11, 13 January 2026 (UTC)

Thanks for the thumbs up – hope you like the result! --Zac67 (talk) 20:45, 13 January 2026 (UTC)

@Voidxor: It now reads "the minimum protocol overhead consists of [...] for a total of 38 to 78 bytes for Ethernet" – where do those 78 bytes come from? I'm aware of optional header fields and alternative frame formats, but it seems oddly specific and I deliberately used minimum protocol overhead to avoid this kind of distraction. --Zac67 (talk) 06:25, 15 January 2026 (UTC)

@Zac67:: You had written "for a total of 78 bytes – 38 bytes for Ethernet". I interpreted that as a range, and flipped it around to be in ascending order, since that's how ranges are normally shown. I then replaced the hyphen with the word "to" so that the range wouldn't be mistaken for subtraction. Lastly, I removed the duplicate unit of measure "bytes" for brevity (also a common edit for ranges). So, was this actually meant as subtraction and not a range? If so, I apologize. — voidxor 16:19, 15 January 2026 (UTC)

@Voidxor:, oh I see. No, it wasn't intended as a range but an ndash – made that more clear now, thanks. --Zac67 (talk) 18:20, 16 January 2026 (UTC)

Ah. For future reference, en-dashes between numbers indicate ranges. See MOS:ENTO. — voidxor 18:24, 16 January 2026 (UTC)