Bitorrent en un dia normal baja archivos a mas o menos 20kBps. Bajando directo de un server (a full), la velocidad es de 150kBps. Ahora, si en una maquina corro torrent y en otra bajo archivos directo, la velocidad total de transferencia se viene al piso: torrent baja un poco (a 18kBps), y la bajada directa se va al piso (50kBps). La subida esta en unos 10kbps. O sea, torrent se come la mitad del ancho de banda efectivo.
Creo que tiene que ver con la cantidad de canales activos. No se si es un problema del protocolo, de la implementacion, o algo inherente al P2P. Creo que ahi hay una oportunidad.


Pablo, me interesaría que linkees a mi blog. Avisame y te linkeamos tambien,. abrazo
muy buen contenido
Sergio
No hice muchas pruebas con eso, pero lo he notado en casa. Al tener en un PC activo el BT, el resto navega mas lento.
Hasta donde se, esto tiene que ver con que BT mantiene muchas sesiones subiendo archivos, generando saturacion en la subida de tu enlace. Por los valores que mencionas, debes tener un ADSL de 1536/128, asi que si tu programa declara 10KBps de subida, estas en 80 kbps de payload, que con cabezales anda cerca de los 128 teoricos que te dan.
El efecto de saturar la subida es que los ACK que debe enviar el otro PC para que su transferencia siga bajando se demoran, generando latencia en la subida. Esto a su vez baja la performance de bajada drasticamente, aun habiendo ancho de banda libre.
Este mismo efecto se da cuando haces una bajada directa local (via HTTP a un host en Uruguay por ejemplo) vs. esa misma bajada contra un host en Europa, con casi 300ms de TTL. Los ACK demoran en volver, generando una baja considerable en el throughput. Si esa misma bajada la dividis en 5 partes y bajas los 5 simultaneamente, el throughput global mejora. Por esto entre otras cosas es que protocolos como BT manejan multiples sesiones TCP, y logran saturar un enlace aun habiendo latencia.