Journal Usenet binaires et rapidité des accès internet

Posté par (page perso) .
Tags : aucun
0
9
mar.
2008
Cher journal,

Tu auras noté que la fibre se propage chez de plus en plus d'internautes, comme par chez moi. Les débits sont de 100Mbits réels chez Orange par exemple (encore que ça dépend pas mal des serveurs en face), néanmoins sur usenet binaires mon core 2 duo a du mal à dépasser 50mbits, et en bouffant beaucoup de cpu (je télécharge mes ISO Debian sur usenet, et j'y fais mes backups chiffrés).

Serait-il temps de passer à autre chose que yEnc ou UUencode ? Des gens sont-ils intéressés par le sujet ?
  • # ou sinon ...

    Posté par (page perso) . Évalué à 4.

    Passer au FTP ?
  • # Backup sur Usenet ?

    Posté par (page perso) . Évalué à 10.

    et j'y fais mes backups chiffrés

    Je pige pas trop, Usenet c'est pas vraiment prévu pour, tu peux expliquer ?
    • [^] # Re: Backup sur Usenet ?

      Posté par (page perso) . Évalué à 10.

      Bah si, les alt.binaries.erotica.* sont un bon endroit pour sauvegarder son pr0n.

      On peut être sûr que quelques temps plus tard quelqu'un repostera ce qu'on aura backupé :)

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

  • # trop gros

    Posté par (page perso) . Évalué à 5.

    Apparemment Fabien, le sujet ne passionne pas ici bas :)

    Y'a besoin de quoi : un encodage sur 7 bits ? idéalement avec compression ?

    ou alors les news sont capable de transporter du 8 bits et c'est juste du ... de nouille de dinosaure que d'imposer yy ou uu ?

    sinon y'a beaucoup de trucs linux ou libres sur les news binaires ? ...
    • [^] # Re: trop gros

      Posté par (page perso) . Évalué à 0.

      Le problème c'est surtout que ceux qui envoient des trucs utilisent des bouses, et qu'on sera obligé de s'y coller. Peut-être que tenter de faire en sorte que ydecoder aille plus vite serait une solution.
  • # Il y a un truc pas mal qui s'appelle...

    Posté par (page perso) . Évalué à 7.

    ... P2P.
    Et ça marche pas mal.
    Parait même qu'il y a plus de monde qui l'utilisent, et qu'ils en sont très content.
    Y compris pour les ISO de Debian.
    C'est en 8 bits/octet à envoyer, et pas de perte de place dues à tes headers mails qui n'ont rien à faire ici.

    Quand je télécharge à partir d'un bon tracker, ca blinde même les 100 Mbps du serveur que j'utilise pour tester (moins de 10 minutes pour télécharger un ISO de DVD, et après je prend du temps, beaucoup de temps pour le rapatrier chez moi :) )
  • # Slim Fast !

    Posté par . Évalué à 1.

    Tester Fast TCP ?

    Note: http://netlab.caltech.edu/FAST/
  • # des isos debian...et la marmotte ?

    Posté par . Évalué à 2.

    quelque chose me tirelalupine
    chez orange les binaires sont bloqués, donc pour dl sur les binaries groups, il faut un payer un acces sur un serveur de news externe, non ?
    payer 15 euros par mois pour ne télécharger que des isos debian, serait-ce en 2 minutes, je trouve ca un peu hardcore.
    Ou alors c'est pour le pr0n...

    Blague à part, pour avoir eu le même problème et l'avoir résolu, l'idée c'est que c'est jamais le CPU qui limite, mais les accès disque. La solution, cacher en RAMDISK, et même unrarer en ramdisk si possible.
    A titre d'information, on multiplie par 5 ou 6 les performances sous linux par rapport aux outils windows qui téléchargent comme des cons, un thread par post, alors que sous linux nzbget ou klibido prennent 20 threads par post.

    En gros, je sais pas si je suis clair, mais la solution, c'est linux+ramdisk.

    Mes 2 cents
  • # uuencode roulaise

    Posté par . Évalué à 1.

    J'imagine difficile de trouver un algo pour coder du binaire en imprimable qui puisse être codé de manière plus efficace qu'uuencode, tellement uuencode est simple, comme tous les algos conçus à l'époque où la puissance machine était rare.

    Bon, après, c'est vrai, ça bouffe de la place.

Suivre le flux des commentaires

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