Package: emacs-snapshot Version: 1:20060908-1 Severity: normal Hi,
I like much org-mode. For the file attached, emacs uses almost 100% the CPU, without reason. It is 100% reproducible. $ emacs -q td M-x org-mode [emacs shows only the headings (about 10 headings)] [top prints: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3612 dedu 25 0 20148 12m 5340 R 90.5 2.5 0:11.94 emacs and this persists. ] If I remove the first heading (cwnd statique), the bug does not appear. If I remove all but the first heading, the bug does not appear either. Very strange... Friendly, Eugen Dedu -- Package-specific info: -- Emacs odds and ends: Loading 00debian-vars... Loading /etc/emacs/site-start.d/50a2ps.el (source)... Loading a2ps-print... Loading /etc/emacs/site-start.d/50css-mode.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50php-elisp.el (source)... Loading /etc/emacs/site-start.d/50pymacs.el (source)... Loading /etc/emacs/site-start.d/50python-mode.el (source)... Loading /etc/emacs/site-start.d/50sawfish.el (source)... Version is: GNU Emacs 22.0.50.1 (powerpc-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-09-09 on malo, modified by Debian System load-path: (/usr/share/emacs-snapshot/site-lisp/sawfish /usr/share/emacs-snapshot/site-lisp/python-mode /usr/share/emacs-snapshot/site-lisp/pymacs /usr/share/emacs-snapshot/site-lisp/pymacs-elisp /usr/share/emacs-snapshot/site-lisp/css-mode /usr/share/emacs/site-lisp/css-mode /usr/share/emacs-snapshot/site-lisp/a2ps /etc/emacs-snapshot /etc/emacs /usr/local/share/emacs/22.0.50/site-lisp /usr/local/share/emacs/site-lisp /usr/share/emacs/22.0.50/site-lisp /usr/share/emacs/22.0.50/site-lisp/a2ps /usr/share/emacs/22.0.50/site-lisp/css-mode /usr/share/emacs/22.0.50/site-lisp/php-elisp /usr/share/emacs/22.0.50/site-lisp/pymacs /usr/share/emacs/22.0.50/site-lisp/python-mode /usr/share/emacs/22.0.50/site-lisp/sawfish /usr/share/emacs/site-lisp /usr/share/emacs/22.0.50/leim /usr/share/emacs/22.0.50/lisp /usr/share/emacs/22.0.50/lisp/url /usr/share/emacs/22.0.50/lisp/textmodes /usr/share/emacs/22.0.50/lisp/progmodes /usr/share/emacs/22.0.50/lisp/play /usr/share/emacs/22.0.50/lisp/obsolete /usr/share/emacs/22.0.50/lisp/net /usr/share/emacs/22.0.50/lisp/mh-e /usr/share/emacs/22.0.50/lisp/mail /usr/share/emacs/22.0.50/lisp/language /usr/share/emacs/22.0.50/lisp/international /usr/share/emacs/22.0.50/lisp/gnus /usr/share/emacs/22.0.50/lisp/eshell /usr/share/emacs/22.0.50/lisp/erc /usr/share/emacs/22.0.50/lisp/emulation /usr/share/emacs/22.0.50/lisp/emacs-lisp /usr/share/emacs/22.0.50/lisp/calendar /usr/share/emacs/22.0.50/lisp/calc) -- /usr/share/emacs-snapshot/: /usr/share/emacs-snapshot: total 0 drwxr-xr-x 8 root root 280 Sep 10 07:38 site-lisp /usr/share/emacs-snapshot/site-lisp: total 8 drwxr-xr-x 2 root root 104 Sep 10 07:38 a2ps drwxr-xr-x 2 root root 80 Sep 10 07:38 css-mode -rw-r--r-- 1 root root 3047 Sep 10 07:38 debian-startup.elc drwxr-xr-x 2 root root 80 Sep 10 07:38 php-elisp drwxr-xr-x 2 root root 80 Sep 10 07:38 pymacs drwxr-xr-x 2 root root 144 Sep 10 07:38 python-mode drwxr-xr-x 2 root root 80 Sep 10 07:38 sawfish -rw-r--r-- 1 root root 106 Sep 8 21:35 subdirs.el /usr/share/emacs-snapshot/site-lisp/a2ps: total 12 -rw-r--r-- 1 root root 1949 Sep 10 07:38 a2ps-print.elc -rw-r--r-- 1 root root 5056 Sep 10 07:38 a2ps.elc /usr/share/emacs-snapshot/site-lisp/css-mode: total 16 -rw-r--r-- 1 root root 15293 Sep 10 07:38 css-mode.elc /usr/share/emacs-snapshot/site-lisp/php-elisp: total 16 -rw-r--r-- 1 root root 14019 Sep 10 07:38 php-mode.elc /usr/share/emacs-snapshot/site-lisp/pymacs: total 16 -rw-r--r-- 1 root root 15868 Sep 10 07:38 pymacs.elc /usr/share/emacs-snapshot/site-lisp/python-mode: total 144 -rw-r--r-- 1 root root 27232 Sep 10 07:38 doctest-mode.elc -rw-r--r-- 1 root root 1297 Sep 10 07:38 pycomplete.elc -rw-r--r-- 1 root root 114327 Sep 10 07:38 python-mode.elc /usr/share/emacs-snapshot/site-lisp/sawfish: total 36 -rw-r--r-- 1 root root 34502 Sep 10 07:38 sawfish.elc -- /usr/share/emacs/site-lisp/: /usr/share/emacs/site-lisp: total 100 drwxr-xr-x 2 root root 104 Mar 9 2006 a2ps drwxr-xr-x 2 root root 80 Dec 5 2004 css-mode -rw-r--r-- 1 root root 6159 Jan 6 2006 debian-startup.el drwxr-xr-x 2 root root 144 Aug 9 00:14 dictionaries-common -rw-r--r-- 1 root root 93020 Mar 12 2006 gnugo.el drwxr-xr-x 2 root root 80 Jul 13 2004 php-elisp drwxr-xr-x 2 root root 80 Jun 26 21:54 pymacs drwxr-xr-x 2 root root 48 Jun 26 21:54 pymacs-elisp drwxr-xr-x 2 root root 144 Aug 10 09:27 python-mode drwxr-xr-x 2 root root 80 Aug 5 01:12 sawfish /usr/share/emacs/site-lisp/a2ps: total 16 -rw-r--r-- 1 root root 3937 Feb 26 2006 a2ps-print.el -rw-r--r-- 1 root root 11164 Feb 26 2006 a2ps.el /usr/share/emacs/site-lisp/css-mode: total 16 -rw-r--r-- 1 root root 15590 Nov 23 2004 css-mode.el /usr/share/emacs/site-lisp/dictionaries-common: total 264 -rw-r--r-- 1 root root 15335 Jul 27 22:28 debian-ispell.el -rw-r--r-- 1 root root 99620 Jul 27 22:28 flyspell.el -rw-r--r-- 1 root root 150585 Jul 27 22:28 ispell.el /usr/share/emacs/site-lisp/php-elisp: total 40 -rw-r--r-- 1 root root 38604 Apr 27 2004 php-mode.el /usr/share/emacs/site-lisp/pymacs: total 28 -rw-r--r-- 1 root root 26374 Jun 30 2003 pymacs.el /usr/share/emacs/site-lisp/pymacs-elisp: total 0 /usr/share/emacs/site-lisp/python-mode: total 188 -rw-r--r-- 1 root root 34929 Dec 2 2005 doctest-mode.el -rw-r--r-- 1 root root 975 Dec 2 2005 pycomplete.el -rw-r--r-- 1 root root 147506 Aug 2 09:54 python-mode.el /usr/share/emacs/site-lisp/sawfish: total 40 -rw-r--r-- 1 root root 40633 Jul 22 18:23 sawfish.el -- /var/lib/emacs-snapshot/: /var/lib/emacs-snapshot: total 0 drwxr-xr-x 2 root root 80 Sep 10 07:38 installed-subflavors /var/lib/emacs-snapshot/installed-subflavors: total 0 -rw-r--r-- 1 root root 0 Sep 10 07:38 emacs-snapshot-x -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages emacs-snapshot depends on: ii emacs-snapshot-bin-common 1:20060908-1 The GNU Emacs editor's shared, arc ii libasound2 1.0.12-1 ALSA library ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libncurses5 5.5-3 Shared libraries for terminal hand ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libsm6 1:1.0.1-2 X11 Session Management library ii libtiff4 3.8.2-6 Tag Image File Format (TIFF) libra ii libungif4g 4.1.4-3 shared library for GIF images (run ii libx11-6 2:1.0.0-8 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii xaw3dg 1.5+E-14 Xaw3d widget set ii zlib1g 1:1.2.3-13 compression library - runtime emacs-snapshot recommends no packages. Versions of packages emacs-snapshot-common depends on: ii dpkg 1.13.21 package maintenance system for Deb ii emacsen-common 1.4.17 Common facilities for all emacsen Versions of packages emacs-snapshot-bin-common depends on: ii emacs-snapshot-common 1:20060908-1 The GNU Emacs editor's common infr ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii liblockfile1 1.06.1 NFS-safe locking library, includes Versions of packages emacs-snapshot-el depends on: ii emacs-snapshot-common 1:20060908-1 The GNU Emacs editor's common infr Versions of packages emacsen-common depends on: ii bsdmainutils 6.1.4 collection of more utilities from Versions of packages emacs-snapshot is related to: ii dictionaries-common 0.70.2 Common utilities for spelling dict -- no debconf information
* cwnd statique (après définitions et avant Tahoe) a. Faites le diagramme de transfert avec les caractéristiques : cwnd = 3 Un fichier de 15 ko à envoyer 1 ko par paquet Paquets perdus : 5 et 8 RTT = 1 sec. RTO = 2 sec. Buffer de réception illimité Sans initiation et fin de connexion Sans accusés retardés b. Utilisez des accusés retardés, 500 ms, en supposant qu'il n'y a aucun paquet perdu. * Évolution de la cwnd en Tahoe, sans pertes Faire le diagramme des paquets d'1 ko transmis par un flux TCP (en considérant que sa fenêtre d'émission est toujours remplie) pendant 1 seconde sur un lien à débit illimité et à latence 10 ms pour (le diagramme contient : temps, cwnd, ssthresh, nb paquets envoyés, nb total de paquets reçus) : a. Sans perte de paquet, ssthresh initial très grand. Quel est le RTT ? b. Sans perte de paquet, ssthresh initial = 64 ko. * Comparaison envoi un gros fichier vs plusieurs petits fichiers Supposons un répertoire de 100 fichiers de 10 ko chacun, fichiers que vous devez envoyer par le réseau. Vous pouvez les transférer de deux manières : envoyer chacun des fichiers ou bien les tar-er et envoyer le gros fichier tar. Si le ssthresh initial est très grand, le lien est à 1 Gb/s et le délai de 10 ms et la taille de paquet est de 1 ko, quel est le temps pris par chacune des deux méthodes ? Est-ce que la comparaison dépend de la bande passante du lien ? 488 paq/RTT => 488 ko/RTT * Perte de paquets (??? espacés d'1ms = ?, quelle version de TCP ?, quel est le but de l'exo ?) À un certain moment t0 d'un transfert, 10 paquets (espacés d'1 ms) sont envoyés par l'émetteur (cwnd=10, ssthresh=50). Le RTT est de 30 ms. Faites un tableau avec l'évolution de la transmission jusqu'à la récupération de la perte au cas où : a. Le paquet perdu est le 8ème. b. Le paquet perdu est le 3ème. * Diverses questions sur cwnd Tahoe (d'Oumaya Baala), pas clair (à quoi sert 2ko ? transm entière = ok ou pas ?) Dans une session TCP MSS = 2 ko. Initialement la fenêtre de congestion est de 1 MSS et le seuil de 32 MSS. Les prochaines transmissions entières d'une fenêtre sont bien acquittées, sauf la 4ème. a. Quel sera alors le seuil ? b. Au bout de combien de transmissions entières un temporisateur doit expirer pour que le seuil double de taille ? * Influence de la fenêtre de réception sur le débit Quelles sont les deux fenêtres qui limitent le débit d'une connexion ? Supposons 10 liens entre A et B, chacun avec 10 ms délai et 100 Mb/s. Quel est le débit max atteint (sachant que la fenêtre de réception en TCP classique est limitée à 64 ko (16 bits dans l'en-tête)) ? * Envoi Reno avec erreurs de transmission Initiation et fermeture de la connexion font 1 sec. Le RTT est de 200 ms. et le RTO est de 400 ms. Les paquets 30 et 90 (les numéros commencent à 1) sont perdus par le réseau. La taille du fichier à transmettre est 100 ko. Le MSS est de 1 ko. Le ssthresh initial est très grand. Combien de temps prend le transfert ? * Transmission Web, modes persistant et non persistant (d'Oumaya Baala) La machine A exécute un serveur web à laquelle se connecte un client web de la machine B. La taille maximale d'un segment (MSS) lors d'une connexion TCP entre A et B est de 512 octets. Ouvrir et fermer une connexion TCP met 2 secondes. Quand A envoie une séquence de segments, elle reçoit l'acquittement de B une seconde après l'émission complète. Le réseau reliant A et B fonctionne à 8kbits/sec et n'est jamais congestionné. B demande à A quatre documents : une page web et trois images de 2ko chacune. On ignore les en-têtes HTTP et TCP, donc on suppose que chaque document peut être envoyé dans quatre segments exactement. En ignorant les messages HTTP de B vers A, calculez le temps total de transmission pour : a. Le mode persistant (les quatre documents sont transmis dans la même session TCP). b. Le mode non-persistant (les quatre documents sont transmis chacun dans une session TCP à part). c. Faites une comparaison entre les 2 modes dpdv : - utilisateur - tout le monde * Transmission d'un flux sur un lien (pas intéressant, à effacer ?) Faire le diagramme des paquets d'1 ko transmis par un flux pendant 5 secondes sur un lien à bande passante illimité (ou 10 Mb/s ?) et latence de 10 ms : a. Le flux est UDP CBR, 1 paquet / 1 ms. b. Le flux est UDP CBR et le lien a un taux d'erreur de 2 % (tous les 50 paquets le dernier paquet est perdu). c. Le flux est TCP (ssthresh très grand). Également, à quel débit arrive le flux à la fin de la 1ère seconde ? d. Le flux est TCP (ssthresh très grand) et le lien a un taux d'erreur de 0.1 % (on utilise la moyenne pour le moment des pertes). e. On suppose que le flux est UDP et TCP en meme temps TCP, puis 1 sec plus tard UDP commence * Transmission d'un flux TCP sur deux liens (difficile, à effacer ?) A-R 100 Mb/s, R-B 10 Mb/s, latences de 10 ms R a une file d'attente de 100 paquets (paquets + accusés !) Le traitement d'un paquet prend 0.1 ms à R. Un flux TCP avec des données illimitées à envoyer. Les paquets sont d'1 ko. Faire le diagramme des paquets échangés * Concurrence de flux TCP/UDP sur un lien Faire la courbe approximative (intuitive) avec la concurrence de flux pour (même RTT) : - 1 tcp - 2 tcp, démarrés à des moments différents - 1 udp cbr - 2 udp cbr, démarrés à des moments différents - 2 tcp, ensuite 1 udp cbr * Transmission d'un flux TCP sur deux liens (je ne l'ai pas très bien compris, à voir...) Supposez qu'entre A et B il y ait un routeur R. La largeur de bande entre A et R est infinie, mais la ligne R-B introduit un délai de 1 paquet par seconde (2 paquets prennent deux secondes). Les acquittements de B à R sont envoyés instantanément. A envoie des données à B avec une connexion TCP, en utilisant le démarrage lent mais avec une fenêtre glissante arbitrairement grande. A chaque seconde, l'émetteur traite les acquittements s'il y en a et répond à chaque timetout. a. Faites l'hypothèse que le timeout est fixé à 2 secondes. Qu'est-ce qui est reçu et envoyé à T=0,1,2,3,4,5,6 secondes ? Est-ce que la ligne est vide à certains moments, à cause du timeout ? b. Qu'est-ce qui change si le timeout vaut 3 ? (Source : http://www.tcom.ch/HomePages/SRT/Exos%20t%E9l%E9informatique%206.pdf) * ??? - un probleme avec le calcul du rtt, du timeout dynamique (pourquoi doit-il etre dynamique), ... - un problème avec différence de débit entre deux TCP due à des RTT différents - à partir d'une capture d'ethereal, donner des informations... ------------- * Solutions ** Comparaison 40 fois plus rapide le dernier : 4 Mb/s, donc on n'atteint pas la bp, mais en général ça depend de la bp ** Oumaya 1 À la 1ère transmission la fenêtre fait 1MSS, à la 2ème 2MSS, ..., à la 4ème 8 MSS. Le temporisateur de cet envoi expire, la fenêtre de congestion courante est de 8 MSS, le nouveau seuil devient donc la moitié : 4MSS. Ensuite, pour que le seuil devienne 8MSS, le temporisateur doit expirer quand la fenêtre fait 16MSS. Pour atteindre le seuil de 4MSS il suffit de 3 transmissions. Ensuite pour atteindre 16 il suffit de 11 transmissions, donc 14 au total. ** Influence sur le débit Fenêtres : cwnd, rwnd, émission ** Reno t[RTT] | cwnd | nbpqenv | nopqenv | nopqrecus | phase | ssthresh 0 1 1 1 SS infini 0.5 1 1 2 2 2-3 1-3 2 4 4 4-7 1-7 3 8 8 8-15 1-15 4 16 16 16-31 1-29,31 5 30 28 32-59 1-29,31-59 6 44 1+14 30,60-73 fret+frec 15 1-73 7 15 15 74-88 CA 1-88 8 16 12 89-100 1-89,91-100 9 16 1 90 fret+frec 8 1-100 10 FIN temps total = 1s + 10*200ms = 3 sec. Donner des explications pour t=6. (Erreur ?? : à t=6, en fret, on envoie 1 paquet à chaque paquet reçu => ce n'est pas 1+14, mais 1+28) ** Oumaya 2 (Web) Ici: ouverture et fermeture TCP mettent en tout 2 secondes. Chaque document (page web ou image) est de 2ko. - le mode persistant En tout 4*4 segments sont envoyés. Le temps total est de 2 sec (ouverture/fermeture TCP) + 8sec (4*2ko/débit) + 4 sec (attentes acquittements) = 14 secondes. - le mode non-persistant Les fenêtres envoyées sont de 2 puis de nouveau 2 segments. Le temps pour chaque transmission est : 2 sec + 2 sec (2ko/débit) + 1 sec (attentes acquittements) = 5 secondes. Au total donc 20 secondes. On voit que le mode persistant fait gagner du temps, car dans le cas échéant on est handicapé par le démarrage lent et par les ouvertures, fermetures de sessions TCP. - comparaison des deux modes a. si sur le lien congestionné nous sommes seuls, préférer persistant (Règle : plus il y a de flux, plus il y a de conflits, donc moins il y a de rendement.) b. si le lien congestionné est partagé, préférer persistant pour tout le monde, et non persistant pour moi (égoisme) c. s'il n'y a pas de congestion, cela dépend du nombre de connexions simultanées et du moment où elles sont faites...
