BandaAncha.eu

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate
ADSL/VDSL

ADSL ¿Canales de upload y download totalmente independientes?

BocaDePez
BocaDePez

Hola amigos,

He podido comprobar al estar haciendo audiostream mediante Shoutcast, en definitiva supongo que al hacer cualquier tipo de upload, y hacer cualquier tipo de download al mismo tiempo, el canal de upload decrece de forma espectacular, es decir, que de estar transmitiendo música a unos 12 - 14 KB/s pasa a transmitir a 3 - 5 KB/s porque este descargando cualquier archivo a 27 KB/s en ese preciso instante :-? . Esto me lleva a pensar que los canales de upload y download no son independientes como tenia entendido, es decir que al menos en mi caso es como si tubiese un modem RTB en cierta medida, en cuanto a la compartición del ancho de banda, si bién el mecanismo no es el mismo, puesto que en modem RTB los 56 kbps se reparten entre las subidas y las badajas, y en mi caso, que dispongo de ADSL 256/128 contratado con Terra (ADSL Plus), pasa lo comentado anteriormente, simplemente decrece el canal de subida al descargar.

No se si a alguien le pasará lo mismo que a mi, si es normal o no, y no se si seré muy malpensado, pero me da en la nariz que puede tratarse de alguna artimaña empleada por la Timo/Perra, para fastidiar el tema de compartición de archviso en redes como la de eDonkey/eMule, programas cuya filosofía es que a razón de la velocidad que subes, bajas y a razón de la cantidad de xB que compartas, tendras mas facilidades para descargar. La conclusión que saco de esto es que si al descargar decrece el canal de subida, estas subiendo menos de la cuenta, para poder mantener una velocidad aceptable de bajada, por lo tanto es un pez mordiendose la cola ...

No se ... sacad vuestras propias conclusiones, y ya me direis algo.

Un saludo

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
BocaDePez
BocaDePez

Es normal que el upload disminuya al descargar, puesto que para negociar la descarga necesitas transmitir datos, datos que evidentemente utilizan ancho de banda de tu subida.

🗨️ 7
BocaDePez
BocaDePez

Por supuesto que se necesita confirmar la entrega de un paquete (TCP) y para lo cuál se necesita ancho de banda, hasta ahí de acuerdo, pero que necesite 10 KB de ancho de banda para ello ... no se, me parece algo excesivo, ya se que la velocidad de descarga es tb alta y requerirá que se confirme la entrega de paquetes mas rapidamente, con lo cuál consumirá un mayor ancho de banda, pero si esto es cierto, es normal que el eMule no rinda lo que tendria que rendir, nunca bajarás a 27 KB/s pq esos paquetes se tienen que confirmar y ello consumirá ancho de banda del canal de Upload, con lo cuál como no subes lo que tienes que subir ...... no se quizas este equivocado pero no me acaba de convencer.

Un saludo y gracias por tu respuesta.

🗨️ 6
BocaDePez
BocaDePez

bueno, haber yo subo algunas veces a ftp's para web de warez, y si bajo a 24KB/S la subida a un server t3 que suelo subir de 8KB/S-11KB/S baja hasta los 2KB/S, a parte que es comprendible eso de que el donwload chupe por la peticion de paquetes, ademas de eso la velocidad no es 256, sino en mi caso es 209KB/S bajada y 107subida, algo que aún hace que esto sea mas penoso... si alemnos tuviesemos 256KB/S reales de subida y 128KB/S reales de bajada, tendrian que hacer como auna, que da 300 porque sabe sobradamente que se les reducira hasta unos 256 que antes ponia menta en mi zona, que es algo comprensible, mis amigos de clase con menta (ahora auna) llegan a bajar sin picos a 38KB/S y yo bajo a 24KB/S sin picos....penosísimo, no se si opinais igual que yo, y ademas lo que me faltaba , se desconecta solo pero se queda el icono de la barra de tareas conectado, pero no recive ni envia ni un solo byte........

opinar vosotros pero esto va en decadencia......

🗨️ 5
BocaDePez
BocaDePez

ademas sin fast path....... pings malos malos malos , no un ping que una adsl devería poseer......... hay que pena de pais.. con la mafiofonica y los demás.....ojala que viniese algun japonés o cualquier simple usuario japones a enseñarles que es la BANDA ANCHA, que esto estan como las carreteras comarcales, saturadas y hechas mierdas.....
el japonés les enseñaría como tiraría una ETHERNET GIGABIT de 20mbit/s por usuario :-P , si alli no han puesto el plc por algo será, talvez da pings malos y al haber tanto consumo.. el espectro de la zona de onda del plc se encogeria y no daria ni para 100 personas............

🗨️ 4
BocaDePez
BocaDePez
🗨️ 3
BocaDePez
BocaDePez
🗨️ 2
BocaDePez
BocaDePez
🗨️ 1
BocaDePez
BocaDePez
BocaDePez
BocaDePez

Lo que no has mirado es que cuando emites, la bajada está activa, recibiendo peticiones. Entre los servicios que ejecutas simultáneamente los hay con mayor preferencia, por tanto, si agotas tu rx con la descarga de un archivo, el numero de peticiones shoutcast baja porque las estás tirando o retardando, por lo cual se reduce el numero de usuarios conectados al shoutcast y no utiliza el ancho de banda de subida, "porque no lo necesita". Y no hace falta cabrearse, que pareceis crios, joder.

Saludos

anthrax

totalmente independientes debido a como esta implementado/construido el protocolo TCP.

En un principio suponiendo que solo hubiera el tráfico de streaming la cosa seria más o menos asi:

tú ----subida---- los 12k o 10 k ------ destino
tú -------bajada---ack ---------------- destino

o sea que tu haces de servidor enviando hacia el destino, y el destino va confirmando lo que recibe enviandote pequeñitos paquetes ACK. Hasta que tu no recibes los ACK no sigues enviando datos.

Ok, ahora tambien se une al juego lo que sea que bajas via web,ftp,etc. :

tú ----------subida--ack----------- origen

tú ----------bajada----25K -------- origen

Que es lo que pasa? pues que al estar saturando el ancho de bajada tu tráfico web, pues tb te llegan más lentamente los paquetes ACK del destino del streaming. Y si te llegan menos ACK, envias más lentamente los datos de SUBIDA hacia el destino del streaming (o sea menos K's de subida pa el streaming). Voila!! :)

Aqui es donde entra en juego el QoS, pero esto me lo reservo para cuando tenga tiempo de hacer el ducumento sobre QoS en GNU/Linux y lo envie a BA.

Saludos 8)
P.D : Sera cuestión de ir a sobar! :P
Perdon por no poner flechitas pero no se que pasa con el opera de los @#$%&, que no hay manera de poder enviar las flechas bien! :(