<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hola Pep. Sí, la verdad es que los problemas de segmentation fault
nos empezaron a surgir ya en la versión 1.0.6 y entonces optamos por
la solución que tú comentas. Por cierto, la función ogTorrentStart
lanza ctorrent con la opción -f. Creía que era para evitar el
chequeo inicial de la imagen.<br>
La verdad es que optimiza el uso de la red al máximo, pero tiene la
pega de no poder utilizar el asistente de deploy de imágenes.<br>
Aunque el despliegue de semilleros que utilizamos en su día era
sencillo, utilizando algunos ogLIve como la imagen ya en la caché:<br>
IMG=<fichero de imagen><br>
IMGDIR=$(ogGetParentPath CACHE /$IMG)<br>
ogCopyFile REPO $IMG.torrent $IMGDIR<br>
ogTorrentStart CACHE $IMG.torrent seeder:<tiempo en segundos><br>
<br>
En cuanto a los problemas de segmentation fault y abortos de
ctorrent, después de ponerlo en debug, he podido ver que en ambos
casos están relacionados con la entrada en el modo EndGame de
BitTorrent. Ese modo se utiliza sobre todo al finalizar las
descargas, preguntando a todos los peers por las partes que le
faltan a un cliente, y cancelando las respuestas a peticiones
repetidas. Lamentablemente, ctorrent no gestiona bien esas
cancelaciones y termina cometiendo errores como la creación de
arrays de longitud negativa.<br>
Para el problema del segmentation fault, que se da al poco de
comenzar las sesiones de descarga, creo que tienen un sencillo
parche en <a class="moz-txt-link-freetext"
href="https://sourceforge.net/p/dtorrent/patches/6/">https://sourceforge.net/p/dtorrent/patches/6/</a>
que lo solventa.<br>
Pero solucionar el bug del error final std::bad_array_new_length
creo que me supera, por lo que he optado por el camino de en medio,
evitando que ctorrent entre en modo endgame. Tiene el inconveniente
de que la localización de las partes finales de una descarga tardan
algo más.<br>
Lo curioso de este último error es que sólo se da, como comentaba,
si los clientes llegan parejos al final en las partes descargadas.
Este sólo es el caso cuando la velocidad para servir disco del
semillero es menor que la velocidad de la red, de tal manera que los
clientes terminan convergiendo entre ellos aunque arranquen después
de un tiempo aleatorio<br>
<br>
Tras regenerar el paquete deb de ctorrent luego sólo hay que
instalarlo en el sistema de ficheros squashfs de ogclient.sqfs, para
que luego lo cargue el ogLive.<br>
<br>
Bueno, al final creo me ha salido también otro ladrillo.<br>
Saludos.<br>
<br>
<div class="moz-cite-prefix">Pep Ciuraneta Sanchez escribió el
9/7/21 a las 18:21:<br>
</div>
<blockquote type="cite"
cite="mid:CAFwfQZcQYYEmnhBSe3_TsyjchkncN7xY9TdC=rEpqASEWvaNfQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hola Miguel,
<div><br>
</div>
<div>Te explico, nosotros empezamos haciendo pruebas con 1.2.0
para ver si solucionabamos unos problemas con el torrent (no
aprovechamiento del ancho de banda, falta de fiabilidad con
muchos errores segmentation fault en clientes) y al ver que
con 1.2.0 nos pasaba lo mismo hemos cambiado el programa que
se encarga de hacer el seed. Seguimos con 1.1.0 de momento.
Esto lo hemos hecho tras hacer pruebas esta misma semana.</div>
<div><br>
</div>
<div>En lugar de usar el bittornado hemos optado por lanzar un
ctorrent por cada fichero torrent. Esto tiene su
inconveniente, pero desde entonces el ancho de banda se
aprovecha algo mejor y los errores se han minimizado
muchísimo. De momento lo vamos a dejar así. En concreto lo
lanzamos así para cada fichero (simplificado)</div>
<div><br>
</div>
<div># cd /opt/opengnsys/images</div>
<div># ctorrent -e -1 -d nombre_fichero_img.torrent</div>
<div><br>
</div>
<div>Yo creo que esto es extrapolable a la versión 1.2.0. El
hecho de usar ctorrent en lugar de bittornado funciona
bastante mejor, pero tiene la pega que cada vez que se inicia
se comprueba el fichero a compartir y eso puede ser costoso en
tiempo y depende de la velocidad acceso de disco.</div>
<div><br>
</div>
<div>Hemos aprovechado este final de curso para hacer multiples
pruebas y el poder aprovechar la red a 1Gbps da bastante
alegria.</div>
<div><br>
</div>
<div>Consejos para subir la velocidad en descarga por torrent:</div>
<div><br>
</div>
<div>1.- si es posible, tener los ficheros imagen en disco SSD</div>
<div>2.- tener algun seeder extra. No hace falta que sea un
REPO, simplemente una máquina de backup donde tener los
ficheros imagen y los torrent.</div>
<div>3.- si los equipos destino tienen disco SSD comprobar que
las particiones esten alineadas. Esto es muy importante.</div>
<div>4.- Realizar un procedimiento para hacer que las aulas o
equipos que tengan la imagen puedan hacer de seeders.
Basicamente es lanzar un ctorrent y esperar al chequeo de cada
imagen, pero esto ayuda mucho a subir la velocidad de
descarga. Esto equivale a multiplicar el consejo 2 por el
numero de máquinas en las que se ejecute el procedimiento. Por
ejemplo, se puede descargar primero en el aula donde sea más
rapido el despliegue y luego añadir sus equipos como seeders
para acelerar al resto.</div>
<div>5.- Tener REPOS repartidos por diferentes tramos de la red.
Esto depende de la infraestructura de cada uno.</div>
<div><br>
</div>
<div>Miguel, Perdona el ladrillo, al final me ha salido algo
largo. En resumen, prueba de cambiar el bittornado por un
script que te lance los ctorrent (en el mismo rc.local) y a
ver que tal. </div>
<div><br>
</div>
<div>Saludos,</div>
<div>Pep.</div>
<div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<pre cols="80">--
O O O Universitat Politecnica de Catalunya
O O O BarcelonaTECH
O O O ------------------------------------
U P C Facultat de Matematiques i Estadistica
Pau Gargallo, 14 - 08028 Barcelona
Pep Ciuraneta Sanchez
Serveis TIC
<a href="mailto:josep.ciuraneta@upc.edu" target="_blank" moz-do-not-send="true">josep.ciuraneta@upc.edu</a>
Tel. 934015853
AVIS DE CONFIDENCIALITAT:
Aquest missatge pot contenir informacio confidencial o legalment protegida i esta exclusivament adrecat a la persona o entitat destinataria. Si no sou el destinatari final o persona encarregada de recollir-lo, no esteu autoritzat a llegir-lo, retenir-lo, modificar-lo, distribuir-lo, copiar-lo ni a revelar el seu contingut. Si heu rebut aquest missatge per error, us preguem que informeu al remitent i elimineu del vostre sistema el missatge i el material annex que pugui contenir. Gracies per la vostra col.laboracio.
Abans d'imprimir aquest correu, penseu si es necessari.</pre>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Missatge de Miguel Sánchez
Sánchez <<a href="mailto:msanchez@fi.upm.es"
moz-do-not-send="true">msanchez@fi.upm.es</a>> del dia
dv., 9 de jul. 2021 a les 12:39:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Buenas.
Me estoy encontrando con que un porcentaje de ogLive, cuando
van <br>
a acabar la descarga de una imagen, ctorrent aborta con error
<br>
std::bad_array_new_length.<br>
Todos los clientes torrent van más o menos igual en la
descarga, pues <br>
acaban bien o fallan al alimón, pues el semillero en el
servidor parece <br>
que no supera los 50Mbit por conexión, y aunque empiezan la
descarga <br>
aleatoriamente van convergiendo. Abortan con un número pequeño
de partes <br>
por completar, menos de 20.<br>
<br>
No estoy seguro si está relacionado con algún parámetro del
semillero en <br>
el servidor, pues hasta ahora nuestro servidor de OpenGnsys
estaba un <br>
poco escaso de recursos y el problema parece que desaparecía
cuando se <br>
limitaban en el semillero el número de peers que se podían
conectar. <br>
Pero hemos cambiado a versión 1.2.0 en un nuevo servidor y el
problema <br>
persiste.<br>
El semillero que estamos utilizando actualmente es <br>
btlaunchmany.bittorrent, por aquello de que utiliza un thread
por imagen <br>
servida. Pero creo recordar que con btlaunchmany.bittornado
los errores <br>
también se producían.<br>
<br>
¿Os habéis encontrado alguno con este problema? ¿Cómo lo
habéis solventado?<br>
<br>
Saludos.<br>
_______________________________________________<br>
Opengnsys-users mailing list<br>
<a href="mailto:Opengnsys-users@listas.unizar.es"
target="_blank" moz-do-not-send="true">Opengnsys-users@listas.unizar.es</a><br>
<a
href="https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users</a><br>
----------<br>
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL<br>
<br>
Ud. recibe este correo por pertenecer a una lista de correo
gestionada por la Universidad de Zaragoza.<br>
Puede encontrar toda la información sobre como tratamos sus
datos en el siguiente enlace: <a
href="https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas</a><br>
Recuerde que si está suscrito a una lista voluntaria Ud. puede
darse de baja desde la propia aplicación en el momento en que
lo desee.<br>
<a href="http://listas.unizar.es" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://listas.unizar.es</a><br>
----------<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Opengnsys-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opengnsys-users@listas.unizar.es">Opengnsys-users@listas.unizar.es</a>
<a class="moz-txt-link-freetext" href="https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users">https://listas.unizar.es/cgi-bin/mailman/listinfo/opengnsys-users</a>
----------
INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL
Ud. recibe este correo por pertenecer a una lista de correo gestionada por la Universidad de Zaragoza.
Puede encontrar toda la información sobre como tratamos sus datos en el siguiente enlace: <a class="moz-txt-link-freetext" href="https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas">https://sicuz.unizar.es/informacion-sobre-proteccion-de-datos-de-caracter-personal-en-listas</a>
Recuerde que si está suscrito a una lista voluntaria Ud. puede darse de baja desde la propia aplicación en el momento en que lo desee.
<a class="moz-txt-link-freetext" href="http://listas.unizar.es">http://listas.unizar.es</a>
----------
</pre>
</blockquote>
<br>
</body>
</html>