viernes, 21 de agosto de 2009

Proyecto SCTP-H264

El proyecto completo se baja del SVN con el comando:

$ svn co svn+ssh://218.45.218.150/SCTP-H264/trunk SCTP-H264

- freebsd.makefile es el makefile para FreeBSD, se usa "$ make -f freebsd.makefile"
- include es el directorio con todos los .h llamados por los programas de la carpeta src
- Makefile es para Linux
- scripts es un directorio con herramientas muy utiles al momento de hacer 1 millon de tests, tiene scripts en ruby y shell
- SCTP-H264.conf es un archivo de configuracion para ciertos programas en src
- suj incluye archivos de la libreria libsuj hecha por Horacio y externa al proyecto

En los Makefile's es posible ver todos los ejecutables del proyecto. Ahora lo tengo para que los ejecutables obtenidos queden siempre en la carpeta raiz (SCTP-H264).
La carpeta scripts incluye:
- common.rb: varias clases y funciones que uso en otros scripts de la carpeta
- info.rb: tira informacion de un archivo .h64
- netem.sh: permite hacer la setting de netem simplemente haciendo "sudo netem.sh 50 6" para simular 50ms de RTT y 6% packet loss rate. En suj-uchile51 puse un link simbolico de /sbin/netem a dicho script que permite ahorrarse el .sh al final del comando.
- plot_globecom1.rb: programa en ruby que genera los graficos usados en el primer paper enviado a Globecom usando mi parser
- plot_ieice.rb: idem para el paper de IEICE
- plot.rb: grafica 1 o mas tracefiles usando mi parser
- process.rb: hecho por Horacio para hacer los graficos del primer paper mandado a Globecom
- sctpdump.sh: igual que netem.sh para obtener los .cap o trace files con tcpdump. Filtra todo lo de sctp haciendo "$ sudo sctpdump archivo.cap"
- test_buffer.rb: lo hice en su momento para obtener la diferencia entre la llamada a sctp_send y cuando efectivamente el mensaje salia a la red
- test_rtx.rb: para dejar corriendo muchos test para testear PR con RTX
- test_rtx2.rb: lo usaba despues del anterior para graficar la data obtenida de muchos tests
- test_sender.rb con este parseaba datos de la parte sender
- test_ttl.rb: analogo a test_rtx.rb pero con TTL
- test_ttl2.rb: analogo a test_rtx2.rb pero con TTL

De todos estos scripts, los mas utiles son netem.sh sctpdump.sh y plot.rb. Todos los programas en Ruby mios se puden ejecutar como comando, es decir "$ ./plot.rb" en vez de "$ ruby plot.rb"

En la carpeta include es relevante:
- const.h donde se especifican constantes para las apps, incluyendo el path del archivo de configuracion.
- connection.h es importante porque se especifica la estructura connection_t usada constantemente.
- nal.h: se especifica la estructura NALUnit usada constantemente y ademas es la que se usa para reproducir video, o sea en el player hecho por Felipe.

Ahora describo la carpeta src, que es donde estan todos los programas:

- annexb.c: hecho por Horacio
- buffer.c: maneja lectura y escritura de archivos, hecho por Felipe Lalanne
- config_file.c: hecho por mi, incluye solo la funcion read_config_file() para leer el archivo de configuracion
- connection.c: uno de los mas importantes del proyecto, hecho por todo el grupo. Maneja el envio y recepcion de datos, ademas de las policies de SCTP. Originalmente fue hecho por Felipe como una capa que manejaba la parte de red, asi que maneja tambien UDP y deberia tambien manejar TCP (no lo hace pero lo implementare en Chile).
- h264-parser.c: hecho por Felipe para obteners las NALs de un archivo H.264 raw.
- idrlist.c: pedido por Luis para listar los frames IDR (suponiendo 1 NAL por frame y descartando los SPS y PPS como frames). Es muy simple, la pega real la hacen los parsers de archivos. Es ejecutable (tiene main()).
- logging.c: hecho por Felipe para tirar a salida estandar mensajes de informacion (INFO: ...) y debugging (DEBUG: ...). Ademas estos mensajes quedan siembre en un archivo .log que usualmente tiene el mismo nombre que el ejecutable
- nal.c: ciertas funciones para NALs hecho por Felipe
- nal-queue.c: hecho por Felipe para el player
- packet-queue.c: hecho por Felipe para el player
- parse_file.c: lo hice para parsear un archivo H.264 pero esta medio deprecado
- parse_sctp.c: llamese a este MI parser. Hecho por mi y odiado por Horacio ;)
es para parsear los trace files y tira el resultado a salida estandar, lo cual es leido por algun programa en ruby para graficar. Come mucha memoria y es lento con archivos grandes, pero al parecer funciona. Es ejecutable
- parse_sender.c: hecho por mi, parecido al anterior pero orientado a sacar informacion de un trace file obtenido en la parte sender. Es ejecutable.
- parse_tcp.c: para parsear trace files usando TCP, no usar por el momento, creo que no esta ni terminado. Es ejecutable.
- parse_udp.c: idem para UDP, pero no obtiene informacion de NALs, sino que lo hice para analizar los trace files de FSO de Christian.
- player.c: hecho por Felipe. Reproduce archivos H.264
- receive_file.c: hecho por mi. Un cliente SCTP que recive NALs y las guarda en un archivo que luego es reproducible
- receive_play.c: igual que el anterior pero en vez de guardar en un archivo, reproduce el video. Este es el player de Felipe. Funciona bien la mayoria de las veces y es tolerante a perdida de NALs pues usa las librerias de FFMPEG
- sctp_dump.c: hecho por Horacio
- sctp_play.c:hecho por Horacio
- sctp_send.c: hecho por Horacio
- test_pcap.c: el parser de Horacio. Lo mismo que parse_sctp.c. Es ejecutable.
- test_pqueue.c: lo hice en su momento para testear la libreria de pqueue's de Horacio. Es ejecutable.
- test_receive.c: es el cliente SCTP, el que uso constantemente. Recibe mensajes SCTP y los descarta inmediatamente. Idealmente se usa junto con tcpdump. Escucha en el puerto 30000 siempre pero esto es modificable en el archivo de configuracion. Es ejecutable.
- test_send.c: el enviador que uso constantemente. Todos los parametros los lee del archivo de configuracion, pero es posible especificar la policy por ej: $ test_send --profile="rtx 0.06". Es ejecutable
- udpclient.c: hecho por mi para testear si la perdida especificada con netem era efectivamente esa. Es ejecutable.
- utils.c: un par de funciones miscelaneas usadas en varios programas
- video-decoder.c: hecho por Felipe para parsear y reproducir archivos H.264
- sctp_dump.rb: Hecho por Horacio en Ruby.

miércoles, 19 de agosto de 2009

Actualización del Kernel de FreeBSD 8 desde el source usando csup

El método que uso para actualizar el kernel de FreeBSD es el oficial, usando una herramienta llamada "csup", que al parecer es una versión moderna de otro comando llamado "cvsup".

Lo que hacemos es bajar de algun servidor CVS oficial el código del kernel + aplicaciones. Recomiendan no actualizar solamente el kernel, sino todo el sistema. Luego recompilamos todo.
Este método es medio delicado, no siempre funcionan las cosas. Lo que describo ahora es lo que me ha resultado sin problemas, basado en la documentación que he encontrado.

Primero que nada, nos logueamos como root (con sudo también se puede) en un PC con acceso a internet (implica cambiar la configuración de red de suj-uchile52 que no tiene acceso a los servidores CVS):
$ su
$ cd /usr/src

Con el siguiente comando se aplican las últimas actualizaciones desde el CVS:
$ csup /etc/supfile

donde /etc/supfile es nuestro archivo de configuración para csup. Así lo uso ahora:

*default host=cvsup.jp.freebsd.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress
src-all
ports-all tag=.
doc-all tag=.

en el directorio que dejamos como "base" (/var/db) hay un archivo de menor importancia, /var/db/sup/refuse, que indica que NO queremos bajar. Yo lo tengo con los idiomas distintos al inglés:

doc/bn_*
doc/da_*
doc/de_*
doc/el_*
doc/es_*
doc/fr_*
doc/hu_*
doc/it_*
doc/ja_*
doc/mn_*
doc/nl_*
doc/no_*
doc/pl_*
doc/pt_*
doc/ru_*
doc/sr_*
doc/tr_*
doc/zh_*

Cuando baja los sources, Randall recomienda hacer lo siguiente:

What I normally do if I want to run HEAD/9.0 on a machine that I want to
"be more stable" and make performance measurements is:

1) Go in to the GENERIC file of the machine type and comment out
the 2 lines that mention INVARIANT and the 2 lines that mention
WITNESS.

2) Go to the file head/lib/libc/stdlib/malloc.c and uncomment the
#define that says MALLOC_PRODUCTION

3) Then do all my builds.. kernel and buildworld/installworld.


This then assures me that I do NOT get:

a) Debugging panics
b) Bogged down with unnecessary performance drags that are for
the normal kernel development.

Lo que uso desde ahora es lo que aparece en /usr/src/UPDATING, que es el método oficial.
Esto compila todo o "el mundo"

$ env -i make buildworld

en /usr/src/UPDATING recomiendan poner "env -i" antes de todos los make, así que eso es lo que hago. Una vez olvidé poner env -i y me tiró un error al compilar.

Este proceso se demora harto rato, más que compilar sólo el kernel.

Cuando vuelves del café (con piernas) y todo compiló bien, compilamos el kernel:

$ env -i make kernel KERNCONF=GENERIC

donde GENERIC es el nombre de nuestra configuración. Esto se demora unos 25 minutos.

Si todo salio bien rebooteamos en modo "single user". Esto se hace rebooteando y cuando aparece el menú feo de inicio de FreeBSD elegimos el modo "single user" presionando el 4.

# mount -a
# cd /usr/src
# mergemaster -pa

# make installworld

esto demora 1 ó 2 minutos

# make delete-old

Otra vez, las opciones por default deberían estar OK.

# mergemaster -a

De nuevo, las opciones por default deberían estar OK. Finalmente:

# reboot

Rebootea normalmente y el sistema queda "a punto", con todas las últimas modificaciones. Ojo que para actualizar los ports es otra historia.