bits to Bytes bite me

[rebrecs]

Hi,

Looking for a good reference book on networking but,

There are lots of networking books for sale, and mountains of research papers - all of which concentrate on some part of networking. I am not sure what part of networking might hold the answers to the questions I have. I'm hoping to limit my search by first asking here. Looking for - anything published that looks at bits and bytes in terms of 'work?' Perhaps some characterization of work versus overhead? I checked my test data csv file and our conversion here at TMN is pretty much a straight "divide by 8," which makes perfect sense; a byte is 8 bits all day long. Got it.

I'm just going to ramble for a paragraph or so, and maybe someone will make sense of what I think I am asking;

How much of the bit-stream on the wire constitutes a byte of actual data in the way a customer would think of their data? I believe that is a question about overhead. In my view, (as a customer) if I am going to move a 200 MB file, then in the simplest terms, and using networking byte representation,  [200,000,000 bytes x 8 = 1,600,000,000 bits]. Without asking any more questions - I go away with the understanding that it takes 1.6 Gbits to move my 200 MBytes. But is that true ? (ignoring the silliness that networking byte math introduced)

For discussion, and with no basis whatsoever for choosing the numbers, if in reality it takes 2 Gbits to move my 200 MBytes, then the overhead is introduced by what? I am going to guess it would come from the protocols, handshakes, CRCs, fields left blank -- I don't know, whatever protocols do.

Since any bits or bytes that are purely overhead still consume bit cells, then they use time. So, do they get measured in a Mbps measurement? Or discarded/factored out?

How do it all work?

So that is the play pen I am going to jump into for a little while.  In case there are any recommendations, thank you in advance.

As well as recommendations to reference material, anyone "in-the-know" who can lay it out for me - please by all means - let me hold it. 

 

 

[CA3LE]

To convert 200 MB to kilobytes and then bytes you times by 1024, not 1000.  Bits scale is normal metric.

 

So 200 * 1024 * 1024 = 209,715,200

 

times 8 to convert to bits = 1677721600

 

divided by 1000 3X to arrive back at Gigabits = 1.68 Gbps

 

So if you have 1.68 Gbps, you can transfer 200 MB in 1 second.

 

But yes, there is overhead.

 

To calculate overhead in windows you can do this.

 

1. make sure network activity is quiet during this test
2. from the command prompt type    netstat -e
3. take note of the current the number of "Bytes Received" and "Bytes Sent"
4. type the following using the IP of one of TestMy.net's servers ttcp -t -h0 -D -l1 -n10 -p9 xxx.xx.xx.xx -- this will send 10 bytes to the target.
   1. example to get the IP, type ping dallas.testmy.net -- the IP for that server right now is 45.32.203.96 so the command would be ttcp -t -h0 -D -l1 -n10 -p9 45.32.203.96
5. netstat -e again and subtract "Bytes Received" and "Bytes Sent" from the previous numbers then add them together to get the total bytes transferred, also subtract the 10 bytes you sent... the remaining number is your overhead.

 

https://docs.microsoft.com/en-us/windows/win32/winsock/calculating-overhead-with-netstat-2

 

Been a while since I've tried this, just tried in Windows 10 and it says ttcp command not found... guess I need to read up on that again.

 

But really, as a consumer... I feel you really don't need to be concerned about network overhead.  

 

Here's an article from 2013 on network overhead but it's still relevant today https://packetpushers.net/tcp-over-ip-bandwidth-overhead/

 

Reality is that overhead really depends on the size of the transfer.  It's probably in the neighborhood of 3-7%... more likely on the lower end.  Meaning that 1.73 - 1.8 Gbps would be needed instead of 1.68 Gbps in the scenario above.  So you might lose 50 to 120 Mbps in overhead on such a fast connection but I feel that's pretty minimal in the grand scheme.  If you're pushing nearly 2 Gbps... do you really care about losing 0.05 to 0.12 Gbps of it?  ... I think I could manage.   

[mudmanc4]

 Packet size effects throughput as well, due to the number of packets required. As well as payload size. Is n truly equatable outside of a proofing environment?

[rebrecs]

On 3/8/2020 at 7:46 AM, mudmanc4 said:

 Packet size effects throughput as well, due to the number of packets required. As well as payload size. Is n truly equatable outside of a proofing environment?

Thank you!

The only "knob" i can find to turn on "packet size"  in the switch gear is "allow/ don't allow Jumbo Packets."

I have not found any "settings" to influence packet size in the TV interfaces.

I suspect there are knobs to turn on the boxes with full blown Operating Systems but they are not really the devices that concern me at the moment.

 

[rebrecs]

On 3/8/2020 at 12:39 AM, CA3LE said:

Reality is that overhead really depends on the size of the transfer.  It's probably in the neighborhood of 3-7%... more likely on the lower end.  Meaning that 1.73 - 1.8 Gbps would be needed instead of 1.68 Gbps in the scenario above.  So you might lose 50 to 120 Mbps in overhead on such a fast connection but I feel that's pretty minimal in the grand scheme.  If you're pushing nearly 2 Gbps... do you really care about losing 0.05 to 0.12 Gbps of it?  ... I think I could manage.   

Hi, thanks for the links! I will definitely have a look. Also, I understand your unspoken guidance. (like, get out of the weeds dude :-)) All I really have to do is reveal that I thought about it and took a cursory look. I won't let it become a lifestyle. I promise.