{"action":"created","issue":{"url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/1","repository_url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander","labels_url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/1/comments","events_url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/1/events","html_url":"https://github.com/sisoputnfrba/2016-2c-char-mander/pull/1","id":178263099,"number":1,"title":"[En progreso] Dándole sentido al SRDF","user":{"login":"mgarciaisaia","id":1190974,"avatar_url":"https://avatars.githubusercontent.com/u/1190974?v=3","gravatar_id":"","url":"https://api.github.com/users/mgarciaisaia","html_url":"https://github.com/mgarciaisaia","followers_url":"https://api.github.com/users/mgarciaisaia/followers","following_url":"https://api.github.com/users/mgarciaisaia/following{/other_user}","gists_url":"https://api.github.com/users/mgarciaisaia/gists{/gist_id}","starred_url":"https://api.github.com/users/mgarciaisaia/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mgarciaisaia/subscriptions","organizations_url":"https://api.github.com/users/mgarciaisaia/orgs","repos_url":"https://api.github.com/users/mgarciaisaia/repos","events_url":"https://api.github.com/users/mgarciaisaia/events{/privacy}","received_events_url":"https://api.github.com/users/mgarciaisaia/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-09-21T07:00:47Z","updated_at":"2016-09-22T01:01:17Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/pulls/1","html_url":"https://github.com/sisoputnfrba/2016-2c-char-mander/pull/1","diff_url":"https://github.com/sisoputnfrba/2016-2c-char-mander/pull/1.diff","patch_url":"https://github.com/sisoputnfrba/2016-2c-char-mander/pull/1.patch"},"body":"> **TL;DR:** Vamos a hacer un cambio importante al enunciado, y estamos evaluando cuál es la mejor opción. Leé, analizá, y, _por favor_, opiná\r\n\r\nComo se discutió en sisoputnfrba/foro#457, el algoritmo SRDF carece de sentido en el enunciado.\r\n\r\nAl ser un algoritmo expropiativo, solamente se elegirá un Entrenador para atender cuando: a) recién se haya (re)conectado al Mapa; b) recién haya capturado un Pokemon; o c) se recargue el archivo de configuración entre que se expropia un Entrenador por fin de ráfaga y se atiende a otro que estaba en Listos.\r\n\r\nc) es _muy_ improbable de ocurrir. a) y b), los casos normales, comparten un problema: el Entrenador aún no informó a qué PokeNest se quiere dirigir, por lo que se desconoce su Remaining Distance.\r\n\r\nEste Pull Request busca corregir eso.\r\n\r\nEl primer paso es que el Entrenador deje de saber que es planificado. En lugar de esperar mensajes de \"Turno concedido\", el Entrenador se conecta al Mapa y pide conocer la ubicación de la primer PokeNest - y será el Mapa el que le conteste recién cuando lo elija \"para ejecutar\". Con esto, solucionamos a), dado que el Mapa siempre sabe a qué PokeNest se dirigen los Entrenadores que acaban de conectarse.\r\n\r\n**Lo que falta** es solucionar b). Si mantenemos el hecho de que solicitar capturar un Pokemon interrumpe la ráfaga de ejecución (simulando una entrada/salida), el Entrenador va a solicitar capturar el Pokemon, y el Planificador lo va a expropiar \"de la CPU\". _Eventualmente_ (ya sea en ese momento, o cuando se libere el Pokemon que está esperando) el Entrenador va a ir a la cola de Listos, y recién al ser elegido para ejecutar va a recibir su confirmación de captura, pudiendo pedir la ubicación de la próxima PokeNest. Pero, para este momento, el Entrenador ya fue planificado - con su Remaining Distance en 0 (porque está en su objetivo), o con una Remaining Distance desconocida (si determinamos que al recibir el pedido de captura ya se considera que su objetivo es la PokeNest siguiente). Como sea, planificaríamos con esta Remaining Distance _ficticia_, y al preguntar por la próxima PokeNest, no tendríamos en cuenta este valor para la planificación - porque _ya es_ el Entrenador activo.\r\n\r\n## Alternativas\r\n\r\nLa primer alternativa es hacer que **preguntar la ubicación de la PokeNest corte la ráfaga**. De algún modo, podemos decir que eso es lo que pasa cuando el Entrenador recién se conecta - envía el pedido y se va a Listos -, pero no estoy del todo seguro de si no trae algún inconveniente. Además, por cada captura expropiaríamos al Entrenador 2 veces (una por la captura, otra por la pregunta de la siguiente PokeNest) - nada del otro mundo, pero quizá queda medio raro. Lo más feo de esta alternativa es que el Entrenador pierde su ráfaga sin realmente tener por qué pasar por el estado de Bloqueado.\r\n\r\nLa segunda alternativa es hacer una **cola con prioridad** para los Entrenadores que recién capturaron un Pokemon. Al asignarle un Pokemon, se lo envía a una cola RR Q=1 de Listos, con mayor prioridad que la cola normal de Listos (la RR/SRDF), para que el Entrenador pueda preguntar por la próxima PokeNest y, como el Quantum es 1, vaya a la cola normal de Listos con su Remaining Distance ya conocida.\r\n\r\nLa tercer alternativa es hacer **que el SRDF sea expropiativo**, por lo que cada vez que se \"aprenda\" la Remaining Distance de un Entrenador se replanifique. Para terminar de cubrir los casos, podríamos determinar un valor configurable para usar en lugar de la Remaining Distance de los Entrenadores cuya RD es desconocida (ie, cuando capturaron el Pokemon pero aún no preguntaron la siguiente PokeNest).\r\n\r\nLa cuarta alternativa es **estimar** los valores con que planificar. Habría que definir cómo interactúa esto con el cambio de algoritmo entre SRDF y RR (si se mantiene o \"resetea\" la estimación, etc).\r\n\r\nNo se me ocurren más alternativas _por l'ahora_.\r\n\r\nMe gustaría tener _muchas_ opiniones, tanto de @sisoputnfrba/ayudantes como de todos los alumnos - que son quienes van a tener que implementarlo, je."},"comment":{"url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/comments/248785432","html_url":"https://github.com/sisoputnfrba/2016-2c-char-mander/pull/1#issuecomment-248785432","issue_url":"https://api.github.com/repos/sisoputnfrba/2016-2c-char-mander/issues/1","id":248785432,"user":{"login":"tferraro","id":7110539,"avatar_url":"https://avatars.githubusercontent.com/u/7110539?v=3","gravatar_id":"","url":"https://api.github.com/users/tferraro","html_url":"https://github.com/tferraro","followers_url":"https://api.github.com/users/tferraro/followers","following_url":"https://api.github.com/users/tferraro/following{/other_user}","gists_url":"https://api.github.com/users/tferraro/gists{/gist_id}","starred_url":"https://api.github.com/users/tferraro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tferraro/subscriptions","organizations_url":"https://api.github.com/users/tferraro/orgs","repos_url":"https://api.github.com/users/tferraro/repos","events_url":"https://api.github.com/users/tferraro/events{/privacy}","received_events_url":"https://api.github.com/users/tferraro/received_events","type":"User","site_admin":false},"created_at":"2016-09-22T01:01:17Z","updated_at":"2016-09-22T01:01:17Z","body":"Algo que me sorprendió y me gusto, es que varios hayan optado por empezar a verlo como colas con prioridades y no dudo en pensar en que seria interesante tenerlo en el tp.\r\n\r\nNo se si la idea de @afilgueira es practicable, dado que el calculo de distancia lo hace como una operación que consume una unidad de tiempo en el algoritmo RR, si agregamos que vuelva a calcularlo empezariamos a interferir con el otro algoritmo.\r\n\r\nEstoy mas a favor de las colas con prioridad porque no interfiere tanto en el resto del proceso."}}
{"actor":{"display_login":"tferraro"}}