Bit Torrents? No Go! Part Deux
Last night, I set the Azureus Server to download 4 simultaneous torrents. This morning, the downloads was completely stopped. The Ericsson W25 router was still reachable on LAN but the connection completely hung. No packet access. The router had to be restarted for internet services to be resumed. Looks like that was too much for the system. I've restarted the test again with only 2 torrents running and only one download stream to see if its the network or the router that was giving way.
These are this morning's results for the http access:
So far, summary of the results are as follows:
1) Maximum network download speeds are up to 1.6mbits with lowest around 0.4mbits per second transfers. The speed (on a control system with full signal) are dependent on the following factors:
a) which external IP - as Marul and I found out, certain external IPs have better performance in uploads whilst others have better performance in download speeds. This is most likely due to congestion on the IP addresses and performance of the servers handling those IP addresses. There are 4 IP addresses that we've found so far: 202.x.x.128-131. The .128 IP seems to have the fastest upload speeds and .131 fastest downloads and the other two in between. The most connected IPs are .128 to .129 whilst .130 and .131 have less people doing the speedtests (results from others are logged on Speedtest.net).
2) Real-time performance is based on traffic congestion at the target IP. When the US wakes up (+14 hrs), access to those sites are slowish (between 400kbits to 600kbits) whilst access to sites where the area is off-peak (not in working hour time), speeds are faster up to 1.4mbits.
3) Contrary to popular beliefs, its is NOT the local HSDPA system that is not handling the load with the slow speeds. From what I can assess so far, the slow speeds encountered by many surfers are affected by external uplink factors. Uplink bandwidth is one of them but up to a certain extend with the heaviest variable being actual congestion at the target sites. I also did a latency test last night which showed that the local networks did lost packets (about 10%) at various hops going out. This shouldnt happen because we dont have that many users. US transit points lost no packets.
I've yet to test the transceiver signal factor affecting transfers because I do not have my modem yet. Once i get it, I'll see how and why these are related and the performance of the modem versus the router.
Update:
PS.. BIGGER PIPE means BIGGER DL speeds for users (hint)
These are this morning's results for the http access:
So far, summary of the results are as follows:
1) Maximum network download speeds are up to 1.6mbits with lowest around 0.4mbits per second transfers. The speed (on a control system with full signal) are dependent on the following factors:
a) which external IP - as Marul and I found out, certain external IPs have better performance in uploads whilst others have better performance in download speeds. This is most likely due to congestion on the IP addresses and performance of the servers handling those IP addresses. There are 4 IP addresses that we've found so far: 202.x.x.128-131. The .128 IP seems to have the fastest upload speeds and .131 fastest downloads and the other two in between. The most connected IPs are .128 to .129 whilst .130 and .131 have less people doing the speedtests (results from others are logged on Speedtest.net).
2) Real-time performance is based on traffic congestion at the target IP. When the US wakes up (+14 hrs), access to those sites are slowish (between 400kbits to 600kbits) whilst access to sites where the area is off-peak (not in working hour time), speeds are faster up to 1.4mbits.
3) Contrary to popular beliefs, its is NOT the local HSDPA system that is not handling the load with the slow speeds. From what I can assess so far, the slow speeds encountered by many surfers are affected by external uplink factors. Uplink bandwidth is one of them but up to a certain extend with the heaviest variable being actual congestion at the target sites. I also did a latency test last night which showed that the local networks did lost packets (about 10%) at various hops going out. This shouldnt happen because we dont have that many users. US transit points lost no packets.
I've yet to test the transceiver signal factor affecting transfers because I do not have my modem yet. Once i get it, I'll see how and why these are related and the performance of the modem versus the router.
Update:
PS.. BIGGER PIPE means BIGGER DL speeds for users (hint)
posted by DC at
5/22/2008 09:14:00 am
<< Home