Los microprocesadores de las naves espaciales

#1   Chips muy fiables no como los que hacen hoy día que se queman solos ":"troll":"

#2   #1 Ya no hacen z80s como los de antes.

#3 Hombre, para calcular a mansalva...con esos sobra. Además el ensamblador es tu amigo. Ni que decir que los SOs de tiempo real ayudan bastante.

#3   Si con esos procesadores varias generaciones atrasadas en relación a lo que hay en el mercado se consiguen semejantes logros la única explicación es que el software tiene que ser de vértigo de bueno.

#4   Espero ansioso el primer comentario sobrado del tipo "donde juego al counter strike va mucho mejor y tiene cuatro cores".

#5   #3 Con un PowerMacintosh a 200 Mhz
bimg2.mlstatic.com/cpu-mac-apple-200-mhz-expandible-a-512-mb-ram-por-r
se pueden hacer todo tipo de tareas de edición gráfica, manejo de textos, etc... de hecho me parece un procesador colosal teniendo en cuenta que va dirigido a realizar calculote puro y duro, y sin duda programado de manera optima y eficiente...

#6   Los chips que van al espacio tienen que resistir temperaturas extremas, radiaciones de todo tipo, y deben funcionar en un aparato con graves escasedades energéticas y de refrigeración. Meterle mas MHz de los que necesita es tener que poner paneles solares mas grandes y un radiador mas grande. Y subir un kilo al espacio es mas caro que un kilo de oro.

Además, deben ser chips fiables y altamente probados en el momento de empezar el diseño de la sonda o nave.

#7   Además para la mayoría de las tareas que tienen que desempeñar les sobra tiempo, sobre todo en trayectorias orbitales. Es innecesario meter un procesador "rápido".

#8   Ahora falta el típico comentario (basado en películas) que los programas que llevan están hechos en los 60s porque no fallan y no encuentran programadores, bla, bla, bla. Mejor empezar por este artículo (hay unos cuantos: lospibesdelautn.foroactivo.com/t370-un-mendocino-en-la-nasa "En la NASA tienen una situación interesante
porque las misiones Viking, que ya han salido de nuestro sistema solar,
siguen funcionando y enviando datos. Entonces han contratado a muchos
ingenieros jubilados que son los únicos que comprenden los sistemas de
navegación. Las máquinas son de los años ´50 y ´60 y los programadores
son los mismos porque las generaciones nuevas no tienen idea de cómo
son esos software")

Para saber más: "NASA unplugs last mainframe" www.networkworld.com/community/blog/nasa-unplugs-last-mainframe

#10   #9 No ha retrocedido, se ha vuelto tan complejo por las nuevas opciones que dan las computadoras modernas que no ha avanzado al ritmo del hardware, pero no es lo mismo: una aplicación de hace 30 años tenía menos oportunidades de fallar porque no dependía de tanto hardware ni estaba pensada para ser ejecutada en distintos modelos de computadoras (no hablo ya de en distintas arquitecturas)... hay muchísimas más variables que pueden fallar hoy día.

Y sobre el rendimiento... una aplicación pequeña se puede hacer si hace falta hasta en ensamblador, pero cuando hablamos de una aplicación como la web de un banco, que permite transacciones bancarias, necesitas un lenguaje y una plataforma que te permita desarrollar en meses algo que en ensamblador te llevaría toda la vida, aparte de que no puede atarte a un hardware en específico porque no permitiría actualizaciones sin reprogramar parte.

Es como decir que los teléfonos móviles han retrocedido porque hace 10 años la batería duraba una semana y ahora dura un día o dos, o porque un Nokia 5110 no se colgaba como se puede colgar ahora un smartphone con Android.

#11   #5 Ahora solo te falta una buena capa de acero para protegerlo de la radiación, no vaya a ser que se cuelgue antes de guardar los cambios.

#12   #10 ¿No había tantos modelos en los 80? ¿En serio? Había incluso más variedad que ahora. Ten en cuenta que actualmente hay un par de plataformas en sobremesa (PC y Mac) y poco más en portátil (ARM y algo de x86). En los 80 había incluso distintas arquitecturas x86 (no sólo IBM PC), distintas M68K (Atari, Amiga, Mac, QL, ...), alguna ARM (RiscPC), Z80 (Amstrad CPC y PCW, Sinclair, ...), 6502 (C64, Apple II, KIM-1, ...), etc.

En cuanto a lo de hacer los programas en ensamblador, se puede usar un método intermedio (que casi nadie usa): Forth. Está en un punto intermedio entre ensamblador y C.

#13   ¿Hal 9000 no está? Qué decepción...

#15   #12 En sobremesa más bien solo hay PC, pues "PC" y Mac actualmente ambos son la misma arquitectura x86, solo que con distinto sistema operativo.

#16   #8 Pues vaya mierda de documentación...

#17   Los de SpaceX usan en el cohete Falcon 9 y en la capsula Dragon ordenadores PPC, aunque no radiation hardened, sino "radiation tolerant", por abaratar. Y casi todo con Linux.

#8, tu primer enlace no se yo si... amos a ver, las Viking fueron las sondas que aterrizaron en Marte. Las únicas que han salido del sistema solar son las Pioneer y las Voyager, y estas últimas funcionan aún. Las Pioneer es posible que funcionen, pero la señal era ya muy débil hace década y pico y se dejó de intentar contactar con ellas.

#18   #8 Las Viking fueron a Marte. Las que salieron del sistema solar fueron las Voyager 1 y 2, y las Pioner 10 y 11.

#19   #9 siento algo de pena por ti si piensas que el software no ha avanzado demencialmente mucho en estos últimos tiempos, y las estadísticas de errores podrían ser hasta despreciables si utilizamos probabilidades teniendo en consideracion la diferencia entre el numero de programadores, su instrucción, lineas de código, opciones de tecnología, y errores críticos cometidos. poniendo como ejemplo www.google.com, hasta ahora no me a sucedido un error, y es un programa que al segundo lo usan mas de dos o tres gatos( como lo eran antes los usuarios de software ).

#20   #3
La NASA es especialista en la investigación del desarrollo de código tolerante a fallos.
El esquema básico es desarrollar los módulos mediante varios grupos independientes. Cada uno de ellos desarrolla el módulo sin contacto con el resto, cumpliendo con estándares de calidad y con una especificación muy clara y detallada.
Luego, hay dos estrategias básicas en tiempo de ejecución:
-Ejecutar todos los módulos y luego decidir cual o cuales de ellos dan resultados razonables (votación, tests estadísticos, validación lógica de resultados...)
-Ejecutar un módulo, y si éste falla (analizando sus resultados con uno de los métodos mencionados en el anterior punto), seguir con el siguiente hasta encontrar uno que de resultados válidos.

#21   #10 Complejo no, cómodo, ¿Para que programar nada que ya está hecho? ¡usemos librerías (con sus fallos) que dependen de otras librerías (con sus fallos) que dependen de....! Pongamos capas y capas de abstracción para que programar sea mas fácil, aunque luego requiera 1000 veces mas recursos que programado sin librerías externas.

#22   #9 2.- Bus de datos: 8->64 8/1

2^8/1 A no ser que andes multiplicando el exponente, en cuyo caso es correcto, pero...

#23   #10 "Es como decir que los teléfonos móviles han retrocedido porque hace 10 años la batería duraba una semana y ahora dura un día o dos, o porque un Nokia 5110 no se colgaba como se puede colgar ahora un smartphone con Android. "

Es que han retrocedido.

Que los móviles ahora se cuelguen, sean lentos, tarden en cargar software, la batería les dure un día en vez de una semana y que encima sean tan grandes que parece que llevas de paseo el mando a distancia de la TV, me parece un retraso muy grave para hacer cosas no muy alejadas de lo que ya podíamos hacer con móviles menos potentes hace 10 años.

#24   #9 Yo creo que se refería al software que se monta en esos equipos espaciales. En cualquier caso, tienes razón en que el software, en muchísimos casos, es un cuello de botella para el máxima aprovechamiento de la tecnología informática, pero considera también que en el desarrollo de hardware se invierte más tecnología y recursos de mejor calidad que en el desarrollo de software. Aún así, los circuitos integrados no están exentos de fallos de diseño. Y por otro lado, todos sabemos que, en ocasiones, la diferencia entre un buen software bien optimizado son un puñado de miles de euros que se les dejan de pagar a los programadores, analistas, diseñadores y demás (lo que implica que trabajen menos motivados), una mala planificación de tiempos (además de trabajar desmotivado te obligan a hacerlo rápido), una falta de coordinación del equipo debido a un mal liderazgo del responsable, distribuciones no equitativas del trabajo, etc, etc, etc.

#20 buen aporte, aunque no esperaba menos de esa gente.

#25   #12 ¡Sacrilegio! Z80... ¡te falta los MSX! (también se te olvida mentar el mundo de los µControladores, que hoy por hoy son ampliamente utilizados)

#26   #21 Si no utilizáramos el trabajo realizado por otros programadores (librerías) el desarrollo de las aplicaciones sería mil veces más lento y costoso.

No he oído a nadie quejarse de la librería stdio ni hay errores en dicha librería. Se pueden utilizar librerías y programar eficientemente y sin errores.

#27   #23: lo de la batería es falso. Quita toda conexión de datos y programillas ejecutándose por detrás, baja el brillo de la pantalla y deja de mirar el chisme cada dos minutos. Tendrás un teléfono que hará todavía muchas más cosas que uno de hace 10 años (que eran llamadas, sms, agenda, juegos simples, calculadora, alarma) y la batería durará si no una semana, si cuatro o cinco días. Esos dos o tres días por las pilas que le tenías que cambiar al diskman.

#28   #12 Y los VIC-20 de Comodore con aquellas memorias de expansión de 8k...¡ que tiempos !

#29   #12 ¿Forth en un punto intermedio entre ensamblador y C?



#9 El otro día salio ese tema de conversación durante una cena: El software está retrocediendo respecto al hardware. Mientras que el hardware es cada vez más y más potente, nos comemos esa potencia con software cada vez más amigables al programador y más costosos para las CPU.

Se empezó programando en ensamblador, se paso a C, y poco a poco se han ido imponiendo las "maquinas virtuales" (Java, C#, Flash?) corriendo bytecodes y ahora el "futuro" parece que será javascript, que es puro texto en ascii/unicode.

Cada vez se necesita más CPU para conseguir los mismos resultados que hace años.

#30   ¿Con qué procesadores se "llegó a la luna"?
Siempre digo en plan de coña que llegamos con la tecnología del Spectrum, pero me gustaría saberlo

#31   #26 Pero programar no se vuelve "complejo" por la "dificultad de las rutinas empleadas" o por la "cantidad de código" si no por la cantidad de código "extraño" donde no se tiene claro que hace ni como y no se tiene el control. El problema es que muchos están acostumbrados a usar librerías muy pesadas para programar cualquier cosa, porque es facil, no por ser complejo, otro tema es que luego un programa de mierda requiere 1Gb de RAM porque la librería usada lo requiere para poder instalarlas.

#32   #28 Yo tuve uno
#29 No digo que esté a medio camino. Me refiero a que es más portable que ensamblador y de aún más bajo nivel que C (RPN entre otras cosas).

#33   #5 El procesamiento de imagen cada vez debe pesar más...

#34   #11 Acero no, plomo.

#35   #9 Por tu percepción del software parece que sólo conoces Windows XP y el Office 2000.
Existen motores de software avanzadísimos: ahí está el PHP, realizando interpretacion y compilacion de lenguaje en tiempo real -cosa impensable hace años - , o el interprete Java en los Android.
O los sistemas de reconocimiento facial , filtrado de voz...
O el codec H.264, que hace maravillas comprimiendo videos de alta resolución.

#36   #3

precisamente se eligen procesadores que sean fiables, no necesitan un I7 porque no van a instalar un windows 7

#37   #29 Yo creo que el problema es que resulta "mas barato" poner mas memoria que optimizar el código ... o usar mas procesador, o mas disco duro, etc...

Al precio que esta el hard, resulta mas barato comprar un par de gigas de RAM que dedicar un equipo a reducir el consumo.

#38   #34 Cierto, pero en realidad cualquier material lo suficientemente grueso.

#39   #12 No digo que no hubiese variedad, sino que se hacían programas pensando mucho más en el hardware de la máquina. No hablo de los PCs, eso fue una revolución (PC era el de IBM, el resto eran "PC compatibles", la denominación ya dice mucho). Antes, si hacías un juego para el Spectrum, tenías que elegir si iba a usar 16, 48 o 64 Kilobytes, y aunque compartiese microprocesador con el Amstrad CPC, no era compatible porque el resto del hardware (véase la memoria, las interrupciones...) no funcionaban igual. Los programas se compilaban casi para cada modelo de computadora, para usar exactamente los recursos que ese modelo tenía. Otra cosa es que los siguientes modelos tratasen de ser compatibles, pero ni siquiera había un SO común entre distintas plataformas para ayudar, y si lo había muchas veces se ignoraba (véase el MSDOS)

#21 El usar librerías no está reñido con la eficiencia. Si programases todo "a pelo" tendrías que crear tus propias librerías, igualmente. Sencillamente intentamos no reinventar la rueda cada día.

#23 Son dos mercados distintos: Nokia sigue sacando terminales baratas con una batería que dura semanas, como éste: www.gizmag.com/nokia-105-mobile-phone-month-long-battery-life/26413/ y ¡con pantalla en color por 15€!
El tamaño es porque la gente lo reclama: en un HTC Hero no se puede navegar tan cómodamente como en un iPhone o en un Galaxy III. ¿Que quieres uno más pequeño? Pues tienes el Galaxy III mini, o el Xperia mini, pero viendo lo que se han vendido no diría que a la gente les mole.

#40   #12 Mi Amiga One, del 2003, usa un PowerPC G4 a 933MHz, y aún hay usuarios de PCs actuales que se quedan fritos cuando ven lo que puede hacer. El último modelo de Amiga es el AmigaOne X1000 ( a-eon.com/?page=x1000 ), de 2012, tiene un PowerPC PA Semi Dual-core PA6T-1682M a 2.0GHz/64 bits y una CPU programable XMOS XS1-L2 124 "Xena" 500MHz.

En general, la filosofía en el desarrollo para Amiga ha sido siempre ha sido siempre la de exprimir las capacidades del hardware al máximo, dado que nunca se ha podido contar con actualizaciones periódicas de CPUs. No te queda otra que apañarte con lo que tienes, sacándole todo el partido posible, a base de optimizar el software hasta sus límites.

#41   Recomiendo echar un vistazo a Single event Effects, single event upsets (SEU), single event transients (SET), Single event LAch up (SEL) , SEGR, SEBR, Son todos effectos diferentes debido a la radiacion que afectan a memorias y logica. Desde transitorios (los peores) a permanentes. Es cierto que hay mucha preocupacion con las nuevas tecnologias nanoscopicas porque "en general" son exponencialmente mas sensibles a la radiacion (sobre todo si tenemos en cuenta que el numero de transistores es mayor y por tanto las probabilidades de fallos incrementan)
El tema de fiabilidad en entornos de radiacion es complicadisimo. Los conceptos no son triviales. Basicamente la Ingenieria de Fiabilidad (reliability engineering) intenta evitar que unDefecto (fault) se convierta en un ERROR y que este a su vez genere un fallo (FAILURE) que a su vez genere un Fallo Catastrofico.
Hay 2 maneras de atacar el problema:
A) Fault avoidance: (prevenir que los fallos debido a radiacion no se generen). Esto es imposible al 100% ya que fotones, protones, muones, electrones, neutrones .... todos generan fallos. Incluso a nivel del mar.
B) Fault tolerance: Los fallos son inevitables. Intentemos por tanto paliar sus errores.


Para conseguir B, hay tres recursos que se usan generalmente entrelazados:

- Redundancia de Informacion (es decir bits extra, ej: CRC, Paridad, Codigos Hamming
- Redundancia de Tiempo (repetir la ejecucion de instrucciones varias veces y comparar resultados)
- Redundancy de Spacio: Tener varias estructuras replicadas, por ejemplo 3 memorias replicadas (TMR), dos (DMR) etc......, dos procesadores)

Disculpas por el mal uso del lenguaje.

#42   #37 Eso de siempre. A finales de los 80, cuando un 386 era el tope de gama, un berzas me soltó que el programaba en GWBASIC y que si no corría lo bastante, que el cliente se comprara un ordenador más potente.

#43   #23 "El tamaño es porque la gente lo reclama: en un HTC Hero no se puede navegar tan cómodamente como en un iPhone o en un Galaxy III. ¿Que quieres uno más pequeño? Pues tienes el Galaxy III mini, o el Xperia mini, pero viendo lo que se han vendido no diría que a la gente les mole. "

No, no lo reclaman: Es que es lo que les venden. No saben que hay alternativas.

Cuantas veces habré oído voces de incredulidad y admiración cuando saco el Xperia Mini para mandar un whassap. No saben que existen móviles pequeños que hacen lo mismo.

De todas formas, aunque sean pequeños siguen teniendo los mismos problemas que los grandes: Lentos, toscos, tienen que cargarse todos los días, etc...

#44   #39 "El usar librerías no está reñido con la eficiencia."
Sí, lo está, siempre, a no ser que haga SOLO lo que quieres que haga, y eso no ocurre nunca (a no ser que la hagas tu y puedas eliminar partes innecesarias), otro tema es que no sepas hacerlo mejor de como lo hace la librería, ese es otro tema.

Pero mi problema principal es otro, y es el tema de los requisitos, ejemplo.
Quiero hacer un "hola mundo", y me apetece hacerlo en .NET
¡SORPRESA! Obtienes un "Hola mundo" que requiere 1Ghz de procesador, 512Mb de ram, 850MB de Disco, y como mínimo un windows vista sp2. Porque sin eso, no puedes instalar el .NET Framework, necesario para ejecutar mi puto "Hola mundo"
Ahora cambia "Hola mundo" por "cualquier programa".

#45   #44 Si nos ponemos así, para hacer un "hola mundo" en cualquier lenguaje necesitas casi lo mismo, porque son los requisitos básicos para instalar Windows/Linux.

Como comenté antes, tienes que mirar los requisitos que quieres cumplir al hacer un programa y elegir cómo hacerlo. Un engine gráfico no está hecho ni en Java ni en C#, sino en C++, y un hola mundo se puede hacer con un .bat en el que pongas "@echo Hola, Mundo", te ocupará lo mínimo que puede ocupar un fichero y será retrocompatible hasta con el MS-DOS de los 80.



#43 Si no saben que hay alternativas es que ni se molestan en mirar, ya no es un tema tecnológico sino de pura vagancia, porque sale en cualquier catálogo de Phone House o de cualquier operadora.

#46   #45 El problema es que pudiendo hacer un bat, la mayoría se acostumbra en hacerlo en .NET cuando no hace falta.
Luego te descargas cualquier chorrada, un cliente de correo, un juego de damas, o algo que no tiene porque requerir nada, y te encuentras que te hace falta el .NET, y si no tienes 512MB de ram no puedes usarlo.
El programador dirá que el cliente no tiene los requisitos mínimos, ¡mentira! ¡el software esta mal diseñado!

La librerías gráficas tres cuartos de lo mismo, muchos juegos y aplicaciones no funcionan en tarjetas sin aceleradora, cuando no les haría falta para NADA, como el ajedrez de windows, no requiere grandes gráficos ni gran velocidad, pero sin aceleración 3D no funciona.

Las librerías hay que usarlas cuando hay que usarlas, no siempre para cualquier cosa.
Dicho de otra manera, un "programador" que no sabe hacer las cosas sin librerías no es un programador, es un usuario de esas librerías.

#47   Para #14. #9 expone una realidad. El hardware ha avanzado en capacidad y velocidad una barbaridad respecto a las tecnologias en desarrollo de software. Si se aprovechara al 100% la potencia real del hardware actual tendriamos en casa siempre un PC una o dos generaciones por delante de la siguiente.