Sign up with GoogleNo, I'm referring to the impact of store-and-forward devices on smaller packets vs packets at max MTU. But your point of payload ratio will also have an impact.
-
Ask a question and get free supportUnlock new privileges and see hidden discussionsWin prizes and earn reputation
-
Question of the day ~ How often do you braai?
-
Afristay giveaway.Win a 2-night stay for two people at an establishment of your choice with R1,000 in spending money. Enter here.
Vodacom 3g is Pathetic.
- Thread starter Tassidar
- Start date
No, I'm referring to the impact of store-and-forward devices on smaller packets vs packets at max MTU. But your point of payload ratio will also have an impact.
- Joined
- Nov 8, 2004
- Messages
- 14,805
Simple and common scenario that demonstrates the correlation between TCP/IP and packet loss and data transfer speed:
When transferring data [either up or down], for example using ftp|http [which is layered on top of TCP/IP], if a single frame within a specific packet is lost or delayed to the point where a timeout is triggered, what will happen is that TCP/IP will request the retransmission of the entire packet, which means more frames being transmitted and hopefully received and reassembled into their original packet, so far so good, but frames can and do arrive in any order [non-sequential] and all frames are required in order to assemble a packet from constituent frames, this means that TCP/IP has to wait until it has all the frames. If just one of the frames is missing then some time will have passed including the actual timeout before realising that a frame is not going to arrive. All of this adds latency to the actual data transfer itself, all of this will result in the overall data transfer taking longer than it should have under ideal conditions, and an increase in time results in a decrease in speed - regardless of the actual link speed...
When transferring data [either up or down], for example using ftp|http [which is layered on top of TCP/IP], if a single frame within a specific packet is lost or delayed to the point where a timeout is triggered, what will happen is that TCP/IP will request the retransmission of the entire packet, which means more frames being transmitted and hopefully received and reassembled into their original packet, so far so good, but frames can and do arrive in any order [non-sequential] and all frames are required in order to assemble a packet from constituent frames, this means that TCP/IP has to wait until it has all the frames. If just one of the frames is missing then some time will have passed including the actual timeout before realising that a frame is not going to arrive. All of this adds latency to the actual data transfer itself, all of this will result in the overall data transfer taking longer than it should have under ideal conditions, and an increase in time results in a decrease in speed - regardless of the actual link speed...
Wasn't that the Love Generation ? And we still trust them....
You should trust them. They made you....
Or is that that why you don't trust them in the first place?
You should trust them. They made you....
Or is that that why you don't trust them in the first place?
Not *so* sure about that now....but peace out !
I doubt that - it's a radio network so....as for the reconnect, that would be a software thing
Prometheus
Banned
- Joined
- Mar 19, 2006
- Messages
- 4,252
They didn't make me. Just missed them luckily.You should trust them. They made you....
Or is that that why you don't trust them in the first place?
I can't remember getting any disconnects on MTN's GPRS, don't know about their 3G.