Dartanyan escribió:Según este vídeo, las FPGA tienen lag, pero poco:
El metodo utilizado en el video presenta demasiados problemas, ni caso a esos numeros ya que son totalmente accidentales y sin valor alguno.
Si utilizas una camara de 50 FPS, eso te da 20ms entre frame, con lo que un valor de 0.1ms y un valor de 19.9ms de retardo te va a dar exactamente el mismo retardo, osea 20ms.
Un margen de error de 20ms para medir latencias es un margen demasiado grande como para tomar en serio ese tipo de mediciones. Y diras, bueno pues cogiendo una camara de alta velocidad, de por ejemplo 1000 FPS, si se podria sacar datos con margenes mas decentes. Pues en teoria si, osea tendrias margenes de 1ms que bueno entre lo que nos movemos ya margenes de error de 1ms pues son aceptables. Pero ahi no queda la cosa, porque ahora viene la segunda parte... y es que las maquinas que mides tienen un refresco, y ese refresco suele ser de 50 o 60 Hz, eso quiere decir que a lo mejor desde que pulsas la tecla hasta que ves el resultado por la pantalla pasa 1 frame de refresco entero porque el ciclo de lectura de input ya ha pasado en el juego/programa y esta ya con el ciclo de pintado, lo que nos volveria a meter en 20ms (50Hz) o 16.67ms (60Hz).
Obviamente hay soluciones, como podria ser leer el input del mando al final de cada linea de dibujado y entonces cambiar ya el color de pintado para asi obtener respuesta de manera mucho mas rapida y no tener que esperar al frame siguiente (aunque esto obligaria a hacer un software especial de testeo para cada maquina y solo serviria para CRT y no para LCD).
Ademas hay muchos retardos a tener en cuenta en todo el proceso y que normalmente se obvian, asi que no es tarea nada sencilla medirlo con margenes de error bajos.
Yo mismamente, hice medidas de retardos en la MiSTer para saber cuanto retardo te puedes esperar de ciertos procesos y del procesado de algunos mandos que tenia por casa, pero al menos los medi con un analizador logico donde el margen de error es infinitamente mas pequeño. Pero bueno, igualmente las medidas tambien varian bastante dependiendo de la "suerte" de cuando coincide la pulsacion respecto al polling o el proceado del juego/programa dentro de la FPGA... pero bueno.
Asi de manera simple el restardo en la entrada en MiSTer utilizando USB es de unos 200us a 1.2ms mas lo que tarde el controlador del mando usb en detectar, procesar y codificar la pulsacion. Y esto ultimo es lo mas importante, ya que he visto mandos con menos de 1ms y mandos chineros con valores variables desde 20ms a 50ms (con lo que esto implica). Es mas he visto como mandos pasaban de 7ms de retardo a 1ms simplemente con una actualizacion de firmware.
Si usas SNAC el retardo en el input es descartable totalmente, no recuerdo ahora el valor pero creo que era de muy pocos us ya que es una conexion directa a la FPGA.
Te dejo el enlace al post que puse hace tiempo en este mismo hilo sobre este tema:
hilo_mister-fpga-plataforma-que-implementa-consolas-clasicas-microordenadores-y-arcades_2306954_s2900#p1751913345