El tiempo libre puede llegar demasiado tarde
Un dispositivo atiende un sensor y ejecuta periódicamente un modelo de IA en el mismo procesador. La carga total indica capacidad suficiente: el procesador no debería estar ocupado todo el tiempo. Sin embargo, una respuesta llega después de necesitarla. No hay contradicción: el tiempo libre puede quedar después del plazo, mientras una tarea prioritaria interrumpe la inferencia durante el intervalo útil. No basta preguntar cuántos milisegundos tarda el modelo aislado; hay que preguntar cuándo puede utilizarlos.
Estudiaremos dos tareas con números sencillos y reconstruiremos cada intervalo de ejecución. Compararemos una prioridad fijada de antemano con otra que considera el plazo más cercano. Después reduciremos el cálculo de IA y añadiremos un bloqueo inicial breve para ver el margen restante. Son tiempos sintéticos de un simulador, no medidas de microcontroladores ni aceleradores. Al final distinguiremos capacidad media, tiempo de cálculo y tiempo de respuesta, sin atribuir inmediatamente todo retraso al modelo neuronal.
Tres relojes distintos en el mismo dispositivo
Una tarea es una actividad recurrente, como leer y procesar un sensor. Cada activación concreta es un trabajo o job, una petición individual. El periodo T indica cada cuánto se libera una petición; el coste C es el tiempo de procesador necesario sin interrupciones; el plazo relativo D es cuánto podemos esperar desde la liberación. El tiempo de respuesta R abarca hasta la finalización real e incluye esperas. Todas las cantidades están en milisegundos, ms: una milésima de segundo.
Asignamos al sensor S un coste de 2 ms cada 5 ms y a la inferencia 4,5 ms cada 8 ms. Ambos deben terminar antes de su siguiente petición, por lo que D = T. Empiezan juntos en cero. Suponemos un núcleo, actividades independientes, costes constantes, ninguna espera de memoria o acelerador e interrupciones inmediatas sin coste de cambio. Las hipótesis permiten analizar el problema, pero no describen automáticamente una placa o sistema operativo. Los 4,5 ms son una entrada elegida, no un máximo demostrado de un modelo real.
| Actividad | C (ms) | T (ms) | D (ms) |
|---|---|---|---|
| S | 2 | 5 | 5 |
| AI | 4.5 | 8 | 8 |
La capacidad media indica cuánto trabajo hay, no cuándo termina
Para comprobar la carga dividimos el coste de cada actividad por su periodo y sumamos. C/T no tiene unidades: el sensor necesita dos milisegundos de cada cinco, el 40 %. La IA necesita 4,5/8, el 56,25 %. El total es 96,25 %, inferior al 100 %. Esto descarta sobrecarga media del trabajo periódico, pero aún no demuestra que la prioridad lo sitúe en los intervalos adecuados.
Consideremos 40 ms, múltiplo común de 5 y 8. Llegan ocho peticiones S y cinco AI: 8 × 2 + 5 × 4,5 = 38,5 ms de trabajo. Sobran 1,5 ms. Pero si una respuesta debía llegar a los 8 ms, un hueco a los 39 no la salva. Es como disponer de media hora por la noche: no resuelve citas incompatibles por la mañana. A diferencia de esa analogía, el cálculo puede interrumpirse y reanudarse; las reglas comparadas aprovechan esa posibilidad.
Prioridad fija: seguir el primer trabajo hasta el retraso
La primera regla da mayor prioridad al periodo más corto: S siempre precede a AI. Se llama rate monotonic, RM, porque ordena por frecuencia de activación. En cero, el sensor ocupa 0–2 ms. AI trabaja de 2 a 5 y completa 3 de sus 4,5 ms. A los 5 llega otro S y la interrumpe hasta los 7. AI reanuda y termina a los 8,5: medio milisegundo tarde. Solo consumió 4,5 ms de cálculo, pero transcurrieron 8,5 desde su liberación.
El procesador no falla ni se ralentiza: cumple exactamente la regla. El sensor liberado a los 5 ms vence a los 10, mientras el job AI anterior vence a los 8. La prioridad fija ignora esa urgencia relativa y atiende antes al sensor. Ahí nace el contraejemplo a «menos del 100 % implica puntualidad». El simulador no cancela trabajos vencidos: los completa y registra el retraso, sin ocultar la infracción eliminando la petición.
Contar interrupciones antes de conocer la duración
Podemos reconstruirlo iterativamente. La respuesta de AI debe incluir sus C milisegundos y todo el trabajo del sensor que la precede. Si dura R, el intervalo desde cero contiene ceil(R/5) trabajos S, de 2 ms cada uno. ceil redondea al entero superior. La nueva estimación depende de la anterior. Empezamos por el coste de AI y repetimos hasta que no cambie el recuento: un punto fijo, un valor que se reproduce en la relación.
Con 4,5 ms contamos un sensor y obtenemos 6,5. Pero 6,5 incluye la liberación a los 5: pasan a ser dos sensores y el total sube a 8,5. Dentro de 8,5 siguen siendo dos, así que termina la iteración. Una petición liberada exactamente al completarse otra no puede retrasar la ya terminada: esta convención explica ceil y la importancia de los extremos. La condición es R ≤ D. Aquí 8,5 > 8, aunque C = 4,5 sea mucho menor que D.
Para nuestras tareas independientes, periódicas e interrumpibles, la liberación simultánea es el caso crítico de prioridad fija: concentra peticiones prioritarias delante de la observada. No lo extendemos a cualquier sistema con bloqueos, suspensiones o aceleradores. El artículo de C. L. Liu y James W. Layland, publicado en Journal of the ACM en 1973, es la referencia teórica de estas hipótesis y de la comparación de prioridades. Es análisis matemático, no un benchmark moderno de inferencia; nuestra simulación usa datos propios elegidos.
Cambiar el orden manteniendo el mismo trabajo
La segunda regla elige el trabajo preparado con plazo absoluto más cercano: Earliest Deadline First, EDF. El plazo absoluto es liberación más D, no D solamente. Hasta los 5 ms la secuencia coincide. Entonces AI debe acabar a los 8 y el nuevo sensor a los 10. EDF deja continuar AI hasta 6,5 y después atiende al sensor, que termina a los 8,5, antes de su plazo. No aceleramos ningún cálculo: desplazamos una interrupción que la primera regla imponía demasiado pronto.
En los 40 ms simulados, EDF completa todas las peticiones a tiempo. Para tareas ideales bajo las hipótesis indicadas, el resultado clásico relaciona factibilidad EDF con U ≤ 1; no autoriza usar el 100 % de una placa ignorando interrupciones. La simulación confirma nuestro caso y el teorema exige hipótesis más precisas que un eslogan. La política dinámica requiere implementación correcta y gestión definida de sobrecarga: no sustituye analizar recursos reales.
Medio milisegundo menos elimina el retraso, no crea margen
Volvemos a RM y reducimos solo AI de 4,5 a 4 ms. U = 2/5 + 4/8 = 0,9; la iteración es 4 → 6 → 8 → 8. AI termina exactamente al vencer. No hay infracciones en 40 ms, pero el primer trabajo tiene margen cero. Sustituir el coste supuesto por una media medida daría una tranquilidad injustificada: una ejecución mayor, un cambio de contexto omitido u otra interferencia puede cambiar el resultado.
El límite suficiente RM para dos tareas, 2(√2 − 1), es aproximadamente 0,8284 bajo las hipótesis clásicas. Superarlo no implica que todas las configuraciones fallen; significa que ese test general deja de garantizar factibilidad. Nuestro caso puntual al 90 % muestra la diferencia. En cambio, observar una petición terminada después de D demuestra fallo de esa configuración simulada. Una condición suficiente no satisfecha y una infracción real son evidencias distintas.
Un bloqueo breve cambia el problema
En la última variante mantenemos C_AI = 4 ms e imponemos 1 ms inicial sin ejecución de ambas tareas. Representa una ocupación abstracta no interrumpible presente al liberarlas, no un mutex ni un controlador específico. S ejecuta de 1 a 3, AI de 3 a 5, el segundo S de 5 a 7 y AI de 7 a 9. La inferencia vence tarde aunque las tareas periódicas aún requieran el 90 %. Ese milisegundo ajeno es adicional y se cuenta en la traza.
B representa solo el bloqueo inicial impuesto. No hemos demostrado que 1 ms limite el bloqueo real ni analizado todos los protocolos de sincronización. En 40 ms el trabajo periódico suma 36 y el bloqueo añade 1: la ocupación total es 37 ms, no 36. El contraste muestra que el trabajo no interrumpible debe incluirse y que una traza completa evita confundir carga de tareas seleccionadas con toda la ocupación del procesador.
Leer el diagrama sin confundir peticiones
La figura muestra los primeros 12 ms de cuatro simulaciones; el archivo conserva los 40. Azul es sensor, verde AI y naranja bloqueo inicial. La línea roja marca el plazo del primer trabajo AI y el punto negro su finalización. El verde posterior corresponde a otras peticiones: el color identifica una actividad, no un job. Las divisiones de medio milisegundo son unidades del simulador, no interrupciones medidas. Las dos primeras filas muestran igual trabajo ordenado de otra manera.
El simulador usa ticks enteros de 0,5 ms: todas las duraciones y liberaciones caen en la rejilla sin redondeo temporal. Cada tick añade peticiones, elige según RM o EDF y resta trabajo pendiente. Registra liberación, plazo y final de cada job. Las aserciones verifican 8,5, 6,5, 8 y 9 ms, y ausencia de infracciones en EDF y RM de 4 ms sin bloqueo. El recuento de retrasos describe la traza, no una probabilidad de fallo.
Qué falta saber antes de hablar de una placa
En hardware, C es el primer dato difícil. La media medida con ciertas entradas no es automáticamente un límite superior. Rutas de operadores, memoria compartida, interrupciones, frecuencia y temperatura pueden cambiar el trabajo. La evaluación debe declarar plataforma, runtime, modelo, compilador, reloj, entradas, batch, hilos y condiciones. Con acelerador, esperar su finalización no siempre ocupa CPU: no podemos sustituir indiscriminadamente el tiempo total por C en el modelo monoprocesador.
Las llegadas tampoco tienen por qué ser periódicas: comunicaciones en ráfaga, sensores por bloques o adquisición que retrasa liberar la inferencia. El plazo del sistema puede comenzar en la medida física, mientras R empieza al liberar el job. El tiempo anterior no desaparece: debe incorporarse al recorrido sensor-respuesta junto con comunicación y actuación pertinentes. No simulamos estos elementos ni afirmamos garantía temporal extremo a extremo.
¿Qué intervención responde a la causa observada?
Reducir C con un modelo pequeño puede ayudar, como en 4 ms, pero debe conservar utilidad predictiva e incluir otros costes. Cambiar prioridades actúa sobre el orden: EDF mejora el caso sin alterar el modelo. Acortar secciones no interrumpibles actúa sobre B; mover trabajo a otro núcleo introduce comunicación y recursos compartidos. No son remedios intercambiables. La traza ayuda a elegir qué hipótesis investigar antes de comprar hardware más potente o culpar solo a la red.
Una prueba futura debe medir ejecución y respuesta por separado, registrar liberaciones y preempciones e incluir interferencias previstas. Los resultados deben contrastarse con un presupuesto explícito, distinguiendo medias, percentiles y límites demostrables. No hay aquí medidas de potencia, energía por inferencia, RAM máxima ni rendimiento de placa. Embedded es un ámbito editorial y de interés por explorar; el estudio no acredita productos ni instalaciones disponibles de EL-AI. No se afirma prueba física ni certificación.
La respuesta: el tiempo debe estar disponible antes del plazo
Puede haber capacidad libre y respuestas tardías porque la capacidad es agregada y el plazo exige un intervalo concreto. En el ejemplo, el 96,25 % da un primer final a 8,5 ms con RM y 6,5 con EDF para igual trabajo. Reducir AI a 4 ms elimina el retraso RM sin dejar margen; un bloqueo inicial de 1 ms lo hace reaparecer. La conclusión práctica es reconstruir recorrido temporal y reglas de acceso al procesador, además de medir el modelo aislado.
Fuentes, código y reproducibilidad
Código y resultados se descargan bajo el listado. Es determinista, sin semilla aleatoria. El fragmento imprime carga periódica, respuesta del primer job y retrasos de cada caso, y después las iteraciones. Se usaron Python 3.14.0 y Matplotlib 3.11.2. La referencia es de 1973, no una novedad de 2026; se leyeron hipótesis, pruebas pertinentes y límites, sin presentar nuestro ejemplo como reproducción de medidas de los autores.
from experiment import run
r = run()
for name, case in r['cases'].items():
print(name, case['periodic_utilization'],
case['first_AI_response_ms'], case['late_jobs'])
print(r['recurrences'])Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 9 de octubre de 2026.