Bits are transferred to you at (up to) sync speed and your tray icon is probably displaying the bit rate.
However to ensure the communicated information is correct and actually belongs to you the communication protocols have to add addressing and integrity-check information to each block of payload data transferred. The added information is contained in what are known as headers and the size of these headers is not insignificant.
The main Internet communication protocol is TCP/IP with TCP data segments encapsulated in IP datagrams. For ADSL in the UK the IP datagrams are transmitted to the user using ATM cells.
TCP segments carry a 20 byte header, IP adds another 20 bytes giving a 40 byte overhead in what is typically up to 1500 bytes (2.7% on
maximum-size segments). ATM cells are fixed size and contain 53 bytes comprising 48 bytes of payload with a 5 byte header overhead (9.4% overhead). IP segments are not split across cells so the overhead for some cells could be 98%.
If the sync speed (bit rate) is 4559kbps, overheads means the useful data rate at best is 4559 x (48 / 53) x (1460 / 1500) = 4018kbps. Notice that value is close to what BT set as the IP Profile of 4000kbps for that sync speed. So the IP Profile reflects the idealised useful-data rate for this connection.
I referred to this as 'idealised' because real communications cannot run at that rate. For starters ones computer (client) has to contact the server and establish a connection. Then the data required has to be requested. The server sends TCP segments in response but it is essential that all of those are received, and received undamaged. So the client has to acknowledge receipt of each segment and any segment not received has to be sent again. Finally the connection has to be closed.
If the server waited for acknowledgement of every segment before sending another the connection would run very slowly; this is where RWIN (the receive window) comes in. This is important for Windows XP and earlier, later versions of Windows manage RWIN dynamically. However setting "the right" RWIN is another story.
The effect of these 'real communication' delays is not quantifiable but reductions of upwards of 500-800kbps are normal, so
at best 3500kbps would be the "real" speed for a 4559kbps sync. You mentioned 3200kbps which I would regard as normal.
Some simplifications of the real situation, but hope that helps.
David
David
