UNIVERSIDAD DE SANTIAGO CHILE

FACULTAD DE INGENIERA
DEPARTAMENTO DE INGENIERA INFORMTICA

BENCHMARK - SISTEMAS OPERATIVOS

GABRIEL GODOY LEN

SERGIO MEDINA
RODRIGO MENDOZA

Profesor: Fernando Rannou

Ayudante: Vctor Flores

Contenido
Santiago Chile
2014

1. INTRODUCCIN............................................................................................. 1
2. MARCO TERICO........................................................................................... 2
3. DESARROLLO................................................................................................ 3
3.1 BENCHMARK............................................................................................ 3
3.2 SCHEDULING BENCHMARK.......................................................................4
3.3 SINCRONIZACIN..................................................................................... 5
4. CONCLUSIONES............................................................................................. 6
5: REFERENCIAS............................................................................................... 7

1. INTRODUCCIN
En este trabajo se darn a conocer conceptos aplicados a los sistemas
operativos principales existentes hoy en da. El principal concepto tratado en
este trabajo es el de Benchmark. El cual tiene permite relacionar distintos
sistemas operativos en distintos aspectos en comn.
El principal objetivo de este trabajo es dar a conocer estas
caractersticas conceptuales de Benchmark y establecer parmetros
generales que son utilizados en los sistemas operativos a mencionar mas
adelante.
Una de las motivaciones en general de este trabajo es el hecho de
realizar comparaciones entre distintos sistemas operativos, los cuales
pueden ser bastante diferentes, mediante aplicaciones de benchmark y
cmo estos trabajan para realizar estas operaciones. Analizar cmo trabajan
y que aspectos toman en cuenta.
En base a lo anterior, este trabajo tendr un marco terico, donde se
detallaran los principales conceptos involucrados en l y a que se refieren. Y
por otro lado tendr el desarrollo del trabajo, donde se detallan los aspectos
principales del informe, a que se refieren y cmo funcionan al interior de un
sistema operativo.

2. MARCO TERICO

2.1 SISTEMA OPERATIVO

Conjunto de programas que se integran con el hardware para facilitar al usuario, el
aprovechamiento de los recursos disponibles. Algunos de sus objetivos principales son:
Provee de un ambiente conveniente de trabajo.
Hace uso eficiente del Hardware.
Provee de una adecuada distribucin de los recursos.
Para un Sistema Operativo real deber satisfacer las siguientes funciones:
Gobierna el Sistema.
Asigna los recursos.
Administra y controlar la ejecucin de los programas.
Un sistema de computo en muchos casos cuenta con demasiados recursos para ser
utilizados por un solo usuario, es en estos casos cuando se puede dar servicio a varios
procesos.

2.2 BENCHMARK

2.3 SCHEDULING
2.4 PROCESO
2.5 HEBRA

3. DESARROLLO
3.1 BENCHMARK
Un programa de prueba, o benchmark, se define como un programa o conjunto
de programas que evalan las prestaciones de un sistema informtico reproduciendo una
carga de trabajo genrica en dicho sistema informtico.
Los benchmark que miden un sistema informticos se agrupan en paquetes, lo
cual se denomina benchmark suites, que agrupan diferentes programas para medir
diferentes aspectos.
De acuerdo a Ramn Puigjaner, en su libro "Evaluacin y explotacin de
Sistemas Informticos", un buen benchmark suite de considerar los siguientes aspectos:

Determinar los objetivos del uso del benchmark: En sntesis, se debe aislar la
parte del sistema que se analizar del resto para evitar sus efectos, as como
especificar en qu tipo de cargas de trabajo o entorno se va a evaluar.
Analizar la carga de trabajo de diversos sistemas, o de un mismo sistema con
diversas aplicaciones: Por ejemplo, analizar en qu proporcin, se ejecutan las
instrucciones de coma flotante y las de nmero entero.
Escoger los programas segn los objetivos determinados: En general cada
programa mide diferentes subsistemas y por tanto.
Escoger las mtricas o mediciones que se van a tomar sobre el sistema:
Dependiendo de la parte del sistema que se medir, se deben usar distintas
mtricas y, en general, se dividirn en mtricas de velocidad de funciones y
capacidad del sistema.
Se deben tener en cuenta todos los factores que influyen en el rendimiento.

Los paquetes de benchmark, deben reunir las siguientes caractersticas para

cumplir su cometido:

Reproductibilidad
Compacidad
Compatibilidad
Resolucin
Escalabilidad

3.2 SCHEDULING
Una de las consideraciones ms importantes al elegir un sistema operativo de
tiempo real, es el overhead del scheduler. Por ejemplo, si un proceso de baja prioridad se
apropia el administrador previamente liberado por un proceso de alta prioridad, cunto
tardar el proceso de alta prioridad para ejecutarse nuevamente? El tiempo mnimo que
esto puede tomar est determinado por el tiempo que se requiere para realizar un cambio
de contexto, es decir, el tiempo requerido para planificar un nuevo proceso.
Para hacer las pruebas de scheduling, los benchmark suites realizan pruebas con
distintos procesos, es decir, de alta prioridad y de baja prioridad y se van haciendo
modificaciones sobre distintos parmetros que se pueden o no considerar en el tiempo
requerido para planificar cada proceso, tales como usar pipes, aadir corrupcin a las
operaciones aritmticas, etc.
Una investigacin de Richard Gooch de 1998, nos permite tener un acercamiento
a como se puede hacer un anlisis de benchmark de scheduling. Durante su
investigacin, midi el tiempo utilizado en cambios entre proceso y cambio entre hebras
para distintos tipos de prioridad de procesos y factores incidentes. Con sus resultados
pudo concluir que los resultados variaban principalmente por el tipo de cache empleado
en cada procesador, dejando de lado la penalizacin en la utilizacin debido a procesos
de baja prioridad.
En la tabla 3.1 se aprecia una comparacin entre los procesadores y su tiempo de
scheduling para un caso en particular, en el cual se consider la corrupcin en
operaciones aritmticas.

Tabla 3.1 : Caso con corrupcin en operaciones aritmticas [4]

3.3 SINCRONIZACIN
Para la sincronizacin de hebras es importante determinar qu tipo de tcnica se
utilizar, es decir, la forma en que se proteger la seccin critica del cdigo analizado.
Las tcnicas ms conocidas y utilizadas son los semforos mutex y las
operaciones atmicas.
Para la comparacin del benchmark, se utiliz tres tipos de tcnica, un mutex con
lock y unlock, un mutex con lock_guard y una operacin atmica para los enteros. La
investigacin se bas en analizar una pequea seccin critica para 1, 2, 4, 8, 16, 32, 64 y
128 hebras, donde cada prueba se repiti 5 veces.
Los resultados se observan en la figura 3.1, donde el color verde corresponde a la
operacin atmica, el azul al lock y el rojo al lock_guard.

Figura 3.1: Comparacin entre tcnicas

Se puede apreciar que sin duda alguna, los mutex son mucho ms lentos que las
tcnicas atmicas, pero que las tcnicas atmicas no tienen una gran escalabilidad y se
ve un gran impacto en su throughput en la medida que se aumentan las hebras, siendo el
ms significativo al pasar de una a dos hebras y mantenindose casi constante desde las
ocho hebras en adelante.
Adems se aprecia que la diferencia entre usar lock
despreciable.

o lock_guard es casi

3.4 SISTEMA DE ARCHIVOS

Para el sistema de archivos hay dos puntos principales que se deben tener en
consideracin, la implementacin del mismo (por ejemplo un sistema i-node) y el
tamao de los bloques del sistema.
Para este caso se considerar un archivo de prueba de 5.5 MB para comparar
tanto la implementacin de un i-node, como de un sistema hashed, ambos en el caso que
estn fragmentados y no fragmentados para distintos tamaos de bloques. En la figura
3.2 se pueden apreciar los resultados de la prueba.

Figura 3.2: Total de bsquedas frente a distintos tamaos de bloque [5]

Se ve claramente que la fragmentacin tiene un fuerte impacto en la medida que
los bloques son ms pequeos, pero que esto disminuye en la medida que se dobla el
tamao del bloque. Por otro lado, el sistema i-node tiene un mayor overhead que el
sistema hashed.

4. CONCLUSIONES

10

5: REFERENCIAS
[1] Pagina Web: http://repo.hackerzvoice.net/depot_madchat/ebooks/sched/Linux/linuxscheduler.html
[2] Juan Julin Merelo, Tema 4 DyEC, Universidad de Granada, Espaa, 2008.
[3] Ramn Puigjaner, Evaluacin y explotacin de Sistemas Informticos, 1995.
[4] Pagina Web: http://repo.hackerzvoice.net/depot_madchat/ebooks/sched/Linux/linuxscheduler.html
[5] Pagina Web: http://www.switkin.com/software/cs614/paper.html
[6] Pagina Web: http://www.mflor.mx/materias/comp/cursoso/sisope1.htm

11