On Tuesday 09 January 2007 22:50, joachim Gwoke wrote: > i haven't written the whole logs but this is what i > got consistently for the past 3 days. > > Pinging buuza.com [72.232.75.142] with 32 bytes of > data: > > Request timed out. > Reply from 72.232.75.142: bytes=32 time=1034ms TTL=48 > Reply from 72.232.75.142: bytes=32 time=935ms TTL=48 > Reply from 72.232.75.142: bytes=32 time=931ms TTL=48 > > Ping statistics for 72.232.75.142: > Packets: Sent = 4, Received = 3, Lost = 1 (25% > loss), > Approximate round trip times in milli-seconds: > Minimum = 931ms, Maximum = 1034ms, Average = > 725ms at 20:29hrs 8\1\2007 > > Ping statistics for 2.2.2.2: > Packets: Sent = 4, Received = 0, Lost = 4 (100% > loss), > Approximate round trip times in milli-seconds: > Minimum = 0ms, Maximum = 0ms, Average = 0ms > 20:30hrs 8\1\2007 > > pinging yahoo.com [216.109.112.135] with 32 bytes of > data > Reply from 216.109.112.135: bytes = 32 time = 955ms > TTL = 51 > request timed out. > Reply from 216.109.112.135: bytes = 32 time = 1085ms > TTL = 51 > Reply from 216.109.112.135: bytes = 32 time = 1159ms > TTL = 51 20:40hrs 8\1\2007 > > Pinging yellowaccess.co.ug [69.50.167.242] with 32 > bytes of data: > > Reply from 69.50.167.242: bytes=32 time=950ms TTL=50 > Reply from 69.50.167.242: bytes=32 time=929ms TTL=50 > Reply from 69.50.167.242: bytes=32 time=1028ms TTL=50 > Reply from 69.50.167.242: bytes=32 time=1119ms TTL=50 > > the 2.2.2.2 is the server ip i get when i connect to > mtn so am not sure if this is the real hostname or ip > for my isp.
Well, you have very high latency to the Internet. Where it's being caused though, is of interest. Can you show similar stats to an address hosted at the exchange point? All that notwithstanding, you've got some packet loss too. Packet loss + high latency will seriously aggravate a slow browsing situation. On the otherhand, since you say other protocols are generally stable, possible MTN are rate limiting HTTP traffic, as it's the most popular, but this is only speculation - someone from MTN's 3G/IP team would need to confirm. You also need to remember that latency can impose an upper limit on throughput: throughput = window / RTT Where window is the maximum TCP window size (64KB by default) and RTT is the round trip time in the network. This equation tells us that the throughput of a TCP connection is inversely proportional to network latency (note that this is TCP throughput for one connection - the aggregate bandwidth is not affected by latency). In other words, if you double latency, you halve throughput. Another possible problem could be MTU issues on your connection to MTN (again, I can't vouch here as I don't know what method MTN use to aggregate customers with this kind of connection). It would help if MTN could provide you with a pingable IP address (preferrably at major hops within their core IP network) which you can ping at different packet sizes (up to 1472 [1500] bytes) to find out if any loss is being induced by the core. Also, what speed do you connect at? Mark.
pgpTEgw36DsIr.pgp
Description: PGP signature
_______________________________________________ LUG mailing list [email protected] http://kym.net/mailman/listinfo/lug %LUG is generously hosted by INFOCOM http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The List's Host is not responsible for them in any way. ---------------------------------------
