Habia prometido algunas historias, para en cierta forma mostrar que trabajar en informatica no tiene nada de aburrido
De paso les comento una decision que tome cuando dirigia el equipo de R&D en Breezecom/Alvarion: todos y cada uno de los ingenieros del departamento tenia que viaja 1 vez al ano a visitar un cliente (no tan facil cuando todos los clientes estan en el exterior), mi opinion es que esto tiene doble valor:
1. Los motiva
2. Aprenden muchisimo, creo que todos sabemos que un ingeniero de R&D se convierte en otra persona (algunos diran: se convierte en persona 🙂 ) despues de pasar 3-4 dias con un cliente.
Volviendo el tema, aca va una cortita:
En Fibronics habiamos desarrollado los primeros y unicos equipos FDDI del mundo, como pueden ver en wikipedia, FDDI era una red de alta velocidad (para aquellos tiempos 100Mbit/s era mucho) y larga distancia (kilometros), compuesta por dos anillos de fibras opticas, de tal manera que si se cortaba una fibra o se caia un equipo , la red se sabia recomponer utilizando partes del anillo secundario (hace mucho que no pienso en FDDI, pero tenia cosas interesantes en su diseño).
Para saber cuando activar el anillo secundario cada nodo de la red verficaba continuamente la calidad de su enlace para saber que no bajaba de ciertos niveles.
Hasta ahi todo bien, resulta que en una instalacion en USA, empezaron a reportar que el equipo mostraba errores en el enlace, no llegaba a activar el secundario pero se quejaba. Mandamos tecnicos a revisar y el enlace estaba perfecto. Pero el problema seguia, lo curioso era que siempre pasaba entre las 3:00 y 3:15 de la manana.
Ahi es cuando los ingenieros empiezan a desarrollar todo tipo de teorias (algunas mas conspiratorias que otras):
«seguramente hay picos de electricidad a esa hora», dijo alguno asi que mandamos monitorear la red electrica y………. nada, todo perfecto
«seguramente el sereno sale a dar una vuelta y toca algo», se imaginan que mandamos a un tecnico nuestro a seguir al sereno a esa hora, y …. nada
A todo esto el cliente se ponia mas nervioso, habia pagado cientos de miles de dolares por el sistema, y (a pesar de que le funcionaba perfecto) lo tenia nervioso la situacion de esos mensajes que indicaban un posible error, y nos puso un ultimatum, ese mensaje tenia que desaparecer en una semana o devolvia los equipos………
Que hacer en una situacion asi?
El sistema funcionaba perfecto, no se perdian ni retransmitian paquetes, no se activaba el link secundario porque los errores reportados eran menores al threshold para activarlos, y le dan un ultimatum de esa indole?
Alguno de ustedes debe haberse imaginado: El cliente siempre tiene razon, hicimos lo que pedia, una nueva version de software que hizo desaparecer el mensaje (lo cambio por un contador bien escondido 🙂 ), y el cliente feliz 🙂
Pero, a pesar de que el cliente se quedo contento y no protesto mas, seguimos buscando y analizando el problema. Meses despues en unas pruebas en el laboratorio se me ocurrio poner enlaces de kilometros de distancia (como se hace eso en el laboratorio?, por suerte era fibra optica y es muy liviana, asi que teniamos roletes de varios kilometros cada uno, a distancia de 50 cm entre si), y ahi reprodujimos el problema.
En realidad fue pura casualidad, no recuerdo que testeabamos, cuando de repente empezamos a ver el mismo mensaje de error, lo interesante fue que el problema aparecia cuando transmitiamos paquetes de un cierto tamano (ejemplo 124 bytes) pero desaparecia cuando los paquetes eran de otro tamano (ejemplo 123 o 125 bytes).
Que pasaba? Por suerte en esa epoca todos los que tenian algo que ver con FDDI eramos conocidos, asi que llame a un amigo que estaba disenando el primer Sniffer de FDDI y lo llame a que traiga su aparato (todavia en Beta), y ahi descubrimos el problema:
El problema aparecia solo cuando el tamano del paquete era tal que su transmision a una velocidad de 100Mbps demoraba lo mismo que la latencia del anillo FDDI, ni un nanosegundo mas ni menos, tenia que ser exacto. Eso causaba que la «limpieza» del paquete viejo no funcionaba bien y dejaba restos en la red, que eran tan pequenos que no parecian paquetes sino basura y que era lo que a nuestra alarma no le gustaba, pero como no eran paquetes validos no molestaba en absoluto, y despues se limpiaban por si solos (por si alguno le interesa, puede leer el standard de FDDI, esa parte de la arquitectura del protocolo es muy ingeniosa).
El problema era del chip, fabricado por AMD y obviamente nunca lo habian visto (demoraron anios en arreglar el «problema»), y obviamente entre las 3:00 y 3:15 de la manana en la red de nuestro cliente corria alguna aplicacion que usaba paquetes de un tamano determinado de tal forma que se daba esta situacion. Al final la «solucion» que le dimos al cliente era la correcta, simplemente habia que ignorar la alarma.
En fin, un ejemplo de que trabajar en informatica a veces es un poco mas «entretenido» que estar escribiendo codigo frente a una pantalla, por suerte (algunos diran por desgracia) cuando los productos los usan clientes de verdad, la cosa se pone divertida …..
Read Full Post »
Pablo Brenner & Sergio Fogel Blog 