La fin d'une Epoch

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
8
sept.
2001
Rien à voir
Ce dimanche à 3h46'40 (1:46:40 UTC), les horloges des machines UNIX égraineront leur milliardième seconde.
La plupart des ordinateurs basent en effet leur date sur le temps écoulé depuis le 1er janvier 1970. (The UNIX Epoch)

Le temps écoulé étant rarement stocké en décimal, il ne devrait pas trop y avoir de bug à déplorer. KMail est une des rares applications à avoir annoncé un bug pour le 9 septembre (dans une ancienne version).
Les _gros_ problèmes devraient arriver en 2038 quand 32 bits ne seront plus suffisant pour coder le nombre de secondes depuis l'epoch. Le problème est connu depuis longtemps (il est évoqué dans le "Unix Programmer's Manual" de Thompson et Ritchie du 3 novembre 1971), mais quoiqu'on dise ou fasse il restera des machines 32 bits qui mettront la zone en 2038.

Tout bon geek se devant de marquer l'évenement, un fort traffic est à prévoir sur la tribune de LinuxFR dans la nuit de samedi à dimanche. N'oubliez pas vos clients NTP, et bon anniversaire. (Notons que le vrai geek dormira tranquillement pendant que sa machine postera toute seule sur la tribune)

Aller plus loin

  • # Ca va etre la fete :-)

    Posté par  . Évalué à -1.

    Rendez vous sur #linuxfr@IRCNET à l'heure dite!

    Et bonne nouvelle Epoch à vous tous :-)

  • # 2038

    Posté par  . Évalué à 8.

    En 2038, nous ne serons pas encore à 2^32 secondes mais à 2^31. Donc, si on gère les dates en unsigned, on devraient pas trop mal s'en sortir. 2^32 c'est en 2116.

    Enfin, ce n'est pas tellement l'architecture 32 bits du microprocesseur qui est en cause, mais plutôt la taille des champs dans les structures du noyau. Si gcc dévide de passer le type long à 64 bits (ce qui est permis par la norme C il me semble), une recompilation suffira à corrier le problème, même sur les processeurs 32 bits.

    • [^] # Re: 2038

      Posté par  . Évalué à 1.

      Mais si le compilateur passe le long en 64 bit alors que la machine est en 32 bits, il ne va pas y avoir une serieuse baisse de performance de tous les soft ?

      • [^] # Re: 2038

        Posté par  . Évalué à 7.

        En théorie non. D'après la norme, l'int est "le plus grand entier manipulé rapidement par le processeur".
        long est "un entier au moins aussi grand que int".

        Il est possible d'avoir un long qui soit beaucoup plus lent, les endroits où la vitesse est importante doivent utiliser int. Le problème est le même que sur les 286 où pour beaucoup de compilateurs int = 16bits et long = 32bits.
        D'autant plus que normalement, l'heure n'est stockée que sur des time_t et non des int ou des long. Faire passer time_t à 64-bits ne devrait poser d'énormes problèmes de vitesse (les calculs intensifs sur la date sont très rares).

        • [^] # Re: 2038

          Posté par  . Évalué à 1.

          "normalement" l'heure est sur un time_t...

          Enfin perso, j'utilise java.util.Date et donc ca ne buggera pas tant qu'il y aura quelqu'un pour maintenir une JRE correcte. (Ca devrait même supporter les passages à des calendriers non-grégoriens. Faudrait que je regarde ca tient...)

        • [^] # Re: 2038

          Posté par  . Évalué à -1.

          > D'après la norme, l'int est "le plus grand entier manipulé rapidement par le processeur".

          Merci de donner la référence d'une supposée citation de la norme. Je ne trouve aucune référence à cela dans ISO/IEC 9899:1999 (pour le C). "int" est suffisament grand pour contenir les valeurs comprises entre INT_MIN et INT_MAX,telles définies dans <limits.h> (6.2.5 [#5])

          Par contre, il existe bien des types entiers spécifiés tels qu'ils soient les plus rapides ayant au moins une certaine taille. Exemple: int_fast32_t (7.18.1.3). Ce sont des typedefs définis dans <stdint.h>

          > Faire passer time_t à 64-bits ne devrait poser d'énormes problèmes de vitesse.

          C'est déjà le cas sur certaines architectures. Je pense aux IA-64, Alpha, SPARC V9. Bref, les archis 64-bits quoi. ;-)

          • [^] # Re: 2038

            Posté par  . Évalué à -1.

            > Merci de donner la référence d'une supposée citation de la norme.

            Moi j'ai effectivement ca dans le K&R ("Le langage C" par Kernighan & Ritchie), paragraphe 2.2.
            Ca n'est pas une norme a proprement parler, mais au moment au ils ont ecrit ce bouquin, le C n'etait pas normalise de toute facon...

      • [^] # Re: 2038

        Posté par  (site web personnel) . Évalué à 2.

        Vous pensez pas que d'ici 2038 les logiciels ne seront plus les mêmes qu'aujourd'hui?
        Il nous ont pété les couilles pour l'an 2000, et il n'y a eu aucun probleme sur les soft récents (enfin je crois, arrétez moi si je me trompe)

        • [^] # Re: 2038

          Posté par  . Évalué à 3.

          C'est vrai. C'est ce que se disait les programmeurs Cobol il y a 20 ans, et c'est encore ce qu'on se dira en 2018.

    • [^] # Re: 2038

      Posté par  . Évalué à 3.

      Malheureusement, beaucoup de programmeurs n'utilisent pas "time_t" pour stoquer l'heure mais "int". Et faire passer "int" en 64-bits sur des processeurs 32-bits est totalement irréalisable pour des raisons de preformances

      • [^] # Re: 2038

        Posté par  . Évalué à 2.

        Oui, calculer en 64 bits sur un proc 32 bits, c'est environ deux fois plus long, c'est sûr.

        En fait, il faidrait juste passer "time_t" en "long long". Maintenant, si les programmeurs sont des porcs et qu'ils ont directement utilisé int, ça leur apprendra. De toute façon, à la compil, on doit pouvoir avoir un warning quand on fait une conversion avec perte, non?

        • [^] # Re: 2038

          Posté par  . Évalué à 5.

          > Oui, calculer en 64 bits sur un proc 32 bits, c'est environ deux fois plus long, c'est sûr.

          Non, beaucoup plus que ça.
          Pour une addition il faut additionner deux fois 32 bits, puis gérer l'éventuelle retennue. Pour une multiplication ou une division c'est beaucoup plus compliqué (comme pour multiplier 2 nombres à chiffres... 42 * 51 c'est plus comliqué que de faire 4 * 5 et 2 * 5)

          > De toute façon, à la compil, on doit pouvoir avoir un warning quand on fait une conversion avec perte, non?

          Je ne connais pas l'option de gcc qui fait ça. :(

  • # Introduction à NTP

    Posté par  . Évalué à 10.

    Pour avoir sa machine à l'heure.

    1 - Choisir un serveur ntp.
    La première chose est de se renseigner auprès de son provider. Nerim fournit ntp.nerim.net pour ses abonnés.
    Si votre fournisseur n'a pas de serveur, ecrivez pour lui dire d'en mettre un en place et rabattez vous sur un public en attendant. http://www.eecis.udel.edu/~mills/ntp/clock2.htm(...) pour une liste de serveur (3 sont Francais). N'oubliez pas de lire le champs "Access Policy".

    2 - Choisir son client
    Deux possibilités : soit vous prenez un petit client qui met le PC à l'heure quand il est lancé (au démarage par exemple), soit lancez le deamon NTP qui corrigera en permanence les écarts de votre horloge et qui pourra servir de serveur pour le reste du réseau si vous avez plusieurs machines.

    Pour le client "One shot", ntpdate est très bien.
    Installation et conf sur Debian :
    - aptget install ntpdate
    - mettre l'ip du serveur ntp dans le script /etc/init.d/ntpdate


    Si vous utilisez Windows, NTPTime fait le boulot sans girophare ni quoique ce soit.
    http://home.att.net/~Tom.Horsley/ntptime.html(...)
    - modifier le .reg pour indiquer le serveur et le repertoire de log
    - fusionner le .reg (clic-droit, installer)
    - WinNT et 2000 : lancer ntptime --install pour le mettre en service
    - Win9X : faite un raccourci vers ntptime dans le menu démarrer.


    voili voilou.

    • [^] # Re: Introduction à NTP

      Posté par  (site web personnel, Mastodon) . Évalué à -5.

      Rah le malin, il poste une partie en news, puis le reste en commentaire pour avoir pleins de XP en plus. Malin malin ... Ca mérite -10 cette fourberie ! :)

      • [^] # Re: Introduction à NTP

        Posté par  . Évalué à 0.

        Bah... et inviter les gens à flamer quelqu'un, ce n'est pas fourbe ?

        Bref... Ca faisait un peu long pour une news...

      • [^] # XP et fourberies...

        Posté par  . Évalué à 0.

        Boah eh ! dis voir, t'avais pas remarqué que tout le monde faisait ça...
        Y'a de plus en plus de commentaires qui ressemblent fortement à des news (avec des URL et tout et tout)...

        Ah ben c'est qu'il faut les gagner ces XP ! :o)

      • [^] # Re: Introduction à NTP

        Posté par  . Évalué à 2.

        Arf... Je n'avais pas vu que c'etais Fabien...

        Bon en fait cette news est vraiment fourbe, mais pour une autre raison : Je l'ai postée pour montrer que je contribue encore à LinuxFR (alors que ca c'est beaucoup ralenti depuis mon changement de boulot), afin de ne pas paraitre trop boulet dans le mail que je vais envoyer dans quelques minutes pour me plaindre de l'abo à LMF qui n'est toujours pas actif. :D

      • [^] # Re: Introduction à NTP

        Posté par  . Évalué à -3.

        Erf, et la tu te prends un beau -3 :)

        Dis, c'est prévu pour quand la page XP-top50 ?

    • [^] # Re: Introduction à NTP

      Posté par  . Évalué à 9.

      Une petite remarque cependant:
      Le protocole NTP s'il fontionne effectivement bien avec un seul serveur de référence, est prévu pour en utiliser plutot 3.
      Pourquoi 3 ? Parce que avec 3 sources, le daemon NTP peut se rendre compte quand l'un d'eux dévie et ne plus en tenir compte. Ca parait anodin mais j'ai déjà vu des serveur ntp sur internet dévier jusqu'a 30 secondes d'écart ...
      Feter la nouvelle epoch 30' trop tard ce serai domage non ?

      Quand a l'usage de votre bande passante faite par ntp, ne vous en souciez pas. Ce protocole est vraiment bien étudié. Au lancement le daemon analyse la différence de vitesse entre l'horloge interne de votre serveur et les références, et il envoie des requetes assez fréquentes ... mais ensuite il fait des corrections par lui même et n'envoie des requetes que pour confirmer ses corrections. Si il voit qu'il ne s'est pas trompé, il diminue encore la fréquence des vérifications ... le trafic devient quasiement nul !![ Donc utilisable sur le cable meme avec la limite d'upload]

      • [^] # Re: Introduction à NTP

        Posté par  . Évalué à 3.

        Il y a un truc que je n'arrive vraiment pas à comprendre. Par quelle magie le client arrive à connaître l'heure exacte de la machine serveur alors qu'aucune des deux machines ne maitrise les délais de transfert inhérent au réseau ???
        Il y a du voudou dans ce protocole. ;)

        • [^] # Re: Introduction à NTP

          Posté par  . Évalué à 3.

          ce délai s'appelle l' OFFSET

          mais il est vrai que l'on n'est pas un milliardième de seconde de précision par le net... mais en a tu besoin ?

          Si oui, alors il éxiste des bornes de réception hertzienne du signal de l'horloge atomique de Francfort. C'est plus precis :)

          PS : "J'ai survecu au passage du billennium !"

          • [^] # Re: Introduction à NTP

            Posté par  . Évalué à 3.

            J'ai cherché un peu. C'est pas l'heure exacte en fait. C'est une banale approximation. Je suis complètement décu. Le vaudou n'existe pas.
            Il est vain d'essayer d'atteindre le Billénnium dans la Tribune. Les photons nous mentent. Les Hertz trichent. Les atomes se moquent de nous. Je vais aller me coucher. ;o)

    • [^] # Re: Introduction à NTP

      Posté par  . Évalué à 2.

      Pour ouinouin, y'a aussi http://sourceforge.net/projects/nettime(...) que je trouve très bien. On peut aussi l'utiliser comme serveur NTP, càd comme relais entre un serveur primaire et ton poste.

      Une petite question : j'ai installé ntpd sur un de mes serveurs, mais ntpdate n'arrive pas à se synchroniser dessus. Je suis obligé d'utiliser nettime entre les deux : ntpd se synchro sur un primaire, nettime sur ntpd et ntpdate sur nettime.

    • [^] # Re: Introduction à NTP

      Posté par  . Évalué à 2.

      Une alternative à NTP, qui est beaucoup plus légère : clockspeed ( http://cr.yp.to/clockspeed.html(...) ) .

      Installation :

      1) Compilez (editez conf-home, puis make setup check) .
      2) Lancez sntpclock <ip d'un serveur sntp> | clockadd => votre horloge est à l'heure.
      3) Lancez clockspeed &
      4) Ajoutez sntpclock <ip> > /usr/local/adjust

      Et votre horloge sera toujours à l'heure, meme déconnectée du réseau. clockspeed corrige la déviation de votre horloge.

      Attention à bien utiliser le temps atomique international et non le traditionnel et débile UTC. Pour les parisiens, ça revient à faire un ln -s /usr/share/zoninfo/right/Europe/Paris /etc/localtime sous Linux. Sous BSD, allez dans /usr/src/share/zoneinfo puis faites un make -DLEAPSECONDS install .

      Vala.

  • # -46386 timestamps roulaizent :o)

    Posté par  . Évalué à -2.

    Function stamp2time ($t, $mode) {
    global $LANG;
    $timestamp = mktime(substr($t,8,2),substr($t,10,2),substr($t,12,2),
    substr($t,4,2),substr($t,6,2),substr($t,0,4));
    + if (($d = $timestamp-1000000000)<=0) return $d;


    C'est rigolo mais ca risque de planter les wmco1nco1n dans la Tribune. =]

  • # Pour les feignasses...

    Posté par  . Évalué à 2.

    ou les fêtards qui ne seront pas encore rentrés de boîte de nuit, rien de tel qu'une ligne dans crontab :

    03 46 09 09 * sleep 38; post.sh Bonne epoch à tous. Que le cul vous pèle et qu\'il vous y pousse des chègues

    (C'est une expression bien de chez moi !)

    post.sh est disponible chez Marie Moustey, ou à l'adresse http://feloy.free.fr/post.sh(...)
    (Merci à gqueri pour ce script).

    • [^] # Re: Pour les feignasses...

      Posté par  . Évalué à 2.

      M'a trompé, c'est
      46 03 09 09 *

    • [^] # Re: Pour les feignasses...

      Posté par  . Évalué à 2.

      "at" aussi est pas mal pour ce genre de truc :
      [pastis:~] $ at 03:46 tomorrow
      warning: commands will be executed using /bin/sh
      at> post.sh nioc nioc
      at> ^D

    • [^] # Re: Pour les feignasses...

      Posté par  . Évalué à 6.

      arf, ces linuxiens, qui pondent de code qui ne marche QUE sur linux ...

      Voilà un truc qui marche :

      #!/bin/sh
      /usr/bin/nc linuxfr.org 80 << EOF
      POST http://linuxfr.org/board/add.php3(...) HTTP/1.0
      Host: linuxfr.org
      User-Agent: devil from `hostname` with `uname`-`uname -r`
      Referer: http://linuxfr.org/news/(...)
      Content-Type: application/x-www-form-urlencoded
      Content-Length: 29
      Connection: close

      message=your%20message%20here
      EOF

      • [^] # Re: Pour les feignasses...

        Posté par  . Évalué à 1.

        linuxien toi-même hé !!!
        tu connais beaucoup d'OS avec netcat installé dans /usr/bin ? :)
        mon script était écrit pour bash 2.04 qui gère les socket et il marche sous plein d'os

        a+, gael

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.