Correciones TP 1

General:

El criterio que usan para calcular el turnaround a lo largo del trabajo es erróneo: no deberían excluir la latencia, ya que la idea es medir cuánto demora la tarea en completarse desde que es enviada por el usuario hasta que termina su ejecución. Noten que, al no considerar el tiempo de latencia, la métrica pierde mucha significación: por ejemplo, en algoritmos que no tengan desalojo, donde los procesos no vuelven a estar en ready luego de comenzar a ejecutar, la métrica siempre arroja el mismo valor independientemente del criterio de scheduling usado.

Ejercicio 1: Bien

Ejercicio 2: Bien

La latencia está mal calculada. Como ustedes mismos aclaran, se trata de la cantidad de unidades de tiempo que el proceso pasa en estado ready antes de empezar a ejecutar. Por lo tanto, deben considerar desde el momento en que el proceso llega al procesador, no desde el comienzo del lote.

Ejercicio 3: Bien

~~Tengan en cuenta que el return de la tarea insume una unidad de tiempo de CPU. Por lo tanto, su tarea TaskBatch utiliza la CPU una unidad de tiempo más que lo especificado por parámetro.~~
~~Cuidado al leer las consignas. El enunciado pide que el lote tenga 4 tareas, pero el lote que grafican solo tiene 3.~~

Ejercicio 4: Bien

A modo de comentario, la implementación que hacen de RR es “poco tradicional”. No es estrictamente cierto que el Map reemplace a una cola, dado que el orden resultante no será el mismo. Por ejemplo, si en un momento dado la próxima tarea que aparece en el Map se desbloquea, con su implementación ejecutará en el quantum inmediato siguiente, mientras que utilizando una cola, esta tarea se insertaría al final de la misma. No obstante, estas diferencias no me parecen un problema, dado que de todas formas obtienen un scheduler que otorga quantums por turnos y previene la inanición.
~~Muy buenos los escenarios de prueba y las conclusiones que extraen de los mismos.~~
NOTA AGUSTIN: Al modifcar el ej3 se agregó una tarea y recalculé las métricas (considerando turnaround con latencia)

Ejercicio 5: Bien

~~Las conclusiones son muy buenas y significativas.~~

Ejercicio 6: Bien

Ejercicio 7: Bien

~~El código tiene abundantes comentarios, lo cual lo hace fácil de leer y comprender.~~
~~Los casos de prueba son pertinentes y muestran que el funcionamiento del algoritmo es el esperado.~~

Ejercicio 8: Regular

Me parece bien la idea de elegir los casos de prueba en base a escenarios reales, aunque sería bueno que el informe detallara mejor cómo construyeron dichos escenarios (cantidad de tareas de cada tipo, rango de longitudes que consideraron, etc.). No obstante, dada dicha separación en casos, es esperable que extraigan conclusiones relativas a los mismos (mencionar, por ejemplo, cuáles son los algoritmos que resultan más eficientes en cada contexto); en cambio, muchas de las conclusiones que obtienen son incidentales, causadas más por circunstancias o parámetros particulares del experimento. Más sobre esto en los puntos siguientes.
Los casos de prueba con un context switch de costo 12 no resultan significativos, ya que es un valor demasiado extremo considerando la longitud de las tareas. Lo mismo puede decirse de los quantums de tamaño 30; como mencionan ustedes mismos en el informe, «como el quantum es mayor que el tiempo que demora cada tarea en completarse, todas se comportan como un scheduler FIFO». Esto le quita todo interés al experimento, ya que impide realizar comparaciones entre los algoritmos, además de tratarse de una situación poco probable en un escenario real.
En varias ocasiones, hacen afirmaciones como la siguiente: «por la naturaleza de este scheduler el mean turnaround time es mucho más alto». Deberían explicar mejor a qué características puntuales del scheduler se refieren cuando hablan de la “naturaleza” del mismo.
Detalle que me llamó la atención: en el caso “uso intensivo de CPU, 4 cores” mencionan que RSJF muestra una mayor latencia que SJF. ¿Por qué creen que sucedió esto? A priori, esperaría que suceda exactamente lo opuesto.
Como comentario general, me gusta la idea de presentar los resultados de las métricas mediante gráficos de barras, lo cual simplifica la tarea de comparar los resultados para los distintos algoritmos. No obstante, creo que el formato que eligieron resulta poco conciso, lo cual dificulta leer la información, y distinguir cuáles son los datos más relevantes. También, deberían tener cuidado con los gráficos donde la leyenda tapa algunas de las barras e impide ver correctamente los resultados.
En resumen: la elección de los escenarios de prueba no me parece mal, pero no logran extraer conclusiones claras acerca de los mismos, lo cual los lleva a detenerse demasiado en circunstancias puntuales de cada experimento. En general se limitan a exhibir los resultados obtenidos, sin ahondar en sus posibles causas o en las implicancias que tienen para el escenario “de la vida real” que están considerando. Uno de los principales problemas es la elección de parámetros desafortunados, puntualmente, el context switch excesivamente costoso y el quantum demasiado largo. Creo que una buena idea sería plantearse cuál o cuáles de las métricas resultan más relevantes en cada uno de sus tres escenarios, y enfocar la experimentación a contrastar los algoritmos con respecto a estas métricas; todo esto teniendo cuidado de elegir parámetros que no quiten relevancia a los experimentos.

Ejercicio 9: Regular

~~El código está bien, y la explicación, aunque escueta, alcanza para comprender el funcionamiento del mismo.~~
Todos los casos de prueba que exponen presentan un error de tipo conceptual: la idea de un scheduler de tipo MFQ es que las colas tengan quantums más largos según disminuye su prioridad. Esto permite que los procesos que hacen uso intensivo de la CPU, si bien bajan de prioridad, causando que ejecuten menos frecuentemente, vean compensado esto con un quantum de mayor duración. Por este motivo, llegan a la conclusión de que el scheduler es ineficiente para tareas de procesamiento intensivo, lo cual no es necesariamente cierto; en realidad, se trata de un scheduler bastante “adaptable”. No me parece necesariamente mal incluir un experimento con estos parámetros, pero debería ser a modo de complemento y aclarando que no es el uso esperado del scheduler.
~~El informe debería indicar las características de los lotes usados en la experimentación; así como está, el lector se ve obligado a inferirlas a partir de los gráficos y sus epígrafes.~~
Teniendo en cuenta que extraen conclusiones acerca de la eficiencia del algoritmo, sería bueno conocer en qué criterio están basadas (¿evaluaron alguna métrica a partir de los resultados?).

General: - El criterio que usan para calcular el turnaround a lo largo del trabajo es erróneo: no deberían excluir la latencia, ya que la idea es medir cuánto demora la tarea en completarse desde que es enviada por el usuario hasta que termina su ejecución. Noten que, al no considerar el tiempo de latencia, la métrica pierde mucha significación: por ejemplo, en algoritmos que no tengan desalojo, donde los procesos no vuelven a estar en ready luego de comenzar a ejecutar, la métrica siempre arroja el mismo valor independientemente del criterio de scheduling usado. Ejercicio 1: Bien Ejercicio 2: Bien - ~~La latencia está mal calculada. Como ustedes mismos aclaran, se trata de la cantidad de unidades de tiempo que el proceso pasa en estado ready antes de empezar a ejecutar. Por lo tanto, deben considerar desde el momento en que el proceso llega al procesador, no desde el comienzo del lote.~~ Ejercicio 3: Bien - ~~Tengan en cuenta que el return de la tarea insume una unidad de tiempo de CPU. Por lo tanto, su tarea TaskBatch utiliza la CPU una unidad de tiempo más que lo especificado por parámetro.~~ - ~~Cuidado al leer las consignas. El enunciado pide que el lote tenga 4 tareas, pero el lote que grafican solo tiene 3.~~ Ejercicio 4: Bien - ~~A modo de comentario, la implementación que hacen de RR es “poco tradicional”. No es estrictamente cierto que el Map reemplace a una cola, dado que el orden resultante no será el mismo. Por ejemplo, si en un momento dado la próxima tarea que aparece en el Map se desbloquea, con su implementación ejecutará en el quantum inmediato siguiente, mientras que utilizando una cola, esta tarea se insertaría al final de la misma. No obstante, estas diferencias no me parecen un problema, dado que de todas formas obtienen un scheduler que otorga quantums por turnos y previene la inanición.~~ - ~~Muy buenos los escenarios de prueba y las conclusiones que extraen de los mismos.~~ - NOTA AGUSTIN: Al modifcar el ej3 se agregó una tarea y recalculé las métricas (considerando turnaround con latencia) Ejercicio 5: Bien - ~~Las conclusiones son muy buenas y significativas.~~ Ejercicio 6: Bien Ejercicio 7: Bien - ~~El código tiene abundantes comentarios, lo cual lo hace fácil de leer y comprender.~~ - ~~Los casos de prueba son pertinentes y muestran que el funcionamiento del algoritmo es el esperado.~~ Ejercicio 8: Regular - Me parece bien la idea de elegir los casos de prueba en base a escenarios reales, aunque sería bueno que el informe detallara mejor cómo construyeron dichos escenarios (cantidad de tareas de cada tipo, rango de longitudes que consideraron, etc.). No obstante, dada dicha separación en casos, es esperable que extraigan conclusiones relativas a los mismos (mencionar, por ejemplo, cuáles son los algoritmos que resultan más eficientes en cada contexto); en cambio, muchas de las conclusiones que obtienen son incidentales, causadas más por circunstancias o parámetros particulares del experimento. Más sobre esto en los puntos siguientes. - Los casos de prueba con un context switch de costo 12 no resultan significativos, ya que es un valor demasiado extremo considerando la longitud de las tareas. Lo mismo puede decirse de los quantums de tamaño 30; como mencionan ustedes mismos en el informe, «como el quantum es mayor que el tiempo que demora cada tarea en completarse, todas se comportan como un scheduler FIFO». Esto le quita todo interés al experimento, ya que impide realizar comparaciones entre los algoritmos, además de tratarse de una situación poco probable en un escenario real. - En varias ocasiones, hacen afirmaciones como la siguiente: «por la naturaleza de este scheduler el mean turnaround time es mucho más alto». Deberían explicar mejor a qué características puntuales del scheduler se refieren cuando hablan de la “naturaleza” del mismo. - Detalle que me llamó la atención: en el caso “uso intensivo de CPU, 4 cores” mencionan que RSJF muestra una mayor latencia que SJF. ¿Por qué creen que sucedió esto? A priori, esperaría que suceda exactamente lo opuesto. - Como comentario general, me gusta la idea de presentar los resultados de las métricas mediante gráficos de barras, lo cual simplifica la tarea de comparar los resultados para los distintos algoritmos. No obstante, creo que el formato que eligieron resulta poco conciso, lo cual dificulta leer la información, y distinguir cuáles son los datos más relevantes. También, deberían tener cuidado con los gráficos donde la leyenda tapa algunas de las barras e impide ver correctamente los resultados. - En resumen: la elección de los escenarios de prueba no me parece mal, pero no logran extraer conclusiones claras acerca de los mismos, lo cual los lleva a detenerse demasiado en circunstancias puntuales de cada experimento. En general se limitan a exhibir los resultados obtenidos, sin ahondar en sus posibles causas o en las implicancias que tienen para el escenario “de la vida real” que están considerando. Uno de los principales problemas es la elección de parámetros desafortunados, puntualmente, el context switch excesivamente costoso y el quantum demasiado largo. Creo que una buena idea sería plantearse cuál o cuáles de las métricas resultan más relevantes en cada uno de sus tres escenarios, y enfocar la experimentación a contrastar los algoritmos con respecto a estas métricas; todo esto teniendo cuidado de elegir parámetros que no quiten relevancia a los experimentos. Ejercicio 9: Regular - ~~El código está bien, y la explicación, aunque escueta, alcanza para comprender el funcionamiento del mismo.~~ - ~~Todos los casos de prueba que exponen presentan un error de tipo conceptual: la idea de un scheduler de tipo MFQ es que las colas tengan quantums más largos según disminuye su prioridad. Esto permite que los procesos que hacen uso intensivo de la CPU, si bien bajan de prioridad, causando que ejecuten menos frecuentemente, vean compensado esto con un quantum de mayor duración. Por este motivo, llegan a la conclusión de que el scheduler es ineficiente para tareas de procesamiento intensivo, lo cual no es necesariamente cierto; en realidad, se trata de un scheduler bastante “adaptable”. No me parece necesariamente mal incluir un experimento con estos parámetros, pero debería ser a modo de complemento y aclarando que no es el uso esperado del scheduler.~~ - ~~El informe debería indicar las características de los lotes usados en la experimentación; así como está, el lector se ve obligado a inferirlas a partir de los gráficos y sus epígrafes.~~ - Teniendo en cuenta que extraen conclusiones acerca de la eficiencia del algoritmo, sería bueno conocer en qué criterio están basadas (¿evaluaron alguna métrica a partir de los resultados?).

#2 Correciones TP 1