4 ms·

Not sure what you see, but I always multiply transfers times 10 to estimate bandwidth, since there is some overhead in the TCP/IP protocol. So 280MB/s I would e

Not sure what you see, but I always multiply transfers times 10 to estimate bandwidth, since there is some overhead in the TCP/IP protocol. So 280MB/s I would estimate being about 2.8gbps...

masterteague3 3y ago
To convert MB/s to gb/s (MegaBytes per second to Gigabits per second) simply multiply by 8 (8 bits per byte). So 280MB/s is 2.24gbps (moving the decimal place).
- _gabe_ 3y ago
  > but I always multiply transfers times 10 to estimate bandwidth, since there is some overhead in the TCP/IP protocol
  - woooooo 3y ago
    20%ish seems high though, especially for file transfers which are probably almost all full packets near 1500 MTU cross WAN.
- thcthc 3y ago
  There is another variable as well. Most network equipment I've worked with reported throughput with incorrectly labeled kibi/mibi/gibi, and the ISP uses kilo/mega/giga. The former system is multiples of 1024, the latter the mathematical and legal definition of x1000 The X10 rule of thumb is probably pretty spot on at the end
  - zamadatix 3y ago
    What godforsaken gear reports in binary prefixes? That's just... horrendous.
tgtweak 3y ago
I think ethernet (1500mtu standard) has about 30 bytes of packet routing information per (max) 1500 bytes of data. That works out to 2% minimum. On smaller data packets (less than 1.5kb) it would be a much higher percentage. TLS on top of that, once you're out of the handshake, is about 40 bytes. those 40 bytes would be inside that 1500 window. Assuming 1460 bytes of data (best case) with 40 bytes of TLS and 30 bytes of ethernet overhead - that's up to ~5%. There maybe further overhead when that packet gets to your router/modem and out to your ISP, and their switches, consider that there's likely another wrapped header on there accounting for 30 more bytes and possibly causing a packet to get split into two smaller ones. I think 10% would be the highest "data rate" vs "port rate" overhead you'd see, without involving a VPN or complex network.
- shrubble 3y ago
  I am not sure if the original poster is talking about downloading over https and, whether he is mentioning the data rate or the file size. For instance you download a 1gbyte file in 4 seconds - your effective data rate in terms of what you want to see on your disk is 250Mbytes/second ; but if you measure the actual data rate it would be more due to both TCP/IP and, application layer overhead.
  - civiloid 3y ago
    There is a more concrete example - in the article I've showed iperf3 output, which gave 23.5 Gbit/s - that is actual data. Raw speed was ~24.9-25. Everything else is overhead in that case.

Not sure what you see, but I always multiply transfers times 10 to estimate bandwidth, since there is some overhead in the TCP/IP protocol. So 280MB/s I would estimate being about 2.8gbps...

masterteague3 3y ago

To convert MB/s to gb/s (MegaBytes per second to Gigabits per second) simply multiply by 8 (8 bits per byte). So 280MB/s is 2.24gbps (moving the decimal place).

_gabe_ 3y ago
> but I always multiply transfers times 10 to estimate bandwidth, since there is some overhead in the TCP/IP protocol
- woooooo 3y ago
  20%ish seems high though, especially for file transfers which are probably almost all full packets near 1500 MTU cross WAN.
thcthc 3y ago
There is another variable as well. Most network equipment I've worked with reported throughput with incorrectly labeled kibi/mibi/gibi, and the ISP uses kilo/mega/giga. The former system is multiples of 1024, the latter the mathematical and legal definition of x1000 The X10 rule of thumb is probably pretty spot on at the end
- zamadatix 3y ago
  What godforsaken gear reports in binary prefixes? That's just... horrendous.

tgtweak 3y ago

I think ethernet (1500mtu standard) has about 30 bytes of packet routing information per (max) 1500 bytes of data. That works out to 2% minimum. On smaller data packets (less than 1.5kb) it would be a much higher percentage. TLS on top of that, once you're out of the handshake, is about 40 bytes. those 40 bytes would be inside that 1500 window. Assuming 1460 bytes of data (best case) with 40 bytes of TLS and 30 bytes of ethernet overhead - that's up to ~5%. There maybe further overhead when that packet gets to your router/modem and out to your ISP, and their switches, consider that there's likely another wrapped header on there accounting for 30 more bytes and possibly causing a packet to get split into two smaller ones. I think 10% would be the highest "data rate" vs "port rate" overhead you'd see, without involving a VPN or complex network.

shrubble 3y ago
I am not sure if the original poster is talking about downloading over https and, whether he is mentioning the data rate or the file size. For instance you download a 1gbyte file in 4 seconds - your effective data rate in terms of what you want to see on your disk is 250Mbytes/second ; but if you measure the actual data rate it would be more due to both TCP/IP and, application layer overhead.
- civiloid 3y ago
  There is a more concrete example - in the article I've showed iperf3 output, which gave 23.5 Gbit/s - that is actual data. Raw speed was ~24.9-25. Everything else is overhead in that case.