suppose i have a 4MBits network and i want to calculate the data throughput, this is considering the max transfer rate minus overhead from ethernet/IP/TCP headers.
Reading on the web i found out that the MSS ( maximum segment size) of a TCP segment is 576 – 20 – 20, these last two being TCP and IP headers overhead, resulting in a 93% of data, meaning i will be only using 93% of my 4MBits link to transfer data. Now where's the link ayer overhead? Shouldn't it be added as well? If im not wrong an ethernet header is around 46 bytes so the final sum would be 576 – 20 – 20 – 46 = 490, resulting in an 85% data throughput, but am i doing something wrong?
Calculating network throughput
ethernetiptcpthroughput
Related Solutions
Wireshark answers your question in FAQ 7.10.
Most OSes do not support capturing the FCS of a frame on Ethernet, and probably do not support it on most other link-layer types. Some drivers on some OSes do support it, such as some (all?) Ethernet drivers on NetBSD and possibly the driver for Apple's gigabit Ethernet interface in Mac OS X; in those OSes, you might always get the FCS, or you might only get the FCS if you capture in promiscuous mode (you'd have to determine which is the case).
IEEE Std 802.11 Page 60:
The Frame Body field is of variable size. The maximum frame body size is determined by the maximum MSDU size (2304 octets) plus any overhead from security encapsulation.
We use TI 2540 (BLE stack version 1.3.2) succesfully with iPad/iPod/iPhone (iOS 6.x and 7.x). We currently send 75 notifications of 20 bytes per second => 1500 bytes/second. But I have tried to send 125 notifications and that worked as well.
Of course the more you send the greater likelihood of loosing data, e.g., less time to resend a NACK'ed message.
I have experienced that iOS' BLE stack may enter a mode where it begins to NACK messages continuously. If this happens you will loose a lot of messages. I have reported an error to Apple about this. (This problem seems to have been fixed in iOS 7.1.beta3/4.)
I currently have:
// Minimum connection interval (units of 1.25ms, 80=100ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 10
// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 20
Yes, it doesn't conform with Apple's guidelines. But I believe they can be relaxed in our case.
UPDATE: I have also tried to use an iDevice as peripheral, i.e., BTLE between two iDevices. Here I have sent 150 messages per second without any problems.
Best Answer
Just work bottom up. Regular ethernet frames (no jumbo frames, no vlan tagging) are
1542 bytesin total and can have a payload of1500 bytes. An Ipv4 header without options is20 bytesand a TCP header without options also20 bytes. So you end up with1460 bytespossible payload of a1542 bytelink-layer frame. So your efficiency is1460/1542=0.9468223086900129, resulting in a maximum throughput of3.7872892347600517Mbps.Notice however this will usually be lower. This is the theoretical maximum rate for a continuous stream you can get on a full duplex link, after the TCP session is established and when you're the only user of that link. Also note that as soon as you're sending at a slightly higher rate for some time your link will get congested, you will see drops and your actual TCP throughput might drop significantly because of slow-start.
If the link is wireless (802.11) the calculation becomes a lot more complex because of RTS/CTS mechanisms, but it's about
/2for only one active user and that's without incorporating loss, which is unrealistic.