L'ordinateur sous Linux le plus lent du monde

Parfois, certaines personnes ont des idées bizarres. Et parfois, ces personnes décident de les réaliser. Dmitry Grinberg, un Russe, a eu l'idée d'installer Linux... sur un microcontrôleur 8 bits. Il a donc utilisé un ATmega1284p, une barrette de mémoire au format SIMM (issue d'un 80286) et une carte SD de 1 Go interfacée en SPI, un mode d'accès série très lent. Pour installer Linux, qui demande normalement un processeur 32 bits et une unité MMU, Dmitry a codé un émulateur de processeur ARM pour son microcontrôleur. 

Et les performances ?

Le microcontrôleur étant assez lent (24 MHz) et émulant un CPU 32 bits, les performances sont très faibles. Globalement, il considère que le processeur émulé fonctionne à environ 6,5 kHz (milliers de Hertz, pas millions, donc). La mémoire vive est accédée à 300 ko/s et la carte mémoire à environ 200 ko/s. Au final, il faut environ 2 heures pour démarrer en ligne de commande et 4 heures de plus pour démarrer un serveur X sous Ubuntu...

Le code source de l'émulateur et du système est disponible et les composants simples à trouver pour ceux qui veulent essayer...

Posez une question dans la catégorie Les news : vos réactions du forum
Cette page n'accepte plus de commentaires
14 commentaires
    Votre commentaire
  • Iksarfighter
    Sympathique performance !
    0
  • SpadVIII
    J'ai un peu du mal à croire la chose: Il doit manquer plein de fonctions obligatoires sur un micro-controlleur 8 bits comme celui-ci, qui sont requises par le kernel Linux (MMU, mode superviseur...). Même en émulant. Enfin, je ne m'y connais pas assez pour porter un jugement définitif, mais je reste étonné tout de même...
    0
  • Col Hanzaplast
    Je pensais être dans le Top Ten avec mon Goupil 386SX16 et sa puissance de 0,2 Bogomips,
    mais je m'avoue battu :)
    A l'époque il me fallait une nuit pour recompiler le kernel. J’appliquais donc le patch kernel sur l'arbre des sources le soir, lançait la compile et partait me coucher. J'ai arrêté le jour où elle n'était plus terminée à mon réveil à cause de l'agrandissement incessant du kernel
    0