Re: apt-proxy/rsync/proxy
georges mariano [EMAIL PROTECTED] writes: intuition : quelle est la probabilité pour que, suite à une reconstruction d'une nouvelle version d'un paquet de 10Mo, les 9,5 premiers Mo ne soit pas modifiés d'un seul octet ?? Je peux me tromper, mais en gros, rsync coupe ton fichier en morceaux, et pour chaque morceau, il envoie de quoi retrouver le morceau en question dans le fichier cible : Le début du segment, et une clé, genre checksum ou md5. La cible regarde ce segment, et dit si elle l'a déjà. Si oui, il n'est pas nécessaire de l'envoyer. -- Matthieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Le jeudi 30 mai, à 14h52 georges mariano a ecrit : gulps ??? alors là je suis surpris, cela signifie que rsync travaille sur des morceaux de fichiers ?? (comment semble le confirmer Jacques ...) est-ce qu'il n'ouvrirais pas tout simplement les archives ? brave new world si un paquet est recompile pour changer un README ou une config par default alors on ouvre l'archive cote apt-proxy et cote serveur, on compare les date des contenus et on ne recupere que les changements, c le principe meme d'rsync il me semble. /brave new world mais quand on a une bonne connection est-ce qu'on ne pard pas en calcul le temps que l'on gagne en telechargement ? depuis que j'ai mis un apt-proxy ici (pour une asso au sein d'une fac) je n'ai pas vu de gain de temps mirobolants au telechargement de nouveaux paquets, mais il est difficille de faire des stats, la qualite de notre connection est trop aleatoire :/ ceci dit il est vrai que leur explications sont pour le moins peu claires: apt-proxy was written to use rsync to transfer files. For large Packages files this is more efficient because only the changed parts need to be transfered. However, compressed files(.gz or .deb) are generally not rsyncable, resulting in no speedup. In addition, the rsync protocol puts more load on the backend server than http. on a donc un transfert des parties changeante des paquets uniquement, mais ce n'est pas possible avec des .gz ou .deb! j'avoue m'y perdre un peu :o) -- aurelien -- All programmers are playwrights and all computers are lousy actors. pgpoKDvDF0RYO.pgp Description: PGP signature
Re: apt-proxy/rsync/proxy
jeudi 30 mai 2002, 14:52:29, georges a écrit : tous les paquets, mais j'ai déja vu des paquet de plusieurs Mo chargés en une dizaine de secondes, toujours en 56k). gulps ??? alors là je suis surpris, cela signifie que rsync travaille sur des morceaux de fichiers ?? (comment semble le confirmer Jacques ...) Et je confirme rsync travaille sur du delta de fichier. intuition : quelle est la probabilité pour que, suite à une reconstruction d'une nouvelle version d'un paquet de 10Mo, les 9,5 premiers Mo ne soit pas modifiés d'un seul octet ?? le pb n'est pas là, mais plutôt quel est la probabilité pour que sur ton paquet de 10Mo, découpé en petit bout, la majorité des bouts soit identiques pour plus d'info sur l'algo de rsync : http://rsync.samba.org/tech_report/node2.html a+ Tom -- Thomas Clavier http://www.tcweb.dyndns.org . _/_/_/_/_/ _/_/ Centre d'expertise RGO. _/ _/ DATACEP Nord ._/ _/ +33 3 28 52 53 02 - +33 6 09 25 59 67 . _/ _/_/
Re: apt-proxy/rsync/proxy
On Thu, 30 May 2002 15:26:33 +0200 Thomas Clavier [EMAIL PROTECTED] wrote: le pb n'est pas là, mais plutôt quel est la probabilité pour que sur ton paquet de 10Mo, découpé en petit bout, la majorité des bouts soit identiques c'est une autre formulation de ce que je voulais dire ... ;-) mais le problème, c'est que cette probabilité me semblant relativement faible (vu la complexité/richesse de ce qu'il y a dans un .deb), il faut encore y ajouter le coût/temps des calculs pour les sommes (en général pour pas grand chose _dans le cas qui nous occupe_) pas étonnant qu'il n'y ai probablement pas eu de conclusion définitve à ce sujet sur debian-devel ;-) pour plus d'info sur l'algo de rsync : http://rsync.samba.org/tech_report/node2.html A+ -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
On Thu, May 30, 2002 at 02:56:00PM +0100, aurelien naldi wrote: est-ce qu'il n'ouvrirais pas tout simplement les archives ? brave new world si un paquet est recompile pour changer un README ou une config par default alors on ouvre l'archive cote apt-proxy et cote serveur, on compare les date des contenus et on ne recupere que les changements, c le principe meme d'rsync il me semble. /brave new world Non, il ne fait ça que sur le fichier complet, coupé par bouts (arbitraires, donc). rsync ne sait pas ce qu'il transfère. mais quand on a une bonne connection est-ce qu'on ne pard pas en calcul le temps que l'on gagne en telechargement ? À moins que tu ne connectes un 386/20Mhz sur du gigaethernet, ça m'étonnerait :-) ceci dit il est vrai que leur explications sont pour le moins peu claires: apt-proxy was written to use rsync to transfer files. For large Packages files this is more efficient because only the changed parts need to be transfered. However, compressed files(.gz or .deb) are generally not rsyncable, resulting in no speedup. In addition, the rsync protocol puts more load on the backend server than http. on a donc un transfert des parties changeante des paquets uniquement, mais ce n'est pas possible avec des .gz ou .deb! j'avoue m'y perdre un peu :o) Il y a 2 choses fondamentales ici: - rsync marche sur un fichier, et l'algo ne dépend pas du contenu (ie on envoie un jpg de la même façon qu'un txt ou qu'un .tar.gz) - Quand on compresse un fichier, changer juste un tout petit bout change typiquement l'ensemble du fichier (pour résumer et simplifier: la compression se base sur le remplacement des octets courants par des chaines de bits plus courtes, et les octets peu courants sont remplacés par des chaines de bits plus longue. Si on compressait du texte en français, on coderait le 'e' sur 2 bits et le 'w' sur 15 bits, comme ça en moyenne tu gagnes. C'est la base de tous les compresseurs (pkzip, gzip, mpeg etc). Par conséquent, quand tu changes juste un octet dans le fichier, la plupart du temps la chaine de bit change de taille et TOUS les octets qui suivent changent, même si la chaine de bit restait la même. Une analogie serait un fichier d'image: j'ai une photo en jpeg, je change la couleur des yeux d'une personne (change quelques pixels), y'a toute les chances pour que le nouveau jpg soit complètement différent.) Si je me souviens bien du format .deb, il y a une partie configuration puis une partie compressée pour le binaire. Donc, si un seul des binaires change, il va falloir que rsync recupere toute la partie compressée, qui se trouve être la plus grosse. D'où, utiliser rsync pour ce genre de chose n'est sans doute pas le mieux (d'un point de vue de bande passante). /Y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re[2]: apt-proxy/rsync/proxy
jeudi 30 mai 2002, 15:42:54, georges a écrit : le pb n'est pas là, mais plutôt quel est la probabilité pour que sur ton paquet de 10Mo, découpé en petit bout, la majorité des bouts soit identiques c'est une autre formulation de ce que je voulais dire ... ;-) oui, avec en plus la possibilité d'intercaler de nouveaux morceaux plus ou moins grand entre les morceaux d'origines. Ce qui augmente grandement la probabilité :) mais le problème, c'est que cette probabilité me semblant relativement faible (vu la complexité/richesse de ce qu'il y a dans un .deb), il faut encore y ajouter le coût/temps des calculs pour les sommes (en général pour pas grand chose _dans le cas qui nous occupe_) En fait, ça dépend du .deb ... sur des doc ou tout paquet avec beaucoup d'ASCII, malgré la compression, si les changements sont mineurs, on retrouve une très grande partie des morceaux de l'ancien paquet dans le nouveau. Par contre, sur les petits paquets compilé puis compressé la probabilité est faible pour plus d'info sur l'algo de rsync : http://rsync.samba.org/tech_report/node2.html Quand au temps de calcul, l'algo ne me semble pas si gourmand en temps proc. A+ tom -- Thomas Clavier http://www.tcweb.dyndns.org . _/_/_/_/_/ _/_/ Centre d'expertise RGO. _/ _/ DATACEP Nord ._/ _/ +33 3 28 52 53 02 - +33 6 09 25 59 67 . _/ _/_/
Re: apt-proxy/rsync/proxy
Le Jeudi 30 Mai 2002 14:52, georges mariano a écrit : si je fais un apt-get update ici, le plus gros Packages.gz fait : 70ko donc avec un 4Ko/s (modem), il me faudrait env. 20s, x3 (main/contrib/non-free)... Bref, on en reste de l'ordre de la minute (mettons deux) Je parlais d'un apt-get update du Packages.gz de la sid ou de la woody, qui eux font plus de 1,6 Mo ! tous les paquets, mais j'ai déja vu des paquet de plusieurs Mo chargés en une dizaine de secondes, toujours en 56k). gulps ??? alors là je suis surpris, cela signifie que rsync travaille sur des morceaux de fichiers ?? (comment semble le confirmer Jacques ...) Oui, l'algorithme de rsync découpe le fichier en morceaux, et envoie le md5sum de chaque morceau au serveur, qui renvoie ce qui a changé (en gros). Le problème, c'est que l'algo de rsync est breveté :-( Enfin en pratique, ça ne marche pas sur tous les paquets, mais comme je l'ai dit, j'ai vu des cas où c'était vraiment plus rapide. Mais au pire on perd quasiment rien (quelques md5sums envoyés au serveur). En tout cas pour le Packages.gz, il n'y a pas photo. A+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
georges mariano a écrit, jeudi 30 mai 2002, à 14:52 : [...] Aurelien Jarno [EMAIL PROTECTED] wrote: La plus value, c'est que apt-proxy utilise rsync. C'est très pratique pour le Packages.gz, un apt-get update me prend moi d'une minute avec un modem 56k. si je fais un apt-get update ici, le plus gros Packages.gz fait : 70ko donc avec un 4Ko/s (modem), il me faudrait env. 20s, x3 (main/contrib/non-free)... Bref, on en reste de l'ordre de la minute (mettons deux) ...même moins, souvent seuls les Packages.gz de proposed-updates sont téléchargés. (il me semble que ça ne marche pas pour le ftp) tous les paquets, mais j'ai déja vu des paquet de plusieurs Mo chargés en une dizaine de secondes, toujours en 56k). gulps ??? alors là je suis surpris, cela signifie que rsync travaille sur des morceaux de fichiers ?? (comment semble le confirmer Jacques ...) oui, man rsync ;) et http://rsync.samba.org/rsync/tech_report/ pour les détails (que je n'ai pas lus). [de mémoire, les discussions sur -devel tournaient un peu en rond parce que personne n'avait de données suffisantes pour démontrer le gain effectif... (au moment où j'ai arrété de suivre) Il y a plus d'un an, quelqu'un avait expliqué sur cette liste qu'il mettait à jour des images iso du serveur hongrois par cette méthode, avec un gain de temps impressionnant (un facteur 4, je crois). intuition : quelle est la probabilité pour que, suite à une reconstruction d'une nouvelle version d'un paquet de 10Mo, les 9,5 premiers Mo ne soit pas modifiés d'un seul octet ?? ...assez forte si tu tares les fichiers dans l'ordre chronologique :) Le hic est que le *nom* du fichier a changé... où alors, y'a un truc que j'ai pas saisi ?? Rsync doit pouvoir reprendre le fil après quelques blocs modifiés, un peu comme diff. Dans une image iso, les fichiers sont compressés un à un, donc il doit y avoir des tas de blocs inchangés. On doit pouvoir faire un essai en réseau local avec les CD1.iso 2.2r5 et 2.2r6 de la patate pour en avoir le coeur net... m*, j'ai effacé les vieux. Donc en fait, apt-proxy est pratique que l'on ai une ou plusieurs machines, avec une connexion internet lente et/ou que l'on paye à la durée/quantité de donnée transférées. Toujours pas franchement convaincu (perso, je préfère me consacrer à wwwoffle par exemple, un _vrai_ proxy **bien documenté**, je limite les debianeries au strict minimum) Oui, wwwoffle est très bien. -- Jacques L'helgoualc'h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
On Thu, 30 May 2002 16:35:42 +0200 Aurelien Jarno [EMAIL PROTECTED] wrote: Je parlais d'un apt-get update du Packages.gz de la sid ou de la woody, qui eux font plus de 1,6 Mo ! argghh, autant pour moi, mais c'est quoi sid et woody ?? :))) je l'ai dit, j'ai vu des cas où c'était vraiment plus rapide. ce qui m'intéresse moi c'est le cas général, le plus probable, et il me semble quand même qu'on télécharge plus souvent du .deb que du Packages.gz (encore une fois je me place dans un contexte d'utilisation normale où on upgrade pas tout en permanence pour le plaisir ...) au pire on perd quasiment rien (quelques md5sums envoyés au serveur). En tout cas pour le Packages.gz, il n'y a pas photo. admettons. -- mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 INRETS, 20 rue Élisée Reclus fax: (33) 03 20 43 83 59 BP 317 -- 59666 Villeneuve d'Ascq http://www3.inrets.fr/estas/mariano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Yves Rutschle [EMAIL PROTECTED] writes: C'est la base de tous les compresseurs (pkzip, gzip, mpeg etc). Pour mpeg, c'est un peu différent. C'est un algorithme avec perde de qualité, qui est surtout basé sur des transformations analytiques (transformées de fourrier cie) que sur la répétition. j'ai une photo en jpeg, je change la couleur des yeux d'une personne (change quelques pixels), y'a toute les chances pour que le nouveau jpg soit complètement différent.) Pas tout à fait vrai non plus : le jpeg commence par découper l'image en carrés de 8 par 8 (ça se voit d'ailleurs quand on zoome), et les carrés sont compressés individuellement, donc, il y a au contraire de fortes chances pour que ton image change peu. A part ces détails (sur lesquels je me trompes sans doute aussi un peu), c'est ça, oui. -- Matthieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Jacques L'helgoualc'h a écrit, jeudi 30 mai 2002, à 16:49 : [...] http://rsync.samba.org/rsync/tech_report/ Désolé (la faute à wwwoffle :), l'url a changé : http://rsync.samba.org/tech_report/ -- Jacques L'helgoualc'h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
On Thu, May 30, 2002 at 06:05:45PM +0200, Matthieu Moy wrote: Yves Rutschle [EMAIL PROTECTED] writes: C'est la base de tous les compresseurs (pkzip, gzip, mpeg etc). Pour mpeg, c'est un peu différent. C'est un algorithme avec perde de qualité, qui est surtout basé sur des transformations analytiques (transformées de fourrier cie) que sur la répétition. j'ai une photo en jpeg, je change la couleur des yeux d'une personne (change quelques pixels), y'a toute les chances pour que le nouveau jpg soit complètement différent.) Pas tout à fait vrai non plus : le jpeg commence par découper l'image en carrés de 8 par 8 (ça se voit d'ailleurs quand on zoome), et les carrés sont compressés individuellement, donc, il y a au contraire de fortes chances pour que ton image change peu. Mpeg et Jpeg marchent de la même façon au niveau de l'image: couper en macro-blocks (8x8 pixels), faire une transformée en cosinus bi-dimentionelle (DCT: Discrete Cosine Transform), prendre les bits des fréquences basses (donc on perd les fréquences hautes: c'est pour ça que Jpeg donne des résultats horribles pour les dessins). De là, Mpeg cherche les macro-blocks dans l'image précédente (et suivante, si on est en Mpeg4 et le bon profil) pour voir si il peut les retrouver au même endroit ou dans les environ, c'est l'estimation de mouvement. (Pour info, Mpeg2, H261 et H263 sont tous basés sur le même principe.) Enfin, Mpeg et Jpeg passent tout ça dans un VLE (Variable Length Encoder) qui est un codage de Huffman avec une table fixe, donc finalement exactement ce que je disais, mais en retirant 2 paragraphes, parce que sinon c'était hors sujet. C'est toujours Hors Sujet, d'ailleurs :-) Donc: si je change des yeux, il y a de bonnes chances que la DCT donne un nombre de bits differents, donc décale l'ensemble du bitstream; ensuite, il y a aussi pas mal de chance que le VLE donne un résultat différent. Au final, ça revient au même: la plupart des compressions sont basées sur des flux de bits (bitstreams), pas sur des octets, donc dès qu'un morceau change de taille, tous les autres octets sont également affectés. Tiens, peut-être qu'une façon d'améliorer rsync serait précisément de considérer le fichier comme une suite de bits au lieu d'une suite d'octet. /Y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Le Jeudi 30 Mai 2002 17:58, georges mariano a écrit : On Thu, 30 May 2002 16:35:42 +0200 Aurelien Jarno [EMAIL PROTECTED] wrote: Je parlais d'un apt-get update du Packages.gz de la sid ou de la woody, qui eux font plus de 1,6 Mo ! argghh, autant pour moi, mais c'est quoi sid et woody ?? :))) Ben c'est les fichier Packages.gz des distributions Debian Woody et Debian Sid qu'on peut trouver ici : ftp://ftp.debian.org/debian/dists/woody/main/binary-i386/Packages.gz et ftp://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.gz Aurelien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Le Jeudi 30 Mai 2002 16:49, Jacques L'helgoualc'h a écrit : georges mariano a écrit, jeudi 30 mai 2002, à 14:52 : intuition : quelle est la probabilité pour que, suite à une reconstruction d'une nouvelle version d'un paquet de 10Mo, les 9,5 premiers Mo ne soit pas modifiés d'un seul octet ?? ...assez forte si tu tares les fichiers dans l'ordre chronologique :) Le hic est que le *nom* du fichier a changé... Sauf que apt-proxy, lors du téléchargement d'une nouvelle version, fait une copie de l'ancienne version et donne à cette copie le nom de la nouvelle version, qu'il n'a pas encore chargée. Le rsync est fait sur ce fichier. Donc pas de problème de ce côté là... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy/rsync/proxy
Aurelien Jarno a écrit, jeudi 30 mai 2002, à 20:10 : Le Jeudi 30 Mai 2002 16:49, Jacques L'helgoualc'h a écrit : [...] Le hic est que le *nom* du fichier a changé... Sauf que apt-proxy, lors du téléchargement d'une nouvelle version, fait une copie de l'ancienne version et donne à cette copie le nom de la nouvelle version, qu'il n'a pas encore chargée. Le rsync est fait sur ce fichier. Donc pas de problème de ce côté là... Ah, bien, c'est mieux qu'un « bête » rsync, alors. -- Jacques L'helgoualc'h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
