Usar Bittorrent para compartir peliculas de divxclasico

[torpedorr]

En resumen, si cuentas sólo los KB del archivo a distribuir, entonces BT puede ir más rápido, pero si cuentas todos los KB que se puenden mandar, con YDM son bastantes más

EL-MEJOR, me extraña q hayas cometido un error de tal calibre.... supongo q no habras leido todo el posteo y q tampoco habras podido dedicarle demasiado tiempo. Sino, no habrias cometido un fallo tan gordo, estoy seguro.

Ya hemos llegado a la conclusion de q al tener el uploader q enviar todos los trozos x lo menos 1 vez, y tener q repartirse el ultimo trozo recibido entre todos, jamas puede ir mas rapido BT.

tengo una linea 256/128.
publico en mpg (esto es cada cd rondando los 800 mgs.
la peli está totalmente distribuida en menos de 24 horas y completada por varias personas, que se quedan haciendo de seed hasta la fecha de cierre que he publicado.
suponiendo que la han terminado cinco y hay otros 40 peers con la peli a medias, ya no es una subida a 128, sino que son 5+1=6 a 128. con lo cual en dia medio la tienen 45 personas.

Ahi, en ese ejemplo practico, esta la diferencia. En 19 horas aprox en una distri YDM completan todos (no varias personas) enviando a 128. Y eso q en el ejemplo q tu pones, no sabemos si algun downloader tiene una velocidad de subida mayor.... q eso seria una ventaja para BT sobre el ejemplo dado.

En unan distri YDM, pasadas esas 19 horas, ya tendrias las 45 fuentes en la mula (o en BT).

Salu2.

[EL-MEJOR]

En resumen, si cuentas sólo los KB del archivo a distribuir, entonces BT puede ir más rápido, pero si cuentas todos los KB que se puenden mandar, con YDM son bastantes más

EL-MEJOR, me extraña q hayas cometido un error de tal calibre.... supongo q no habras leido todo el posteo y q tampoco habras podido dedicarle demasiado tiempo. Sino, no habrias cometido un fallo tan gordo, estoy seguro.

Cierto que no he leído todo el hilo, también cierto que apenas le he dedicado tiempo y encima tenía un dolor de cabeza que no me dejaba pensar demasiado bien, pero...

Ya hemos llegado a la conclusion de q al tener el uploader q enviar todos los trozos x lo menos 1 vez, y tener q repartirse el ultimo trozo recibido entre todos, jamas puede ir mas rapido BT.

Vamos a ver, si tú admites que tiscali envía más rápido que todos los usuarios juntos, no hay nada que discutir (supongamos que tiscali enviara a 1MB/s y hubieran 10 usuarios que pudieran subir a 12KB/s con lo que en el mejor de los casos, cuando los 10 estuvieran enviando, sería 120KB/s; muy por debajo del 1MB/s de tiscali). Está claro que así el método YDM arrasaría con el BT.

Ahora bien, si aceptas que pueda haber un número de usuarios que, todos juntos, puedan enviar más rápido que tiscali, entonces no está tan claro que BT nunca pueda ir más rápido que YDM. Eso sí, hay condiciones que favorecerían al BT y otras que lo perjudicarían. Cuanto más pequeñas sean las partes en que divide el archivo el BT, más fácil sería acabar antes que con YDM. Lo mismo ocurre con el tamaño del archivo, cuanto más grande sea éste más fácil es que BT ganase. Pero la condición sine quanum para que el BT pueda ir más rápido es que el grupo al completo pueda subir más rápido de lo que lo hace el servidor de correo de tiscali (la parte disponible para el grupo que está descargando el archivo por YDM).

Si me hablas de grupos de 10 personas y con "chunks" tan grandes como en el eMule, entonces te diré que es utópico pensar en distribuir más rápido que con YDM, salvo que tiscali tenga un día muy negro. Pero de eso a decir que NUNCA puede ir más rápido el BT va un largo trecho. Nunca digas NUNCA No es lo mismo que hayan 10 personas descargando de tiscali a 15KB/s a que sean 300. Pero esto lo deberías saber tú mejor que yo ¿o es que no hay días en los que tiscali se atraganta y se alargan las distribuciones? ¿No hay gente que pierde correos? Tiscali no es omnipotente y tiene sus limitaciones.

[javu61]

Hola:

Había preparado una respuesta muy larga, pero lo he dejado reposar, no vale la pena seguir discutiendo.

Ahi te equivocas, pero en contra de la efectividad del sistema YDM. Los ficheros tardan unas 17 horas en distribuirse, por el motivo q sea las subidas no son al maximo teorico del ancho de banda.

Como he dicho repetidas veces, estamos estudiando los dos sistemas EN CONDICIONES IDEALES, en el que no existen retrasos entre paquetes del YDM, y como en este sistema hay tantos paquetes, cualquier retraso se multiplica por mucho, si en lugar de 10 segundos entre paquetes esperamos 1 minuto, tendremos ya 2:20 horas, y además Tiscali no tiene ancho de banda ilimitado, por lo que cuantos mas se apunten, mas retrasos existirán, o cuantas mas distribuciones simultáneas, mas retrasos.

Siguiendo tu ejemplo, al fin del 7º ciclo el uploader ha enviado cada trozo a los 9 downloaders pero... deben intercambiarlo entre ellos. O ese ultimo trozo se multiplica como en el milagro de los panes y los peces???

Repito despacito a ver si queda claro. En cada ciclo BT del ejemplo existen dos fases, una en que solo envía el lanzador 1 paquete a todos, y otro en que todos se intercambian entre sí 10 paquetes, osea que en cada ciclo se intercambian 11 paquetes de 10Mb = 110Mb por ciclo, y 700/110 = 6.36 ciclos, redondeamos a 7. La parte fraccionaria la empleará el sistema en repartir entre todos el último trozo que le falta enviar al emisor y repartirlo entre todos.

Pero mira, me gusta mas tu método, así envías 8 ciclos de 110 megas, y por arte de magia cuando envias una peli de 700Mb, se recibe una peli de 700Mb, mas 180Mb con el "como se hizo". Me has convencido, me paso al BT que permite esto.

De todos modos, gracias x lo de chaval. A mi edad ya empieza a ser un halago....

De nada "chaval", lo puedo decir porque tengo 42 años, y no creo que tu tengas mas que yó, pero dedinitivamente creo que lo tuyo no es lo de las telecomunicaciones, ¿o es que ya no es obligatorio el álgebra, el cálculo, ... y así hasta 5 o 6 asignatutas de mates en la carrera? (y a mayor nivel que en informática creo recordar), ¿será que han quitado la asignatura de redes que antes era obligatoria?.

Aunq de todos modos algo hemos ganado... reconoces q te equivocaste al decir q los tiempos con BT serian menores por la "multiplicacion de la velocidad" (aunq muy de pasada, para la gravedad del error).

Pues si crees que poner un calculo y dar una cifra EXACTA no es suficiente...tu mismo. Y la multipicación de velocidad se cumplirá, pero no en estas condiciones, sino en cuanto uno complete el ficheo y tengamos dos emisores se multiplica, luego completan tres y volvemos a multiplicar, y así. Si la distribución dura mas de 12 horas, los que se apunten después irán a mucha mas velocidad, llegando poder bajar en unas 8 horas.

Tambien te digo q si mis calculos hubieran sido erroneos (y te acabo de demostrar q no lo eran) lo reconoceria sin problema.

Sin comentarios. Tu mismo.

Pues bien, en tu analisis teorico mas o menos estricto de la situacion (en el q has sido demasiado generoso con el YDM) has obviado algo q ya mencione en respuestas anteriores:
.....
La situacion ideal seria q nadie repitiera trozos para q el sistema fuera totalmente eficiente. Solo subiriamos "lo necesario", 1 vez cada trozo a alguien q no lo tuviera.
......
Como estadisticamente un buen numero de ellos se repetira (no sabria decirte en q porcentaje de repeticiones nos moveriamos) el sistema pierde eficiencia (aunq mejora mucho el hipotetico caso de q el uploader tambien repitiera).
.......
1.- Das por supuesto q el Uploader envia a los 10 de golpe. Dudo q sea asi.
......

Ya estamos otra vez con lo mismo, contesto junto al siguiente punto, pero ¿estamos discutiendo sobre situaciones teóricas o reales?, porque si es sobre condiciones reales, hablemos en serio:

1.- ¿Cuanto se engordan los paquetes?, en BT aproximadamente cada parte necesita 1Kb de información redundante, y hay 70 paquetes, total 0.07Mb, ¿y en YDM?, cada paquete de 5Mb necesita por lo menos 500Kb, y hay 140 paquetes, total 68.4Mb.

2.- ¿Cuanto tiempo de espera existe entre paquetes?, en YDM será de unos 2 minutos entre paquetes (sbre un tiempo de 17 horas reales), en BT no puede existir, ya que tenemos teóricos tiempos de espera al final de cada ciclo, en el que se pueden hacer muchas cosas.

3.- ¿Cuanto ancho de banda concede TISCALI al mail?, cifra desconocida, que además variará a ratos. En BT el ancho de banda es el de cada miembro de la distribución, por lo que podemos considerarlo fijo.

4.- ¿Que pasa cuando un paquete llega erroneo?. En YDM lo pierdes y debes recuperar por la mula, en BT se auto-recupera, y como hay teóricamente descansos entre ciclos, mira por donde tenemos tiempo hasta de bajar otra vez el trozo sin penalizar el total.

Se honesto y analizalo con detalle para ver la situacion real. Si hay algun fallo, me dices cual es.

Sigues sin captar que da igual el número de slots, y da igual que no sea una distribución completamente perfecta. Recapitulamos la situación teórica planteada, una distribución se hace en ciclos, cada ciclo tiene dos fases, en la primera solo sirve uno, en la segunda todos a todos, pero existe un tiempo en que deben esperar a que el servidor termine su trozo, que tu asumes en tu ejemplo que se quedan todos esperando, ¿porque?:

A. Si el que sirve envía el mismo trozo a dos, estos ya lo pueden pasar a otros en el tiempo de espera de la segunda fase, por lo que se igualan al final del ciclo todos los usuarios.

B. Si solo hay 3 slots, los tiempos cambian por completo, ya que entonces el que envía sirve a 128/3 en lugar de 128/9, la primera fase del ciclo se acorta. Ahora empieza la segunda fase, y ya tenemos 4 enviando usando 3 slots cada uno, osea que podemos servir a 12, como el ciclo es mas corto al disponer de mayor ancho de banda, y encima sobran 2 slots, dos usuarios recibirán dos trozos en lugar de uno, y en la siguiente fase durante el primer ciclo enviarán tres usuarios en lugar de uno solo.

Si no te has perdido, verás que las dos ventajas del BT son que se ajusta al ancho de banda disponible, y que aprovecha los tiempos muertos para ajustar las diferencias, como el sistema no se queda parado mientras pueda hacer algo, suposición que erroneamente adoptas en tu modelo, este no es válido.

2.- Que alguien se lo lea, lo analice, extraiga conclusiones y lo comente. (a poder ser, javu61). Me joderia muchisimo q no sirviera de nada.

Pues no sirve para nada, ya que asumens que las pausas son pausas reales, pero el sistema las puede aprobechar para otras cosas productivas. Pero aun así, pongo el detalle de lo que me pides después, para no seguir cansando a todos.

En fín, a ver si podemos dejar esta discusión, y centrarnos en el tema del hilo:

Pregunta: ¿porque no usar BT para distribuir pelis clásicas?.

Respuesta: No existe ninguna razón para no hacerlo, y dado que es un método muy sencillo de usar, tanto para el que quiera enviar como para los que quieran recibir, y es un método asíncrono, puedes empezar cuando quieras y no hace falta mantener el ordenador conectado mientras dure la distribucuón, no veo razón alguna para no usarlo. Recomiendo que os paseis por la página que se ha mencionado en este hilo, y en 3 folios os explica mucho mas de los necesario para poner en marcha el BT, es tan sencillo que no tiene ni configuración, no hay nada que configurar.

Jose Antonio

-------------------------------------------------------------------------------------------

Y vamos con el nuevo análisis de la situación planteada. 9 trozos que subir de 10Mb cada uno (T1-T2...T9), un emisor (E) y 9 receptores (R1-R2-R3...R9), líneas de 256/128 pero limitados todos a 3 slots de subida.

1.- E envía T1 a R1, T2 a R2 y T3 a R3. Ha tardado 32 minutos en completar esto:
R1: T1
R2: T2
R3: T3
R4: --
R5: --
R6: --
R7: --
R8: --
R9: --

2.- E envía T4 a R4, T5 a R5 y T6 a R6. Mientras tanto, R1 envía T1 a R2, R3 y R4; R2 envía T2 a R1, R3 y R4; R3 envia T3 a R1, R2 y R4. Esta fase dura 32 minutos:
R1: T1,T2,T3,T4
R2: T1,T2,T3,T4
R3: T1,T2,T3,T4
R4: T1,T2,T3,T4
R5: T5
R6: T6
R7: --
R8: --
R9: --

3.- E envía T7 a R7, T8 a R8 y T9 a R9. Mientras tanto, R1 envía T1 a R5, R6 y R7; R2 envía T2 a R5,R6 y R7; R3 envia T3 a R5, R6 y R7; R4 envía T4 a R5, R6 y R7; R5 envía T5 a R1, R2 y R3; R6 envía T6 a R1, R2 y R3. Esta fase dura 32 minutos:
R1: T1,T2,T3,T4,T5,T6
R2: T1,T2,T3,T4,T5,T6
R3: T1,T2,T3,T4,T5,T6
R4: T1,T2,T3,T4
R5: T1,T2,T3,T4,T5
R6: T1,T2,T3,T4,T6
R7: T1,T2,T3,T4,T7
R8: T8
R9: T9

4.- E envía T7 a R1, T8 a R2 y T9 a R3. Mientras tanto, R1 envía T1 a R8 y R9 y envía T5 a R4; R2 envía T2 a R8 y R9 y envía T6 a R4; R3 envia T3 a R8 y R9, y T6 a R5; y así sucesivamente. Si completas todos los envíos posibles (que no desgloso por no liar mas todavía la cosa pero está claro como seguir), verás que todos tienen ya todos los trozos.
R1: T1,T2,T3,T4,T5,T6,T7,T8,T9
R2: T1,T2,T3,T4,T5,T6,T7,T8,T9
R3: T1,T2,T3,T4,T5,T6,T7,T8,T9
R4: T1,T2,T3,T4,T5,T6,T7,T8,T9
R5: T1,T2,T3,T4,T5,T6,T7,T8,T9
R6: T1,T2,T3,T4,T5,T6,T7,T8,T9
R7: T1,T2,T3,T4,T5,T6,T7,T8,T9
R8: T1,T2,T3,T4,T5,T6,T7,T8,T9
R9: T1,T2,T3,T4,T5,T6,T7,T8,T9

Hemos empleado 4 ciclos de 32 minutos = 2:08 horas, esta vez al limitar los slots y los trozos tanto ya no hay pausas. Si planteas una distibución YDM igual, tienes 90Mb a 128Kbs, por lo que tardas 1:36 horas. Si lo quieres de otra forma, YDM tarda 3T mientras que BT tarda 4T (y tu has puesto 9T contra 14T, parece que no se parecen en mucho)

No tengo problemas en reconocer que en este supuesto YDM sería mas rápido, has ganado una diferencia de tiempo de 32 minutos, 1 ciclo, que es lo que se tarda en distribuir el último paquete entre todos los participantes de un BT (lo que en mi ejemplo incial era la parte fraccionaria del último ciclo, que igualaba las cosas).

Ya lo has conseguido, has restringido tanto las cosas a tu favor, que me rindo, mira chico los telecos sois la ostia, le pegais palizas en mates a cualquiera, vuestra combinatoria es la repera, suplico humildemente que me perdones la vida, y renuncio a usar la mierda de sistema ese ¿se llama BitTorrent? para descargar ficheros de 90 Megas, cuando los slots de salida están restringidos a 3 por usuario (caso que encontraremos el 99% de las veces).

Pero espera un segundo, si tu restringes las cosas a tu favor, ¿quizá yo también pueda usar el mismo truco?.

Supongamos la misma distribución por YDM, si para un fichero de 700Mb tardas 17 horas como mínimo, cuando teóricamente serian posible en 12:30 horas, esa diferencia debe ser la pausa entre paquetes. Calculando salen que hay una pausa de unos 2 minuto para sincronismos. Si mantenemos eso en este ejemplo, con 90Mb hay 18 paquetes, por 2 minuos de espera, salen los 36 minutos que has ganado antes. Coñe, otra vez iguales. Si aumento un poco mas las pausas (y creo que realmente se tardan unas 19 horas en una YDN, no 17 como he supuesto), ya gano.

Pero mejor aun, supongamos que dos amigos se ponen de acuerdo para lanzar a la vez una distribución que ya se han intercambiado en mano o por correo (¿acaso sería tan raro eso?). Si calculamos los tiempos por YDM, tarda lo mismo, solo 1 puede enviar. Si lo hacemos por BT duplicamos la velocidad de los servidores y acabamos antes (¿quieres que te lo calcule?).

Podemos seguir y seguir, buscar ejemplos restrictivos o favorables, pero no conduce a nada. Ambos métodos son, teóricamente, practicamente iguales en velocidad, quieras o no reconocerlo.

[EL-MEJOR]

Hola:
4.- E envía T7 a R1, T8 a R2 y T9 a R3. Mientras tanto, R1 envía T1 a R8 y R9 y envía T5 a R4; R2 envía T2 a R8 y R9 y envía T6 a R4; R3 envia T3 a R8 y R9, y T6 a R5; y así sucesivamente. Si completas todos los envíos posibles (que no desgloso por no liar mas todavía la cosa pero está claro como seguir), verás que todos tienen ya todos los trozos.
R1: T1,T2,T3,T4,T5,T6,T7,T8,T9
R2: T1,T2,T3,T4,T5,T6,T7,T8,T9
R3: T1,T2,T3,T4,T5,T6,T7,T8,T9
R4: T1,T2,T3,T4,T5,T6,T7,T8,T9
R5: T1,T2,T3,T4,T5,T6,T7,T8,T9
R6: T1,T2,T3,T4,T5,T6,T7,T8,T9
R7: T1,T2,T3,T4,T5,T6,T7,T8,T9
R8: T1,T2,T3,T4,T5,T6,T7,T8,T9
R9: T1,T2,T3,T4,T5,T6,T7,T8,T9

Este ciclo es imposible. En el ciclo anterior entre todos tienen 39 partes y en éste se supone que acaban con 81. Puesto que en un ciclo cada participante puede subir 3 partes y sólo hay 10 participantes (9 down + el uploader), a lo máximo que se llegaría a tener en este ciclo sería 69 partes (39 que habían en el ciclo anterior más 3 * 10 de este ciclo).

Hemos empleado 4 ciclos de 32 minutos = 2:08 horas, esta vez al limitar los slots y los trozos tanto ya no hay pausas. Si planteas una distibución YDM igual, tienes 90Mb a 128Kbs, por lo que tardas 1:36 horas. Si lo quieres de otra forma, YDM tarda 3T mientras que BT tarda 4T (y tu has puesto 9T contra 14T, parece que no se parecen en mucho)

Esto es una forma de hablar. Estás reconociendo que el YDM tarda un 25% menos si lo tomamos sobre el tiempo del BT o un 33% más si tomamos como referencia el tiempo que le asignas al YDM. Además, si contamos el tiempo adicional necesario para completar la descarga la diferencia es más que apreciable.

NOTA: He dado por hecho que los 10 participantes pueden enviar 3 partes en el cuarto ciclo, aunque eso habría que comprobarlo primero, ya que se podría dar la situación de que alguno no pudiera enviarlas completas.

[javu61]

Hola a todos:

Primero, estaba tan centrado en el análisis del sistema BT, que olvidé por completo analizar un poco mas a fondo del YDM. Vamos a repetir un poco el análisis:

- En T1 el que hace de servidor envía el trozo 1, pero hasta que no esté compelto no puede ser descargado por los destinatarios.

- En T2 el que hace de servidor envía el trozo 1, y los destinatarios reciben en trozo 2.

.......

- En Tn el servidor envía el trozo n, y los destinatarios reciben el trozo n-1.

- En Tn+1 el servidor está parado, y los destinatarios reciben el tozo n.

Por lo tanto, una distribución YDM de n trozos, requiere n+1 ciclos, no n tal y como había planteado.

De mi análisis del BT con restricciones:

Este ciclo es imposible. En el ciclo anterior entre todos tienen 39 partes y en éste se supone que acaban con 81. Puesto que en un ciclo cada participante puede subir 3 partes y sólo hay 10 participantes (9 down + el uploader), a lo máximo que se llegaría a tener en este ciclo sería 69 partes (39 que habían en el ciclo anterior más 3 * 10 de este ciclo).

Gracias por la corrección, pero me he equivocado en una cosa, en el ciclo 2 T7,T8 y T8 acaban sin nada, por lo que no contribuyen en el siguiente ciclo. Si cambio el orden de las cosas ligeramente, de forma que T1, T2 y T3 envíen a estos tres que están sin nada, en la siguiente fase ya contribuyen, y terminamos en 4 fases.

No hay mas vuelta de hoja, el tiempo en estas condiciones tan restringidas siempre será de medio ciclo mas que en el YDM, porque se necesita el mismo tiempo para enviar el fichero completo, mas un ciclo para repartir la última parte. En el ejemplo propuesto en tres ciclos se envía un fichero completo por el servidor, y el ultimo ciclo sirve para acabar de distribuir todo entre todos.

Igual que en el ejemplo inicial mio sin tantas limitaciones, con ciclos de dos fases, si quieres ser muy muy realista, habrá una serie de personas que completaran en la primera fase del ciclo X, y otros que acabarán en la primera fase del ciclo X+1, la media se queda al final de la segunda fase del ciclo X, mientras que en YDM con N trozos siempre será N+1 ciclos

Y siendo mas generales todavía, el tiempo mínimo que se tarda en cualquier distribucón será siempre el que le cueste enviar al servidor una vez completa el fichero, mas el tiempo de distribuir el último envío entre todos, por lo que, si no cambia este planteamiento (cosa que no admiten sistemas no P2P como YDM, NEWs o FTP, pero si sistemas P2P como el BT), no se puede ir mas rápido, solo mas lento.

NOTA: He dado por hecho que los 10 participantes pueden enviar 3 partes en el cuarto ciclo, aunque eso habría que comprobarlo primero, ya que se podría dar la situación de que alguno no pudiera enviarlas completas.

Pues no des nada por hecho, simplemente lee el enunciado del problema, estamos en un mundo perfecto y todo funciona de la mejor manera siempre, si cambias este pequeño principio, ya no hablamos de lo mismo, y eso es lo fundamental en este análisis, es teórico.

Si empezamos a ver que el mundo no es perfecto, ¿que pasa si el que comienza una YDM tiene problemas momentaneos con un paquete?, pues que ese paquete no llega a su destino, pero es que además puede darse el caso de que ese paquete desincronice todo el resto del envío.

Y no olvidemos otro dato importante que falsea por completo este análisis teórico, estamos planteando que todos empiezan a la vez, obligatorio en YDM. Si tu te enteras de una distribución YDM tarde, o el que envía por error no te mete en la lista de destinatarios, te has quedas sin nada. Si te enteras tarde de un BT, no pasa nada, empiezas cuando puedes. Creo que esa es una gran ventaja del BT sobre el YDM.

Y plantearos lo último que he dicho muy en serio, ¿que pasa si en lugar de uno, se ponen dos o tres a la vez a enviar por BT?, cuando este sistema se difunda un poco, no dudeis que esto empezará a ocurrir, y veremos resultados sorprendentes en velocidad de distribución.

Jose Antonio

[calvicius]

añado sobre el tema de las subidas en BT.
alguna vez hemos hecho entre dos o tres, pasarnos una peli gorda, en el tracker particular su propia máquina de uno cualquiera, fuera del oficial, claro, y luego publicar los tres o cuatro a la vez.
no veais como fructifica. en 24 horas más de 50 personas
edito: 50 personas completadas, más los que andan a medias.

[javu61]

Hola:

Para que no me vengais con que no reconozco mis errores, aquí está el análisis del BT para 3 slots corregido, mas uno con 4 y otro con 5 slots.

Vamos con análisis de varias situaciones posibles, partiendo del supuesto de que hay 9 trozos que subir por un emisor (E) a 9 receptores. Hay que repartir 81 trozos en total.

A. Limitados todos a 3 slots de subida (en mínimo en BT son 4 para ADSL y 2 para modem normal).

1.- Solo envía E, se distribuyen tres trozos
2.- Envían E y los tres primeros, se pueden enviar 12 trozos, tenemos 15 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 30 trozos, tenemos 45 trozos servidos
4.- Todos tienen ya trozos, se pueden enviar 30 trozos, tenemos 75 trozos servidos
5.- Servimos los 6 trozos para los 81 totales.

Ocupamos un tiempo adicional, en el que podemos repartir 24 trozos adicionales.

B. Limitados todos a 4 slots de subida (mínimo del BT para ADSL)

1.- Solo envía E, se distribuyen 4 trozos
2.- Envían E y los 4 primeros, se pueden enviar 20 trozos, tenemos 24 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 40 trozos, tenemos 64 trozos servidos
4.- Todos tienen ya trozos, se pueden enviar 40 trozos, tenemos 81 trozos

Ahora hay tiempo para servir 23 trozos adicionales, holgura sobrada

C. Limitados todos a 5 slots de subida (mi mula tiene esos 5 slots, yo no limito subidas)

1.- Solo envía E, se distribuyen 5 trozos
2.- Envían E y los 5 primeros, se pueden enviar 30 trozos, tenemos 35 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 50 trozos, tenemos 85 trozos servidos

Ahora hay un ciclo menos y tiempo para servir 5 trozos adicionales.

Si vamos variando las condiciones, vamos obteniendo resultados diferentes, eso el lógico, si pones condiciones muy restrictivas, todos los sistemas salen perdiendo, conforme nos acercamos a su punto óptimo, todos se aceleran.

Jose Antonio

[xaniox]

Para que no me vengais con que no reconozco mis errores...

A estas alturas te aseguro que nadie te lo recriminará, ¿o es que alguien es capaz de leerse enteritos los posts?

[torpedorr]

Bien, debo decir algo en tu favor javu61.

Se ve q lo has analizado con detalle (gracias), le has dedicado mucho tiempo y esfuerzo, y voy a ignorar las puyas q sigues meitendo (y q yo tb te he metido en respuesta a las tuyas).

Empezare por decirte q en tu modelo inicial, aparte del error detectado por EL-MEJOR, hay alguno mas. Normal, yo tuve q repetir el modelo varias veces pq tambien la cagaba y no tiene mas importancia.

Al final del hilo, te podre la correccion para q se la salte quien quiera, es tan solo un detalle q te ha llevado a concluir q eran 12t en vez de 14t. Da lo mismo.

Ya me pongo en plan serio, veo q eres una persona (dejando las formas q empleas) q se toma las cosas en serio y las analiza. Mi interes es reorientarte en tu interpretacion de todo lo posteado, creo q se te han pasado varias cosas q son importantes desde el primer momento.

Nos ponemos a ello????

Pregunta: ¿porque no usar BT para distribuir pelis clásicas?.

En ningun caso he dicho q no se hiciera. A medida q lo analizo, cada vez me parece "mejor" en cuanto a efectividad (cosa q ya dije en posteos anteriores).

Y plantearos lo último que he dicho muy en serio, ¿que pasa si en lugar de uno, se ponen dos o tres a la vez a enviar por BT?

Evidentemente, ahi BT gana en efectividad (como cualquier P2P). De ahi nuestro interes de difundir varias fuentes completas (mediante YDM) para entrar en emule con eficacia.

Si vamos variando las condiciones, vamos obteniendo resultados diferentes, eso el lógico, si pones condiciones muy restrictivas, todos los sistemas salen perdiendo, conforme nos acercamos a su punto óptimo, todos se aceleran.

Es evidente, cualquier modificacion de las condiciones iniciales es importante y cambia los resultados.

Pues bien, vamos a hacer un analisis reposado del porque de cada cosa. A estas alturas tenemos ya varias cosas asumidas:

- YDM es mas vulnerable.

- BT aumenta su efectividad a mas fuentes iniciales y con el transcurso del tiempo.

- Las condiciones iniciales estan "manipuladas" segun mi interes.

Pero porque??? Pues simplemente, pq le damos un enfoque diferente segun nuestras circunstancias y necesidades.

* Yo soy un uploader, me interesa distribuir el fichero a la gente de mi grupo de una forma rapida y eficaz, me interesa q los ficheros anteriores del grupo se sigan distribuyendo en emule (downloaders sigan siendo fuentes completas en emule), todos los miembros tenemos conexiones similares, todos podemos dejar el pc abierto.....

* Tu sin embargo, partes de otras condiciones iniciales e intereses. Puedes entrar en plena fase de una pre-distribucion BT. No perteneces a un grupo de distribucion y suponemos q no tienes esos intereses (evidente) como downloader "ajeno" al grupo. Tu no puedes mantener la conexion mas de 12 horas, BT te permite resumir cuando quieras......

* Mi unico interes era analizar los comportamientos en el caso q yo planteo. Quiero saber si BT me es mas eficiente q YDM (mientras funcione). Y que me encuentro????

a.- Tarda algo menos una distri YDM. Dejemoslo en q tardan lo mismo, ok? Esto me importa poco, incluso asumiria q BT fuera algo mas rapido.

b.- Estamos de acuerdo q con BT todos los downloaders dedican todos sus recursos a la pre-distribucion. Ok? Por lo tanto, con BT todos los downloaders de mi grupo cierran el emule y solo se dedican a BT. Acaba la pre-distribucion y todos lo completan, genial.

c.- Mediante una distri YDM siguen con emule (aunq restringido). El hecho de estar recibiendo no les impide seguir descargando sus ficheros, y siguen subiendo pero a otros usuarios emule. No debo pedirles q se dediquen en "exclusiva" a pre-distribuir. Entre todos los participantes siguen enviando trozos de distribuciones anteriores mediante emule hacia la red.

Fijate q para nuestro caso, el punto c es vital (y BT no nos lo permite, asumiendo q tardaran lo mismo).

Entiendes pq digo q es menos efectivo?????

Solo desde este punto de vista particular, tanto para uploaders como downloaders del grupo de pre-distribucion.

El punto de vista q tu usas, ya nos servira para la difusion posterior del fichero..... ya sea mediante emule o cualquier P2P. Una vez estemos en la mula, cualquier usuario q no sea del grupo podra bajar mejor, con muchas fuentes completas (o casi) y apagar su pc cuando quiera.

En ningun momento, en el fragor de la "batalla", has hecho mencion a este hecho. Bueno, si, dijiste q los downloaders BT subian tambien 24,4 Gigas, pero sin hacer distinciones de si era entre ellos o hacia la comunidad.

Y ya dejo de aludirte, hasta el final de este posteo en el q corregire los fallos de tu modelo (a pesar de q soy tan malo en mates , permiteme la puyita).

Vamos a ver, si tú admites que tiscali envía más rápido que todos los usuarios juntos, no hay nada que discutir (supongamos que tiscali enviara a 1MB/s y hubieran 10 usuarios que pudieran subir a 12KB/s con lo que en el mejor de los casos, cuando los 10 estuvieran enviando, sería 120KB/s; muy por debajo del 1MB/s de tiscali). Está claro que así el método YDM arrasaría con el BT.

Vamos a ver, sigues enfocandolo mal.... y no se si podre hacertelo ver (Diosssss, me da un noseque corregirte pq tu si q eres un crack).

Olvidate de numeros. No hables de KB/s. Es evidente q el upload de todos los usuarios podria ser mayor q el ancho de Tiscali. Pero es q.... hay una limitacion.

El uploader, unico q tiene el fichero completo en nuestro caso, debe ir repartiendo trozos. Por mucho ancho de banda q tengan los downloaders y muy rapido q intercambien, la veloc de subida del uploader es la q lo limita todo.

En cualquier periodo de tiempo, aceptamos q mientras el uploader envia trozos nuevos los downloaders pueden intercambiar mas rapido. Pero, mientras no haya trozos nuevos, estaran parados... me entiendes???

Debo acudir ya a los ejemplos.... supongamos un fichero con 100 trozos. Da igual a cuantos se envie cada vez, incluso te acepto q algun downloader tenga un T3 de subida!!!!! Los downloaders suben sus trozos a velocidades puntuales de vertigo, pero en cuanto mas rapido suban entre ellos antes se quedaran sin material por repartir y en reposo.

De este modo, la velocidad media de intercambio de trozos entre downloaders siempre sera menor q la del uploader (q es quien realmente limita todo).

El uploader debe subir los 100 trozos x lo menos una vez y hasta 100t no acabara. Da igual q intercambien entre ellos a velocidad de la ostia.

Si pej ha subido en el periodo 2 los trozos 4, 5 y 6 y en el periodo 3 sube 7, 8 y 9. Los trozos 1, 2 y 3 ya estan repartidos, y asumimos q los 4, 5 y 6 se reparten a velocidades de vertigo. Hasta q el uploader no acabe de subir los 7, 8 y 9, todos los downloaders estarian parados (todos tienen ya los trozos del 1 al 6).

No se explicarlo ya mas claro...

Lo mismo ocurre con el tamaño del archivo, cuanto más grande sea éste más fácil es que BT ganase.

Vuelvo al razonamiento anterior..... por muy grande q sea el trozo, el uploader debe subirlos todos (da igual 70 subidas de 10 megas q 350 de 2 megas). HAsta q no ha subido x lo menos 1 vez cada trozo, es imposible q completen todos.

No es lo mismo que hayan 10 personas descargando de tiscali a 15KB/s a que sean 300.

Esa es una limitacion teorica q seguro q existe, pero q nunca se ha dado.

Hasta en las distribuciones con mas downloaders (50) todos han bajado a ritmo mayor del q subo (128). Eso nos da un minimo necesario de 6,25 gigas de download de Tiscali, pero creo q debe ser aun mayor.

Cierto es q si en vez de enviar con adsl 256 y ser 50, enviara con adsl 2Mb y fueramos 10000, llegariamos a la situacion de q Tiscali no diera para mas. No se aun donde esta su limite.

Pero esto lo deberías saber tú mejor que yo ¿o es que no hay días en los que tiscali se atraganta y se alargan las distribuciones? ¿No hay gente que pierde correos? Tiscali no es omnipotente y tiene sus limitaciones.

Pues si, Tiscali tiene dias malos...

Sin embargo, nunca en cuianto a velocidad de bajada. Los problemas q suele dar son de otro tipo:

1.- Ultimamente, el bit de confirmacion al terminar un envio no lo manda. Eso hace q el script se quede a la espera (genera retraso) y acabe por no mover el trozo de carpeta.

2.- En algun momento, da problemas de conexion al uploader. Eso implica q no pueda enviar por el motivo q sea. Hay dias q no pasa, otros dias pasa durante 10 min de las 17 horas, en algun dia (el peor) una distri se ha ido a 24 horas.

3.- El problema de perdida de correos suele darse pq el downloader apura demasiado (no reserva suficiente ancho de banda) y acumula correos. Jamas he visto (en mi caso) q bajara lento teniendo ancho suficiente disponible en mi conexion.

De todos modos, seguro q habria un limite. Ya comente en posteos anteriores q serian impensables 20 distribuciones simultaneas, y 500 o 100 downloaders en total.

4.- Tambien en un par de ocasiones la maquina de Tiscali ha dado problemas en cuanto a la replica de los correos. Quiero decir, un correo enviado suele estar disp para bajar a los 2 segundos en todas las ctas de correo. En 2 ocasiones, pasaban quiza 20 minutos en los q yo enviaba, nadie tenia correos x descargar, y le aparecian 5 de golpe en la cta de correo (pero weno, 2 veces en unas 500 distribuciones hechas son pocas).

Y nada mas de momento, os propongo a tod@s seguir este hilo por el camino del respeto y la educacion, vale???

Olvidemos puyas anteriores y centremonos solo en el analisis de los datos y el enfoque de este caso particular.

Salu2.

************************************************************

Errores en el analisis de javu61.

Son varios, y logicos si se va deprisa al desarrollar el proceso. Ya no pretendo darte puyas ni lecciones, ni tan solo demostrar q se mas q nadie. Solo pretendo q lo veas, detectes tu error, y verifiques si yo he cometido alguno.

Repito despacito a ver si queda claro. En cada ciclo BT del ejemplo existen dos fases, una en que solo envía el lanzador 1 paquete a todos, y otro en que todos se intercambian entre sí 10 paquetes, osea que en cada ciclo se intercambian 11 paquetes de 10Mb = 110Mb por ciclo, y 700/110 = 6.36 ciclos, redondeamos a 7. La parte fraccionaria la empleará el sistema en repartir entre todos el último trozo que le falta enviar al emisor y repartirlo entre todos.

Los numeros q haces son erroneos. Partes de la base en q deben circular 700 megas, y ahi te equivocas.

Se ve mas facilmente si, en vez de hablar de paquetes, hablamos de trozos, ok????

Si el uploader tiene 70 paquetes, y hay 10 downloaders, al final del proceso entre todos los downloaders deben tener 700 paquetes.

- En T1, solo circulan 10 paquetes. Los envia el uploader.

- En T2, circulan 100 (y no 110). El uploader envia 10 nuevos, y los downloaders envian 90 (cada uno ya tenia uno, y lo envia a los otros 9).

- En T3 tambien son 100, al igual q en T4... T7.

- En T8 el uploader ya no envia paquetes nuevos, y solo se intercambian los 90 de los downloaders.

Se cumple q en T1+T2...+T8 circulan 700 paquetes (10+100+100+100+100+100+100+90).

Pues si crees que poner un calculo y dar una cifra EXACTA no es suficiente...tu mismo. Y la multipicación de velocidad se cumplirá, pero no en estas condiciones, sino en cuanto uno complete el ficheo y tengamos dos emisores se multiplica, luego completan tres y volvemos a multiplicar, y así. Si la distribución dura mas de 12 horas, los que se apunten después irán a mucha mas velocidad, llegando poder bajar en unas 8 horas.

Tienes toda la razon, pero te sales totalmente de las condiciones del analisis. Pasado el tiempo de la distribucion, cuando BT mas aceleraria (con downloaders nuevos ajenos al grupo) nosotros ya estamos en emule en circunstancias similares. Todos hemos completado, y emule se encarga de distribuir.

1.- ¿Cuanto se engordan los paquetes?, en BT aproximadamente cada parte necesita 1Kb de información redundante, y hay 70 paquetes, total 0.07Mb, ¿y en YDM?, cada paquete de 5Mb necesita por lo menos 500Kb, y hay 140 paquetes, total 68.4Mb.

2.- ¿Cuanto tiempo de espera existe entre paquetes?, en YDM será de unos 2 minutos entre paquetes (sbre un tiempo de 17 horas reales), en BT no puede existir, ya que tenemos teóricos tiempos de espera al final de cada ciclo, en el que se pueden hacer muchas cosas.

3.- ¿Cuanto ancho de banda concede TISCALI al mail?, cifra desconocida, que además variará a ratos. En BT el ancho de banda es el de cada miembro de la distribución, por lo que podemos considerarlo fijo.

4.- ¿Que pasa cuando un paquete llega erroneo?. En YDM lo pierdes y debes recuperar por la mula, en BT se auto-recupera, y como hay teóricamente descansos entre ciclos, mira por donde tenemos tiempo hasta de bajar otra vez el trozo sin penalizar el total.

1.- YDM engorda los ficheros un 4%. Es decir, para enviar un fichero de 700 megas se envian 728 megas en trozos.

2.- El script q gobierna el mailer admite tiempos de espera. Nunca los usamos, siempre esta a cero.

Hay esperas "no buscadas" generadas por establecimientos de conexiones a Tiscali, transferencia de informacion necesaria (direcciones de los downloaders), comprobacion del SMTP de esas direcciones.... digamos q en un dia normal, de 10 a 15 segundos entre envio y envio.

En las 17 horas estan ya incluidos estas esperas.

3.- Tiscali, como ya dije antes, en cuanto a bajada nunca ha ido mal (hasta hoy). Ha dado otros problemas (quiza peores) en alguna ocasion, afortunadamente pocas veces (en 2 distribuciones de 500 tuvimos problemas graves q convirtieron las 17 horas en 24, en unas 40 o 50 distribuciones problemas leves q retrasan la distri 30 min, el resto de veces de perlas).

4.- Raramente llega un paquete erroneo. Y, si llega, segun el caso es mas grave o no.

Si el paquete erroneo ha salido del uploader, no queda mas remedio q reenviarlo. Si lo ha descargado corrupto 1 downloader y los demas ok, este downloader completara por emule.

Y vamos con el nuevo análisis de la situación planteada. 9 trozos que subir de 10Mb cada uno (T1-T2...T9), un emisor (E) y 9 receptores (R1-R2-R3...R9), líneas de 256/128 pero limitados todos a 3 slots de subida.

1.- E envía T1 a R1, T2 a R2 y T3 a R3. Ha tardado 32 minutos en completar esto:
R1: T1
R2: T2
R3: T3
R4: --
R5: --
R6: --
R7: --
R8: --
R9: --

2.- E envía T4 a R4, T5 a R5 y T6 a R6. Mientras tanto, R1 envía T1 a R2, R3 y R4; R2 envía T2 a R1, R3 y R4; R3 envia T3 a R1, R2 y R4. Esta fase dura 32 minutos:
R1: T1,T2,T3,T4
R2: T1,T2,T3,T4
R3: T1,T2,T3,T4
R4: T1,T2,T3,T4
R5: T5
R6: T6
R7: --
R8: --
R9: --

3.- E envía T7 a R7, T8 a R8 y T9 a R9. Mientras tanto, R1 envía T1 a R5, R6 y R7; R2 envía T2 a R5,R6 y R7; R3 envia T3 a R5, R6 y R7; R4 envía T4 a R5, R6 y R7; R5 envía T5 a R1, R2 y R3; R6 envía T6 a R1, R2 y R3. Esta fase dura 32 minutos:
R1: T1,T2,T3,T4,T5,T6
R2: T1,T2,T3,T4,T5,T6
R3: T1,T2,T3,T4,T5,T6
R4: T1,T2,T3,T4
R5: T1,T2,T3,T4,T5
R6: T1,T2,T3,T4,T6
R7: T1,T2,T3,T4,T7
R8: T8
R9: T9

4.- E envía T7 a R1, T8 a R2 y T9 a R3. Mientras tanto, R1 envía T1 a R8 y R9 y envía T5 a R4; R2 envía T2 a R8 y R9 y envía T6 a R4; R3 envia T3 a R8 y R9, y T6 a R5; y así sucesivamente. Si completas todos los envíos posibles (que no desgloso por no liar mas todavía la cosa pero está claro como seguir), verás que todos tienen ya todos los trozos.
R1: T1,T2,T3,T4,T5,T6,T7,T8,T9
R2: T1,T2,T3,T4,T5,T6,T7,T8,T9
R3: T1,T2,T3,T4,T5,T6,T7,T8,T9
R4: T1,T2,T3,T4,T5,T6,T7,T8,T9
R5: T1,T2,T3,T4,T5,T6,T7,T8,T9
R6: T1,T2,T3,T4,T5,T6,T7,T8,T9
R7: T1,T2,T3,T4,T5,T6,T7,T8,T9
R8: T1,T2,T3,T4,T5,T6,T7,T8,T9
R9: T1,T2,T3,T4,T5,T6,T7,T8,T9

Hemos empleado 4 ciclos de 32 minutos = 2:08 horas, esta vez al limitar los slots y los trozos tanto ya no hay pausas. Si planteas una distibución YDM igual, tienes 90Mb a 128Kbs, por lo que tardas 1:36 horas. Si lo quieres de otra forma, YDM tarda 3T mientras que BT tarda 4T (y tu has puesto 9T contra 14T, parece que no se parecen en mucho)

FIjate q partes de un error grave en el segundo periodo de tiempo. T4, no pueden tenerlo R1...R3

Segun tu modelo, la evolucion de los trozos es despues de cada periodo de tiempo la siguiente:

3, 18, 39, 81 (de interv de tiempo 1 a 4)

La distribucion q yo puse, tambien tenia mal en 2º periodo pero con una diferencia fundamental: mi error fue al contar al final, no desencadenaba envios erroneos en los calculos..

Asi, los trozos despues de cada intervalo de tiempo seria;

Int 1 --> 3 trozos (solo sube el uploader)

Int 2 --> 15 trozos (6 de U + 9 de intercambio)

Int 3 --> 36 trozos (9 de U + 27 de intercambio)

Int 4 --> 63 trozos (9 de U + 27 de intercambio) <--- uploader ya no envia

Int 5 --> 81 trozos (Int5 es mas corto, solo circulan 18 trozos)

Como veras, son 4 periodos completos (a los yo llame T=3t) y el ultimo mas corto. Por una simple regla de 3, si en un periodo T (cuando el uploader ha acabado) se envian 27 trozos entre los 10 usuarios, si son 18 necesitamos 2/3T.

Sumando todos los periodos, tienes 4T + 2/3T = 14/3T

Como T=3t --> 14/3T = 14t = tiempo total

(fue mi respuesta q tu dices es erronea, como veras no lo es).

-------------------------------------------------------------------------------------

Paso a los demas modelos q has planteado. Tambien hay algun fallo. Parto de las mismas condiciones de salida q tu:

Código: Seleccionar todo

 Vamos con análisis de varias situaciones posibles, partiendo del supuesto de que hay 9 trozos que subir por un emisor (E) a 9 receptores. Hay que repartir 81 trozos en total. 

A partir de aqui expones varios modelos q te analizo debajo de cada uno:

A. Limitados todos a 3 slots de subida (en mínimo en BT son 4 para ADSL y 2 para modem normal).

1.- Solo envía E, se distribuyen tres trozos
2.- Envían E y los tres primeros, se pueden enviar 12 trozos, tenemos 15 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 30 trozos, tenemos 45 trozos servidos
4.- Todos tienen ya trozos, se pueden enviar 30 trozos, tenemos 75 trozos servidos
5.- Servimos los 6 trozos para los 81 totales.

1.- Calculo correcto.

2.- Calculo correcto.

3.- Mal.

En los 2 periodos de tiempo anteriores, E ha enviado 3 trozos cada vez. En total 6. Mientras E envia los trozos nuevos, solo 6 pueden intercambiar.
Por lo tanto, los archivos q circulan son 21 (E envia 3, y los 6 downloaders tambien)

En total tenemos 36 (como ya habia indicado antes)

4.- Mal.

E ya ha terminado y no envia. Solo hay intercambios (entre los 9 downloaders) y se reparten 27 trozos.

Como ya indicaba anteriormente, al final de este periodo hay 63 trozos.

5.- Mal.

Quedan 18 de los 81 trozos por repartir, q se reparten en 2/3T (siendo T el valor de 1 periodo completo, igual a 3t).

Seguimos concluyendo (las matematicas no fallan x muchas vueltas q les des) q en total tardamos:

4T + 2/3T = 14/3T = 14t (recuerda q T=3t ).

Paso al siguiente modelo.

B. Limitados todos a 4 slots de subida (mínimo del BT para ADSL)

1.- Solo envía E, se distribuyen 4 trozos
2.- Envían E y los 4 primeros, se pueden enviar 20 trozos, tenemos 24 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 40 trozos, tenemos 64 trozos servidos
4.- Todos tienen ya trozos, se pueden enviar 40 trozos, tenemos 81 trozos

1.- correcto.

2.- correcto.

3.- Mal

Hay 1 downloader q aun no tiene trozo (D9). Pero eso cambiara pronto, asi q subdividiremos este periodo de tiempo en 2.

3.1.- En T/4, E envia al ultimo. En ese periodo, los 8 restantes intercambian 8 trozos (1 cada 1).

En total, tenemos 33 trozos (24+9).

3.2.- Para no cambiar de escala, tomaremos este periodo 3/4T q es lo q nos falta para completar T.

Como ya todos pueden intercambiar (menos E q ha terminado), sabiendo q en T cada uno envia 4 trozos, en 3/4T envia 3.

Como hay 9, son 27 trozos en este subperiodo.

En total, en este punto, tenemos 60 trozos (y no 64).

4.- Faltan 21 trozos por repartir.

Igual q antes, asumiendo q entre todos enviarian 36 trozos en T, para enviar 21 tardarian 21/36T, o lo q es lo mismo 7/12 T

Sumamos los 4 periodos, pero teniendo en cuenta q ahora T=4t.

Asi serian 3 T + 7/12T ----> 3.583 T = 14.333 t

Se acerca mucho al resultado del analisis anterior, en q T=14t

Y paso al ultimo modelo.

C. Limitados todos a 5 slots de subida (mi mula tiene esos 5 slots, yo no limito subidas)

1.- Solo envía E, se distribuyen 5 trozos
2.- Envían E y los 5 primeros, se pueden enviar 30 trozos, tenemos 35 trozos servidos.
3.- Todos tienen ya trozos, se pueden enviar 50 trozos, tenemos 85 trozos servidos

Vuleve a ser un analisis inexacto, analicemos porque:

1.- Correcto.

2.- Mal.

Aqui volvemos a subdividir este periodo en 2 subperiodos:

2.1- Tiempo necesario para q E termine. En este caso, al enviar solo a 4, seria 4/5T.

Mientras entran los ultimos 4 nuevos, los otros 5 intercambian 4 trozos cada uno (estamos en 4/5T, y en T envian 5 cada uno).

Los trozos q circulan en este subperiodo serian:

4 + 20 =24.

En total tenemos 5+24= 29

3.2.- Tomando 1/5T restante para no variar la escala, ya todos tienen trozos, y hay 9 downloaders. Tienen tiempo de enviar 1 cada 1, en total 9

Acabamos el 2º subperiodo con 29+9= 38

3.- Mal.

Ya todos tienen trozos, y faltan 43 por recibir.

Sabemos q entre los 9, en un periodo T pueden repartirse 45 trozos.

Para repartirse 43 trozos, necesitan 43/45T.

Por lo tanto, vamos a por el total final (teniendo en cuenta q ahora T=5t):

2 T + 43/45T ----> 2.955 T = 14.777 t




Y se acabo.

Podras verificar si le dedicas tiempo cuando puedas q las correcciones estan bien.

En todos los casos, rondan 14t cuando en una distri YDM serian 10t (añadiendo la correccion q hiciste de la ultima descarga).

Pero me da igual, seguro q en otros modelos ambas cifras podrian acercarse si combinaramos los slots y el nº de downloaders de otra forma, siempre limitandonos el hecho de q BT no puede tardar menos.

Insisto lo dicho arriba en el post q me interesa mas, y lo cito para q no tengas q buscarlo:

* Yo soy un uploader, me interesa distribuir el fichero a la gente de mi grupo de una forma rapida y eficaz, me interesa q los ficheros anteriores del grupo se sigan distribuyendo en emule (downloaders sigan siendo fuentes completas en emule), todos los miembros tenemos conexiones similares, todos podemos dejar el pc abierto.....

* Tu sin embargo, partes de otras condiciones iniciales e intereses. Puedes entrar en plena fase de una pre-distribucion BT. No perteneces a un grupo de distribucion y suponemos q no tienes esos intereses (evidente) como downloader "ajeno" al grupo. Tu no puedes mantener la conexion mas de 12 horas, BT te permite resumir cuando quieras......

* Mi unico interes era analizar los comportamientos en el caso q yo planteo. Quiero saber si BT me es mas eficiente q YDM (mientras funcione). Y que me encuentro????

a.- Tarda algo menos una distri YDM. Dejemoslo en q tardan lo mismo, ok? Esto me importa poco, incluso asumiria q BT fuera algo mas rapido.

b.- Estamos de acuerdo q con BT todos los downloaders dedican todos sus recursos a la pre-distribucion. Ok? Por lo tanto, con BT todos los downloaders de mi grupo cierran el emule y solo se dedican a BT. Acaba la pre-distribucion y todos lo completan, genial.

c.- Mediante una distri YDM siguen con emule (aunq restringido). El hecho de estar recibiendo no les impide seguir descargando sus ficheros, y siguen subiendo pero a otros usuarios emule. No debo pedirles q se dediquen en "exclusiva" a pre-distribuir. Entre todos los participantes siguen enviando trozos de distribuciones anteriores mediante emule hacia la red.

Fijate q para nuestro caso, el punto c es vital (y BT no nos lo permite, asumiendo q tardaran lo mismo).

Entiendes pq digo q es menos efectivo?????

Y nada mas, tomalo con calma, me ha llevado 5 horas (y 4 0 5 ediciones) escribir todo el post y analizarlo puede ser tedioso.

Salu2.

P.D: yo voy pa 36.

[ummo]

¿o es que alguien es capaz de leerse enteritos los posts?

Pues aunque mi nivel de matemáticas está a años luz, yo sí que sigo el hilo, aunque paso por encima los razonamientos matemáticos sin entrar a fondo en ellos. Muy interesante el debate.

Pero, desde mi ignorancia matemática, yo me atrevería a preguntar:

En una distri YDM yo envío 1 vez cada byte del fichero. Una vez los he enviado todos, ya he terminado. Sólo los envío 1 vez y el resto completa sin que yo tenga necesidad de enviar más veces.
Usando el BT, en cuanto enviara el mismo byte 2 veces, ya estaría duplicando envíos. Por lo tanto, cuantas más veces haya de repetir los mismos bytes, más tiempo ha de durar. ¿Esto es así o estoy equivocado? Todo esto en condiciones ideales, claro.

[torpedorr]

Usando el BT, en cuanto enviara el mismo byte 2 veces, ya estaría duplicando envíos. Por lo tanto, cuantas más veces haya de repetir los mismos bytes, más tiempo ha de durar. ¿Esto es así o estoy equivocado?

ummo, ese dato es vital para el supuesto q analizamos.

Damos x sentado q BT no repite ningun envio, algo similar al jumpstart de la mula.... y una condicion indispensable para este supuesto. BY incorpora wese control de envios, ya lo menciono algun usuario.

Si BT repitiera, ahi seguro q la cosa se disparaba. Te lo digo x experiencia.

Hace ya 2 años, intercambiabamos los ficheros entre miembros del grupo mediante edonkey (cuando estaban las vers 57 y 59). Fue una buena epoca, muy divertida... y hasta q desarrollamos el YDM era lo mejor q teniamos.

Compartiamos solo 1 fichero (como en BT), en 1 mismo server (el mio), con 1 uploader y varios downloaders.

Como edonkey si repetia envios, los numeros se disparaban de forma escandalosa (sin mencionar q al ser un chunk 18 veces mayor q en BT, el intercambio inicial se retrasaba mucho). Ademas, debido a las repeticiones, pasabamos mucho tiempo en "no need parts" y habia largos periodos sin transferencias wentre downloaders... cosa q en el modelo analizado no ocurre.

Juer, q tiempos, x aquel entonces conoci con todo este tema a kampi, latata, palidocola, dakoki..... y paro ya q empiezo a parecer el Abuelo Cebolleta.

Salu2.

[raul2010]

esto... he borrado un post repetido tuyo torpedorr (era el largo este penúltimo, pero no contenía el quote, así q he pensado q sería un error)

yo, como ummo, estoy siguiendo el hilo, saltando bastante por encima de las cuestiones más puramente técnico-matemáticas, pq me pierdo mogollón

me alegro de q vayais suavizadoos y reposando los posts, y leñe, ¡así se hacen amigos!

no sería mala idea ampliar el foro YDM a predistris en general, aunque habría q poner algo de info sobre condiciones previas de un BT en un hilo, para q todos pudieramos ceñirnos a un estandar. Tp tengo mucha idea de si la web debería contribuir con algo de infraestructura (los seeds, trackers y toda la pesca, q no se q son ) ¿q os parece?

weo, enga un saludo

[javu61]

Hola a tod@s:

Este post, siguiendo la pauta marcada útlimamente, es largo, pero no agresivo (o eso he intentado), y por otra parte, !que cojones¡, cuando discuto en un grupo de amigos (y aunque no conozco personalemnte a torpedorr, en divxclasico me siento entre amigos), unas veces te ries, pero otras te calientas, le llamas de todo, te levantas a pegarle un par de ostias, y en ese momento, te tropiezas aparatosamente, todos se rien, tu te descojonas, y empiezas a comentar lo buena que es la peli esa que visteis el último día (aunque lo que quieres decir realmente es que buena está la rubia de esa peli).

Condenso en respuestas para raul2010, torpedorr y ummo en un solo mensaje.


********************************************************************

no sería mala idea ampliar el foro YDM a predistris en general, aunque habría q poner algo de info sobre condiciones previas de un BT en un hilo, para q todos pudieramos ceñirnos a un estandar. Tp tengo mucha idea de si la web debería contribuir con algo de infraestructura (los seeds, trackers y toda la pesca, q no se q son ) ¿q os parece?

Eso sería la mejor manera de que cada uno pruebe todos los sistemas, y adopte el que mas le guste. Lo único que debería aportar la Web es un espacio para albergar un tracker. Explico unas cosas:

Peers o Leeches: Son los usuarios que se están descargando el fichero, pero todavía no lo han completado

Seed: son los usuarios que tienen el fichero completo, y puede enviar cualquier trozo. Da igual que sea el que empezó la distribución o que sea uno que ha acabado.

Nº de Copias: Es una información que proporciona el BT indicando un numero con parte entera y decimal, que indica el número de copias completas que se encuentran circulando entre todos los usuarios apuntados. Si pone por ejemplo 3.56, es que hay 3 partes completas y un 56% de partes circulando. Si en un momento dado no hay Seeds, pero hay partes completas, sabes que puedes completar la descarga con la información que hay disponible entre todos (en BT se pueden retirar los que tiene el fichero completo y aun así completarse).

Tracker: Es un sitio en que que se puede ver que descargas hay disponible, e icnlñuso en algunos como están las descargas, cuando comenzó, cuantos están haciendo de servidor y cuantos hacen de receptores, cuantos hay en cada momento, cuanto lleva descargado cada usuario, cuantas partes completas existen ya en la red, etc. Esta información puede ser mas o mwnos amplia, según desee el que monta el tracker.

Si quereis ver uno tracker en acción, pasaros por la página "http://bittorrent.nocillatv.com/" y vereis uno pequeño en cuanto a ficheros, pero con mucha información, pinchando en el número de seed o leeches os dará información mas detallada de como va la descarga. En este momento hay una que comenzó el día 17, con 11 seeds y 20 leeches (volará descargando seguramente), aunque lo normal es tener entre 1 y 3 seeds y entre 10 y 20 leeches en una descarga.

Otros tackers tienen listas muy largas de pelis (la mayoría modernas), pero no dan tanta información adicional.

********************************************************************

* Yo soy un uploader, me interesa distribuir el fichero a la gente de mi grupo de una forma rapida y eficaz, me interesa q los ficheros anteriores del grupo se sigan distribuyendo en emule (downloaders sigan siendo fuentes completas en emule), todos los miembros tenemos conexiones similares, todos podemos dejar el pc abierto.....

* Tu sin embargo, partes de otras condiciones iniciales e intereses. Puedes entrar en plena fase de una pre-distribucion BT. No perteneces a un grupo de distribucion y suponemos q no tienes esos intereses (evidente) como downloader "ajeno" al grupo. Tu no puedes mantener la conexion mas de 12 horas, BT te permite resumir cuando quieras......

* Mi unico interes era analizar los comportamientos en el caso q yo planteo. Quiero saber si BT me es mas eficiente q YDM (mientras funcione). Y que me encuentro????

a.- Tarda algo menos una distri YDM. Dejemoslo en q tardan lo mismo, ok? Esto me importa poco, incluso asumiria q BT fuera algo mas rapido.

b.- Estamos de acuerdo q con BT todos los downloaders dedican todos sus recursos a la pre-distribucion. Ok? Por lo tanto, con BT todos los downloaders de mi grupo cierran el emule y solo se dedican a BT. Acaba la pre-distribucion y todos lo completan, genial.

c.- Mediante una distri YDM siguen con emule (aunq restringido). El hecho de estar recibiendo no les impide seguir descargando sus ficheros, y siguen subiendo pero a otros usuarios emule. No debo pedirles q se dediquen en "exclusiva" a pre-distribuir. Entre todos los participantes siguen enviando trozos de distribuciones anteriores mediante emule hacia la red.

Fijate q para nuestro caso, el punto c es vital (y BT no nos lo permite, asumiendo q tardaran lo mismo).

Entiendes pq digo q es menos efectivo?????

Por partes. Lo que intentamos con ambos programas es distribuir un fichero al máximo número de personas en el menor tiempo posible, con el objetivo de que se ponga en la mula con las máximas fuentes de inicio. No tenemos objetivos diferentes, es el mismo, completar fucnets en un grupo de pre-distribución. Lo que pasa es que usamos métodos diferentes. Y si quieres ejemplos, la peli "plumas de caballo", que se está lanzando por BT, tiene actualmente mas de 100 fuentes completas en la mula. Y si miras cosas que no sean "cine clásico", como el manga, verás que su distribución se hace masivamente por BT, y en la mula hay muchas fuentes de episodios contínuamente. Lo siento, pero el BT está ganando la partida al YDM como método, ya que es mas sencillo para el que envía y para el que recibe.

Es cierto que en una YDM el ancho de banda de subida está siempre libre, mientras que en una BT solo el 50%, pero a cambio evitamos los dos problemas del YDM, el sincronismo obligatorio (todos tienen que empezar a la vez, nadie puede parar hasta que se complete) y la limitación de destinatarios (solo lo reciben los que se apunten directamente a la YDM desde el principio, y nadie mas). Todos los métodos tienen sus ventajas e inconvenientes, pero es que creo que estás negando las evidentes del BT mientra niegas los fallos del YDM.

Pongamos un ejemplo. Lanzamos una distribución durante 24 horas. Lanzas unas YDM a 50 usuarios, ancho de banda de 128Kbs/128kbs de envio y recepción (no se puede recibir mas rápido de lo que se envía), tardando 16 horas en completarla. Si quieres lanzar a otros 50 usuarios, ancho de banda de 128Kbs/128kbs, tardas otras 16 horas, por lo que no puedes completar mas que la mitad, y al cabo de 24 horas la tienen 50 personas completa y 50 personas tiene medio archivo.

Lanzamos lo mismo por BT. En 16 horas la completan 50 a 128kbs/128kbs. A partir de ese momento multiplicas por 50 tu ancho de banda de salida, por lo que todos reciben al máximo de su ancho de banda de entrada contínuamente, 6400kbs/256kbs (no puedes recibir a mas de lo que de tu línea), y tardan la midad en completar, por lo que acaban en 8 horas.

En el mismo tiempo y condiciones lo han recibido el doble de personas, y aunque existen límites para las distribuciones YDM (tienes que usar una tubería muy gorda, pero limitada), no existen en BT, puedo empezar a juntar magueras pequeñas, y hacer en total una tubería todo lo gorda que quiera.

A cambio de esto, has dejado de distribuir OTROS ficheros antíguos durante una parte del día, no es posible negarlo, aunque si han distribuido el propio fichero entre ellos mismos, eso también es compartir, por lo que realmente no es correcto que no han compartido nada, hay que decir que han compartido entre ellos ese fichero el 50% de su tiempo, y el resto de fichero el otro 50%, acabando con los mismos Gb subidos. A cambio puedes acabar teniendo mejor distribuido el fichero. Si alargamos esto entre 3, 5 o 7 días que dura una distribución YDM media, resulta que no se ha notado casi en la red que los del BT no han compartido otros fichero durante una horas mas que la mitad del tiempo que los del YDM en el mismo periodo, pero lo han recibido muchos mas.

El punto de vista q tu usas, ya nos servira para la difusion posterior del fichero..... ya sea mediante emule o cualquier P2P. Una vez estemos en la mula, cualquier usuario q no sea del grupo podra bajar mejor, con muchas fuentes completas (o casi) y apagar su pc cuando quiera.

No es correcto, ya que BT no usa el mismo principio que el eMule. El emule va por colas de espera, intercambiando varios ficheros. Aun en el caso de que en una distribución el servidor en su incoming use un solo fichero, y todos los participante en su incoming no tengan ningúnn fichero, al no estár optimizado para esta situación y mantener su configuración por colas, la mula tardará mucho en completar una distribución.

En el BT no existen colas, el sistema está concebido para comparti un solo ficheo, e intenta optimizar siempre el ancho de banda disponible, prefiere repartir tres veces al mismo usuario, antes que quedarse sin enviar nada. Esto garantíza que la velocidad de este P2P sea similar a una distribución YDM cuando arranca, pero también garantiza que conforme completen la distribución mas usuarios, más rápido funcionará.

Vamos a ver, si tú admites que tiscali envía más rápido que todos los usuarios juntos, no hay nada que discutir (supongamos que tiscali enviara a 1MB/s y hubieran 10 usuarios que pudieran subir a 12KB/s con lo que en el mejor de los casos, cuando los 10 estuvieran enviando, sería 120KB/s; muy por debajo del 1MB/s de tiscali). Está claro que así el método YDM arrasaría con el BT.

Olvidate de numeros. No hables de KB/s. Es evidente q el upload de todos los usuarios podria ser mayor q el ancho de Tiscali. Pero es q.... hay una limitacion.

El uploader, unico q tiene el fichero completo en nuestro caso, debe ir repartiendo trozos. Por mucho ancho de banda q tengan los downloaders y muy rapido q intercambien, la veloc de subida del uploader es la q lo limita todo.

Perdona, pero no es así exactamente. Evicentemente el tiempo de distribución sera el que tarde el uploader en suboir el fichero, mas lo que tarden los downloaders en descargar el último trozo. Eso está claro, y es el límite teórico.

El servidor sube los trozos a 128kbs, que es su máximo de ancho de banda, pero luego hay 50 usuarios que están bajando el trozo A LA VEZ, desde un solo sitio, en este caso Tiscali. Esto representa que existe un límite, que marca Tiscali, que no tiene ancho de banda infinito que dedicar al correo. Como bien indica EL-MEJOR, este es grande pero no infinito, son los 120Kbs que indica, pero es que no solo existen tus 50 usuarios, hay muchos que está leyendo su correo en cualquier momento dado, pro eso Tiscali limita el ancho de banda individual de cada usuario del correo, para que no se sature el sistema. Si hay en un momento 50 usuario en una YDM y otros 250 que leen su correo, tenemos 300 personas accediendo al servidor de Tiscali a la vez, y debe dar para todos. Si todos usan su ancho de banda máximo (256kbs), esto representa que se necesitan 9.4Mb/s de ancho de banda para todos. Por ese motivo las distribuciones YDM tiene un límite, si metes demasiados, se satura Tiscali y algunos empiezan a perder paquetes (ya que el buzón no tiene capacidad ilimitada), o no deja subir nuevos correos hasta que no se desahogue la línea.

************************************************************

...
En los 2 periodos de tiempo anteriores, E ha enviado 3 trozos cada vez. En total 6. Mientras E envia los trozos nuevos, solo 6 pueden intercambiar.
Por lo tanto, los archivos q circulan son 21 (E envia 3, y los 6 downloaders tambien)
....
E ya ha terminado y no envia. Solo hay intercambios (entre los 9 downloaders) y se reparten 27 trozos....

Repites contínuamente el mismo error. En el primer caso hay 6 trozos enviados, pero los 9 no los tiene todos, supongamos que los tienen U1 a U6, pero U7 a U9 no los tienen, aprovechemos para enviarselos. Por eso todos pueden enviar trozos a todos.

En el segundo caso asumes que el servidor ha terminado y se queda parado, ¿porque?, esto no es una YDM, si ya ha servido todos los trozos, puede empezar a repetir trozos, nadie ha dicho que un usuario no pueda pasar el mismo trozo varias veces. Incluso puede pasar dos trozos diferentes a la vez al mismo usuario, o incluso puede pasar un trozo usando el doble del ancho de banda, no existen limitaciones de este tipo en BT (y menos en un análisis teórico).

************************************************************

Usando el BT, en cuanto enviara el mismo byte 2 veces, ya estaría duplicando envíos. Por lo tanto, cuantas más veces haya de repetir los mismos bytes, más tiempo ha de durar. ¿Esto es así o estoy equivocado?

ummo, ese dato es vital para el supuesto q analizamos.

Damos x sentado q BT no repite ningun envio, algo similar al jumpstart de la mula.... y una condicion indispensable para este supuesto. BY incorpora wese control de envios, ya lo menciono algun usuario.

Si BT repitiera, ahi seguro q la cosa se disparaba. Te lo digo x experiencia.

Primero, ya he dicho que eMule y BT no son comparables a ese nivel, BT está mas optimizado para distribuciones rápidas, por eso su autor no ha dedicado ni un minuto a temas como mantener listas de ficheros compartidos, búsquedas o servidores, hacen perder mucho tiempo y generan un trafico adicional considerable. Repito que BT está orientado a distribuir un solo fichero entre un grupo de usuarios por un tiempo limitado (generalmente entre 3 y 7 días), solo mira que lo que has subido de ese fichero no sea menos de la mitad de lo que te has bajado (y repito que en mi caso lo mormal es que suba el doble de lo que bajo), mientras que el eMule está orientado a compartir muchos ficheros entre un grupo de usuarios por tiempo indefinido, funciona por colas y los ratios son entre todo lo compartido entre dos usuarios, no por ficheros individuales.

Segundo, como ya he dicho, el BT puede repetir envíos sin problemas, y no se pierde tiempo por ello, está en su propia filosofía. Si miras mi último análisis, he recalcado que al final de cada periodo existen tiempos de sobra, 6 para 3 slot, 23 para 4 slots y 5 para 5 slots, en estos tiempos se puede optimizar perfectamente la pérdida de tiempo que supone el que el sistema no esté optimizado y envíe un paquete cuando no debe.

Si aumentamos el número de partes y de usuarios, aumenta el número de trozos en movimiento contínuo, y por supuesto el número de slots que nos quedan libres en el último movimiento, por lo que se tiende a igualar el sistema, aunque los trozos se sirvan aleatóriamente.


**************************************************************************************

Hasta la próxima a todos, Jose Antonio

[EL-MEJOR]

Sigo pensando como al principio: demasiados análisis matemáticos para algo que es mucho más simple.

torpedorr, tú presupones que tiscali siempre enviará más rápido que tú (uploader), hayan 10 downloaders o hayan 1000. Eso significa en la práctica darle a tiscali un ancho de banda infinito. En esas condiciones es muy difícil ganar en velocidad al YDM salvo que sólo haya 1 o 2 downloaders.

Siendo igualmente generosos con BT y teniendo en cuenta que sus chunks son más pequeños que las partes en que se suelen dividir los dkdr en YDM, también podríamos admitir que BT podría ir más rápido en el caso de que los downloaders también gozaran de una subida infinita (como tiscali).

Evidentemente, estamos hablando de posibilidades teóricas, ya que parece que de eso se trata en este hilo.

El uploader, unico q tiene el fichero completo en nuestro caso, debe ir repartiendo trozos. Por mucho ancho de banda q tengan los downloaders y muy rapido q intercambien, la veloc de subida del uploader es la q lo limita todo.

Si tiscali tiene una capacidad de subida infinita, como decía en un párrafo anterior, esto es así. En el momento que se suponga que tiscali tiene un límite, eso ya no se cumple.

Supongamos el servidor de tiscali tiene una capacidad de 1000KB/s. Supongamos ahora que hay 50 downloaders descargando a la vez. Éstos podrán descargar a una velocidad de 20KB/s (1000/50). Ahora subamos el número de downloaders a 100 y la velocidad de descarga bajará a 10KB/s. Y si suponemos 200 downloaders entonces la velocidad a la que podrían descargar sus correos sería sólo 5KB/s, con lo que la velocidad de subida del uploader ya no sería el límite; ahora la limitación vendría impuesta por la velocidad de descarga. En un caso semejante, el uploader tendría que limitar su velocidad o los correos se acumularían y se perderían. Esto en el BT no ocurre y el uploader siempre podrá subir a tope. De ahí que dijera aquello de que con una cantidad suficiente de downloaders el BT ganaría al YDM. Pero claro, aquí se le está suponiendo una capacidad de subida infinita a tiscali, con lo que esto ya no es aplicable.

Sin embargo, nunca en cuianto a velocidad de bajada. Los problemas q suele dar son de otro tipo

Supón que yo monto un servidor de correo. El ancho de banda del que dispongo es de 1000KB/s. Pues bien, ahora tengo 2 opciones:

1 - Permitir todas las conexiones que mi router me permita, en cuyo caso cuantos más usuarios se conecten menor será su velocidad de descarga (este es el supuesto que te comentaba más arriba)

2 - Limitar el número de conexiones para garantizar un mínimo de calidad. Por ejemplo, si quiero que los usuarios descarguen sus correos a un mínimo de 10KB/s podría limitar el número máximo de conexiones a 100 y repartir equitativamente el ancho de banda disponible. En ese caso nunca habría nadie que descargara a menos de 10KB/s, pero lo que sí ocurriría sería que en cuanto hubieran más de 100 usuarios intentando descargar sus correos simultáneamente, habría gente que no podría conectar (al llegar a 100 usuarios conectados el servidor ya no permitiría más conexiones hasta que alguno de los 100 anteriores desconectase).

Con esto lo único que quiero decir es que el que tú puedas descargar siempre a 15KB/s no quiere decir que tiscali no tenga un límite. A lo peor, hay otros usuarios que no pueden conectar.

Pues no des nada por hecho, simplemente lee el enunciado del problema, estamos en un mundo perfecto y todo funciona de la mejor manera siempre, si cambias este pequeño principio, ya no hablamos de lo mismo, y eso es lo fundamental en este análisis, es teórico.

En un mundo perfecto los bloques no serían de 10MB como planteas en tus análisis y tampoco estaríamos hablando de un grupo de 10 personas.

Hay cosas en tus planteamientos, sobre todo cuando te pones a hablar de ciertas ventajas del BT que son completamente ciertas, pero sin embargo, cuando te pones a hacer análisis matemáticos ya es otro tema.
Si tú consideras bloques de 10MB y aceptas como bueno que tiscali subirá más rápido que el total de usuarios (y con sólo 10 usuarios será así) no sé qué estás discutiendo. En esas condiciones BT sólo será más rápido cuando sólo haya 1 o 2 downloaders (como mucho), en el resto de casos BT será más lento. Esto es así y no creo que admita ninguna discusión. Tampoco creo, como ya he dicho antes, que se necesite de complicados análisis matemáticos para demostralo. Todo es mucho más sencillo y simplemente con un poco de sentido común es más que suficiente.

Imagina que vas con tu coche a 10 km/h y pasa al lado uno que va a 100km/h. Entonces aceleras a tope hasta ponerte a 100 km/h y seguís así hasta el final. ¿Crees que en algún momento alcanzarás al otro coche? Está claro que no ¿verdad? Pues eso mismo es lo que pasa con YDM y el BT. El servidor de tiscali es el coche que va a 100km/h durante todo el trayecto desde X0 hasta X1 y BT es el que empieza a 10km/h y acelera rápidamente hasta alcanzar los 100km/h para después mantenerse a esa velocidad. Para que BT alcanzara y/o superara a YDM la primera condición indispensable es que BT pudiera ir más rápido que tiscali en algún momento. Ahora bien, si tú nos hablas de 10 usuarios que pueden enviar a 12,8KB/s cada uno, aceptas que tiscali envía a más de 128KB/s y supones bloques de 10MB en ambos métodos, no sé cómo puedes pensar que BT pueda ir igual de rápido como planteabas en un post anterior. Si en T0 BT iba más lento que tiscali y en ningún momento BT supera la velocidad de éste, está clarísimo que BT nunca alcanzará a YDM (dejamos aparte el caso excepcional de 1 único downloader).

Y te digo más, en ese supuesto, cuantos más usuarios sean más será la diferencia que le saque YDM a BT. Y para demostrar esto no hace falta más que suponer que el fichero a distribuir tiene 1 único bloque. Con YDM tardas un tiempo T en subir el bloque al servidor y en el segundo periodo éste se lo envía a todos los downloaders (suponemos que éstos descargan a la misma velocidad que el uploader envía, para simplificar). YDM ha necesitado de 2*T para distribuir el bloque. Ahora veamos qué sucede con BT, según el número de downloaders:

1 downloader: BT necesita T para enviar el bloque. Un 50% más rápido que con YDM (tomamos como referencia el tiempo que tarda YDM).

2 downloaders: BT necesita 1,5*T. En el primer T el uploader le envía el bloque al primer downloader y en el segundo T son el uploader + el primer usuario los que envían, así que tardan T/2 en enviarle el bloque al segundo usuario. Aquí ya sólo es un 25% más rápido que YDM.

3 downloaders: BT necesita 2*T. En el primer T el uploader le envía al primer downloader y en el segundo son los 2 los que envían a los otros 2 downloaders. Igual de rápidos.

4 downloaders: BT necesita 2,25*T. Los 2 primeros T es igual que en el caso anterior. Ahora tendremos 4 usuarios (1 uploader + 3 downloaders) que enviarán el mismo bloque al cuarto downloader, con lo que tardarán 1/4T en hacerlo. Aquí BT ya es un 12,5% más lento que YDM.

Y a partir de aquí seguirá aumentando la diferencia entre uno y otro método.

La única forma de que BT sea más rápido con X usuarios es suponer que tiscali no tendrá capacidad para enviar el bloque a los X usuarios en el tiempo T. Eso implica ponerle un límite al ancho de banda de tiscali. En ese supuesto, teniendo en cuenta ese límite y todos los demás factores, podríamos hablar de los casos en que BT sería más rápido.

Acabo diciendo que no entiendo cómo hablas de bloques de 10MB cuando los del BT parecen ser mucho más pequeños. Y te lo digo, porque bloques más pequeños permiten una distribución más rápida, lo cual es algo que beneficia al BT en algunos casos. Por ejemplo, en el supuesto planteado anteriormente, si BT distribuyera bloques de 5MB en vez de los de 10MB, en el caso de los 3 downloaders tendríamos:

0,5 T -> Up. envía 5MB al Down1
1T ->Up. envía los siguientes 5MB al Down2 y Down1 envía sus 5MB a Down3. Ahora tendríamos al uploader con los 10MB y a los 3 downloaders con la mitad.
1,4166 T-> Si no me he equivocado al elegir la secuencia aquí se acabaría la distribución BT. Menos de 1,5T frente a los 2T que se tardaba con bloques de 19MB.

Lo que he supuesto es lo siguiente:

Down1 + Donw3 envían los primeros 5MB a Down2 (tardan 1/4T)
Up. + Down2 envían los segundos 5MB a Down1 (tardan 1/4T)
Up. + Down1 + Down2 envían los degundos 5MB a Down3 (tardan 1/6T)

Conclusiones finales:

Suponiendo capacidad ilimitada a tiscali y una velocidad constante a la hora de recibir los correos, BT irá más rápido cuando hayan muy poquitos downloaders (el número exacto habría que calcularlo considerando el tamaño de los bloques tanto de YDM como de BT. Cuanto más pequeños sean los bloques de BT y más grandes los de YDM, más downloaders podrán haber en BT yendo más rápido que YDM).

En el caso de que se consideren bloques del mismo tamaño, entonces la única opción para que BT sea más rápido es considerar que tiscali tiene un límite real y que en un momento dado la velocidad a la que uno se descarga el correo descenderá.

Esta creo que es mi conclusión final

[EL-MEJOR]

Pongamos un ejemplo. Lanzamos una distribución durante 24 horas. Lanzas unas YDM a 50 usuarios, ancho de banda de 128Kbs/128kbs de envio y recepción (no se puede recibir mas rápido de lo que se envía), tardando 16 horas en completarla. Si quieres lanzar a otros 50 usuarios, ancho de banda de 128Kbs/128kbs, tardas otras 16 horas, por lo que no puedes completar mas que la mitad, y al cabo de 24 horas la tienen 50 personas completa y 50 personas tiene medio archivo.

Lanzamos lo mismo por BT. En 16 horas la completan 50 a 128kbs/128kbs. A partir de ese momento multiplicas por 50 tu ancho de banda de salida, por lo que todos reciben al máximo de su ancho de banda de entrada contínuamente, 6400kbs/256kbs (no puedes recibir a mas de lo que de tu línea), y tardan la midad en completar, por lo que acaban en 8 horas.

En el mismo tiempo y condiciones lo han recibido el doble de personas, y aunque existen límites para las distribuciones YDM (tienes que usar una tubería muy gorda, pero limitada), no existen en BT, puedo empezar a juntar magueras pequeñas, y hacer en total una tubería todo lo gorda que quiera.

Aquí un defensor del YDM te podría decir que cada uno de los primeros 50 downloaders podría estar distribuyendo un fichero con el BT (aparte de estar descargando la distribución YDM). ¿Cuántas fuentes y cuántos ficheros se podrían distribuir así?. El que YDM te deje libre la subida es una ventaja primordial (yo considero que es la más grande). Lo que te da tiscali es a cambio de nada, mientras que en BT, como en cualquier P2P, todos los que descargan tienen que subir también o la cosa se estanca. Al no necesitar subir con YDM, esa subida la puedes usar con el eMule o el propio BT para distribuir otros ficheros.

[cricri]

Hola.

Lo único que debería aportar la Web es un espacio para albergar un tracker.

Yo creo que para hacer una minidistribución puntual no es necesario. Ya sea el uploader de partida, o cualquier otro participante en la distribución, puede montarse un tracker sencillito en su ordenador.

Tracker: Es un sitio en que que se puede ver que descargas hay disponible, e icnlñuso en algunos como están las descargas, cuando comenzó, cuantos están haciendo de servidor y cuantos hacen de receptores, cuantos hay en cada momento, cuanto lleva descargado cada usuario, cuantas partes completas existen ya en la red, etc. Esta información puede ser mas o mwnos amplia, según desee el que monta el tracker.

Si quereis ver uno tracker en acción, pasaros por la página "http://bittorrent.nocillatv.com/" y vereis uno pequeño en cuanto a ficheros, pero con mucha información, pinchando en el número de seed o leeches os dará información mas detallada de como va la descarga. En este momento hay una que comenzó el día 17, con 11 seeds y 20 leeches (volará descargando seguramente), aunque lo normal es tener entre 1 y 3 seeds y entre 10 y 20 leeches en una descarga.

Se está hablando de BT como una posible herramienta para aquel usuario de eMule que quiera hacer una distribución previa entre un grupo limitado de gente realmente interesada en esa película, y que además está dispuesta a colaborar después compartiendo en el eMule, que es el objetivo final que se busca. En cambio, el ejemplo de Tracker que tu has puesto es ya una cosa digamos "más profesional" tratando al BT como un P2P ya en "masa".

Coincido con lo que habeis comentado alguno/s de que para saber cuál le funciona mejor a uno y se ajusta mejor a sus necesidades es probarlo.

Personalmente me gusta más el eMule que el BT como P2P. Prefiero una carrera de fondo como es el caso del eMule, pero a velocidades de BT en mi caso, y además seleccionando aquello que me quiero descargar y además apagando y encendiendo el ordenador cuando quiera o pueda. Pero si aparece una oportunidad en el BT, pues la aprovecharía. Sí en cambio veo útil el BT para hacer una distribución previa, aunque el trabajo de uploader sin poder descargar a la vez que subes puede ser para muchos demasiado sacrificio, con la ventaja que no tienes que mantener un archivo mucho tiempo en el incoming (que puede ser interesante para quien está justito de espacio y quiere compartir).

Hasta otra.

[javu61]

Hola:

EL-MEJOR, Estoy deacuerdo contigo (estamos diciendo lo mismo), Tiscali no tiene ancho de banda ilimitado, y realmente BT usa trozos mas pequeños para optimizar mejor el ancho de banda. He usado bloques de 10 Mb, porque es mas sencillo el cálculo y no afecta en las condiciones "ideales" que hemos planteado, si reduzco el tamalo del bloque, reduzco el último tiempo, pero mi objetivo es plantear que el tiempo será teóricamente el mismo, o muy similar siempre, y que si mejoro un poco las condiciones (mas slots o trozos mas pequeños) igualo mas los tiempos teóricos.

En una distribucion por BT, por YDM o por el sistema que quieras, hasta que el que tiene el fichero no lo haya puesto completamente en la red, no puede acabar la distribución. Si es cierto que el BT puede ser que acabe a la vez (recepción y emision van a la par), aunque en YDM no puede sera así (primero se emite, y luego se recibe).

Lo que puede pasar es que en BT el que emite envía el último trozo, y en ese momento hay N usuarios que han terminado, pero ahora necesitan distribuir ese trozo entre el resto de usuarios, usando un tiempo adicional.

Por este motivo, y de forma práctica, YDM o NEWs o BT concluirán una distribución mas o menos en el mismo tiempo, incluso BT debe ser mas rápido al optimizar los anchos de banda en el mundo real.

Y siguiendo el ejemplo de la velocidad, el YDM sería como ir en autobus, todos viajan juntos, si pierdes la salida ya no llegas, si te bajas en una parada ahí te quedas. Mientras tanto, BT organiza el viaje en coche, cada uno va en el suyo, sale cuando queire, para cuando le da la gana, y encima indican el mejor camino a los que van detrás, y conforme llegan a la meta algunos, ayudan a aumentar la velocidad de otros.

Elije tu medio de transporte, viaja, y luego nos enseñas las fotos (o en nuestro caso descarga y luego comparte).

cricri No digo que tengamos que montar un traker como el de Nocilla, sino que lo miren como ejemplo de lo que puede ser un tracker, y no hace falta montarlo para distribuir nada efectivamente, solo hay que publicar el enlace al torrent, como han hecho con el "plumas de caballo".

Pero precisamente nocilla se dedica a lanzar episodios de series y películas poco difundidas por BT (antes por NEWs, pero han cerrado mucho el grifo) o por cualquier otro método, para que luego se compartan por el eMule ¿no es eso lo que queremos todos en divxclasico?

Jose Antonio

[calvicius]

pero si un tracker es muy fácil de montar. si lo tengo hasta yo QueSoyMuyTorpe.
hay kits que te los dan prefabricados con el ftp apache, el python. y nada mas es descomprimir y arrancar los bat (en win, claro)

[EL-MEJOR]

He usado bloques de 10 Mb, porque es mas sencillo el cálculo y no afecta en las condiciones "ideales" que hemos planteado, si reduzco el tamalo del bloque, reduzco el último tiempo, pero mi objetivo es plantear que el tiempo será teóricamente el mismo, o muy similar siempre, y que si mejoro un poco las condiciones (mas slots o trozos mas pequeños) igualo mas los tiempos teóricos.

No nos equivoquemos, el tamaño de los bloques SÍ que afecta, y mucho, sea en condiciones "ideales" o no. Y para dejar claro el asunto, cuando hablo de "bloques" me refiero a la unidad mínima que se puede compartir (mientras que no tienes un bloque completo no puedes enviar nada de ese fichero). No es lo mismo enviar un bloque de 10 MB y que el usuario que lo está recibiendo no pueda enviar nada hasta que lo haya recibido completo, que enviar 500 KB a un usuario y 500KB al siguiente y que éstos puedan compartir esos 500KB recibidos.

Respecto a lo de mejorar las condiciones, la forma óptima (teóricamente hablando, ya que en la práctica también tiene sus defectos) sería usar un único slot de subida. Esto también es muy sencillo de demostrar:

Suponemos que T es el tiempo que tarda el uploader en subir un bloque (entendido como lo explicado más arriba).

Si usamos 2 slots de subida tendríamos:

2T -> U envía 1 bloque a D1 y a D2 (puesto que sube 2 bloques, tarda 2T).
4T -> U envía 1 bloque a D3 y a D4. Mientras tanto, D1 y D2 han subido 4 bloques (dos por unidad) a otros tantos downloaders.

En total, después de un tiempo 4T, los bloques subidos (y recibidos) han sido 8.

Si suponemos 3 slots, nos encontraríamos:

3T -> U ha enviado 1 bloque a D1, D2 y D3.
4T -> Tanto U como D1, D2 y D3 han subido 1/3 de bloque a 12 downloaders más.

En total, en un tiempo 4T, los bloques subidos han sido de 7 (aquí sumo los bloques no completos recibidos por los 12 downloaders).

Y ahora vamos con 1 único slot:

T -> U envía 1 bloque a D1.
2T -> U envía 1 bloque a D2 y D1 envía otro a D3. 2 bloques enviados en este periodo.
3T -> En este ciclo se enviarían 4 bloques
4T -> Y finalmente, 8 bloques más.

En el mismo tiempo, 4T, con un único slot hemos enviado 15 bloques.

Esto está muy ligado a lo del tamaño de los bloques. Para distribuir lo más rápido posible lo que nos interesa es que los downloaders empiecen a colaborar con el uploader lo antes posible (si sólo sube el uploader lo hace a una velocidad V, mientras que si hay un downloader subiendo también, la velocidad será de 2V y así sucesivamente). Cuanto más pequeños sean los bloques, antes los recibirán los downloaders y antes los podrán enviar. Y cuantos menos slots usemos, más rápido enviaremos 1 bloque, que es lo mínimo que se puede compartir.

Por este motivo, y de forma práctica, YDM o NEWs o BT concluirán una distribución mas o menos en el mismo tiempo, incluso BT debe ser mas rápido al optimizar los anchos de banda en el mundo real.

Como habrás podido comprobar, no tengo ningún reparo en admitir que, bajo ciertas circunstancias, BT puede ser más rápido a la hora de distribuir un archivo. Ahora bien ¿significa eso que BT es más eficaz? Pues, sinceramente, NO. Tanto en las distribuciones YDM o por NEWS sólo hay una persona, el uploader, subiendo (y a una velocidad relativamente baja). Por el contrario, en una distribución BT se necesita de la subida de muchos downloaders para que la distribución vaya más o menos igual de rápida. Es decir, para obtener resultados similares necesitas aplicar mucho más trabajo, lo cual demuestra que es mucho menos eficiente.

En esto hay algo que está muy claro: cuando hablamos de un programa P2P, los KB que el conjunto de usuarios se descargan son exactamente los mismos que esos mismos usuarios suben. Si suben más, podrán descargar más, pero no de otro modo. Por el contrario, en los métodos YDM o NEWS, los KB que se descargan son muchos más que los KB que se subieron. Tú subes 100MB y los downloaders se descargan 10GB (por ejemplo). La diferencia entre lo que has subido tú y lo que se han descargado los demás es lo que ha subido el servidor (de correo o de news).

Y siguiendo el ejemplo de la velocidad, el YDM sería como ir en autobus, todos viajan juntos, si pierdes la salida ya no llegas,....Mientras tanto, BT organiza el viaje en coche, cada uno va en el suyo...

Puede servir de ejemplo, siempre que admitas que con los coches no llegarás más rápido (en muchas ocasiones llegarás más tarde) y el gasto en combustible habrá sido mucho mayor para los que van en coche.

El coche tiene sus ventajas, pero a costa de un mayor gasto.

[raul2010]

ya he estado viendo q montar un pequeño tracker puede resultar sencillo, y la verdad es q he visto algunos integrados en php-nuke q me han gustado bastante

me lo miraré más, pq pienso q puede estar bien, cualquier idea o ayuda q querais prestar la podeis dejar en el foro Devel

asias