Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Bonjour, On m'a demandé s'il y a un besoin d'avoir de nouveaux serveurs comme ceux récemment installés à Pau. Votre avis? Romain 2012/12/18 Pierre Béland infosbelas-...@yahoo.fr Voir .l'annonce du serveur de tuiles Pau sur talk. Pierre - Mail transféré - *De :* Richard Weait rich...@weait.com *À :* t...@openstreetmap.org t...@openstreetmap.org *Envoyé le :* Mardi 18 décembre 2012 13h14 *Objet :* Re: [OSM-talk] New OpenStreetMap tile server On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. ... to which I had intended to link. :-) http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Ca peut être utile, peut être pas pour le rendu OSM international qui a déjà plusieurs caches, mais pour offrir un cache de tuiles du rendu FR si celui vient à être utilisé par plus de monde et ne pas mettre tout les œufs dans le même panier. Le 21 mars 2013 10:01, Romain MEHUT romain.me...@gmail.com a écrit : Bonjour, On m'a demandé s'il y a un besoin d'avoir de nouveaux serveurs comme ceux récemment installés à Pau. Votre avis? Romain 2012/12/18 Pierre Béland infosbelas-...@yahoo.fr Voir .l'annonce du serveur de tuiles Pau sur talk. Pierre - Mail transféré - De : Richard Weait rich...@weait.com À : t...@openstreetmap.org t...@openstreetmap.org Envoyé le : Mardi 18 décembre 2012 13h14 Objet : Re: [OSM-talk] New OpenStreetMap tile server On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. ... to which I had intended to link. :-) http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Ok je fais suivre... Merci. Romain Le 21 mars 2013 10:33, Christian Quest cqu...@openstreetmap.fr a écrit : Ca peut être utile, peut être pas pour le rendu OSM international qui a déjà plusieurs caches, mais pour offrir un cache de tuiles du rendu FR si celui vient à être utilisé par plus de monde et ne pas mettre tout les œufs dans le même panier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
http://www.pcinpact.com/news/76247-demultiplication-mails-bug-gmail-identifie-correctif-arrive.htm? Le 20 décembre 2012 01:10, Philippe Verdy verd...@wanadoo.fr a écrit : Bogue de Gmail alors (dans son interface web). Je n'ai qu'une seule copie reçue et je n'ai certainement fait aucun copier-coller d'un mail à l'autre. Je ne sais pas pourquoi le 1er mail est parti plus tôt mais incomplet et réexpédié complet 20h plus tard. Le 20 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le jeudi 20 décembre 2012 à 00:43 +0100, Philippe Verdy a écrit : Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. T'es sûr ? C'est possible ? ya 3h tu nous disais tous le contraire.. je te cites : Je les ai lu au moment où je les ai reçus sans retard, et je sais même avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout de suite pratiquement à la seconde : je le sais lorsque je suis en discussion au téléphone et que j'envoie un mail à la même personne, le délai pour que la personne au bout du fil ait le mail n'excède pas quelques secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est pratiquement la seconde dans les deux sens, si on est tous les deux sur Gmail). Maintenant il est possible que tu ne reçoives pas les messages dans le même ordre et que des réponses des uns et des autres se croisent. Donc n'interprète pas un désordre apparent entre des messages des uns et des autres qui se succèdent en quelques minutes (selon la vitesse que met chaque FAI à livrer ses mails dans les boites aux lettres). Je t'épargnes les en-têtes de tes mails qui prouve qu'ils ont circulé en temps et en heure ! En tout cas tu nous fait bien rire, on a anticipé ta réponse ! [23:33] xx RedFox: ça serait un bug de la mailing list visant notre pauvre philippe que ça m'étonnerait pas [23:34] xx c'est toujours sur lui que ça tombe [23:34] RedFox arfff :D Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.166 ms 2.835 ms 2.808 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 72.387 ms 76.436 ms 76.420 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 76.396 ms 78.996 ms 80.110 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 85.690 ms 85.684 ms * 6 linx-gw1.ja.net (195.66.224.15) 97.748 ms 66.202 ms 54.794 ms 7 ae1.lond-sbr4.ja.net (146.97.35.181) 55.726 ms 57.377 ms 58.669 ms 8 ae12.read-sbr1.ja.net (146.97.33.141) 61.820 ms 63.552 ms 64.568 ms 9 be1.londic-rbr1.ja.net (146.97.35.150) 72.247 ms 72.251 ms 73.140 ms 10 imperial-college.ja.net (146.97.137.154) 74.123 ms 75.037 ms 75.920 ms 11 me-rach.net.ic.ac.uk (194.82.153.92) 77.125 ms 82.417 ms 82.379 ms -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 00:26 +0100, Christian Quest a écrit : Constat proche pour moi (aussi chez free), le ping est quasiment identique (dans les 40/45ms) et même nombre de hops. Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Le GeoDNS redirige les IP par pays entier. Il ne semble pas y avoir de subdivision. De plus pour fournir un cache de tuiles à la fondation OSM, il y a quelques conditions à réunir... https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Concernant les temps d'accès, c'est un problème connu. Il y a un GIX à Pau sur lequel Axione et RENATER échangeait du trafic. Mais cela posait un petit problème... lorsqu'une université francilienne souhaitait accéder à un client citéFibre (à paris donc), il faisait un aller-retour à Pau... Les joies du routage Internet ! De plus, le routage n'est pas qu'un problème technique, c'est aussi et surtout un problème financier. Les opérateurs de transit facture la bande passante dans des rapports pouvant aller de 1 à 20 ! Donc il revient facilement moins cher d'aller faire son peering sur un GROS GIX fédérateur, voire à l'étranger que sur un nœud local. Des discussions d'il y a quelques années faisant un état des lieux... http://lafibre.info/paubc/index.php/topic,1704.0.html Pour ceux qui l'ignore, Pau est la première ville^Wagglo de France a avoir déployé son propre réseau FTTH. Il dessert plusieurs dizaines de milliers d'habitants https://fr.wikipedia.org/wiki/Pau_Broadband_Country Aujourd'hui, le plus grand FAI a destination du grand public utilisant ce réseau est SFR. Il a été rejoint cette année par Orange http://www.larepubliquedespyrenees.fr/2012/04/19/fibre-optique-premieres-offres-d-orange-avant-noel,232898.php On peut donc espérer qu'avec 4 gros opérateurs nationaux (RENATER, Axione, SFR, Orange) ils voient un intérêt financier à peerer proprement en local... Christophe, ça serait possible de rajouter ce serveur dans le munin d'OSM-FR ? On a déjà notre propre munin http://tile.paulla.asso.fr/munin-osm/ La fondation OSM intégrera ce serveur dans son propre munin http://munin.openstreetmap.org en janvier. (Il faut qu'on lui ouvre des ports supplémentaires pour ce faire) Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Et j'en profite pour saluer l'outil mis à disposition par Paulla Le 19 décembre 2012 11:25, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Je m'auto répond : Je note à l'instant que les relations comprennent un noeud avec le rôle label, qui lui n'a pas de traduction. Je ne serais pas étonné qu'il soit à l'origine de ce souci, si la feuille de style lui donne la priorité pour le rendu ___ J'anticipe : don't feed the troll Le 19 décembre 2012 11:46, Ab_fab gamma@gmail.com a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Et j'en profite pour saluer l'outil mis à disposition par Paulla Le 19 décembre 2012 11:25, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja -- ab_fab http://wiki.openstreetmap.org/wiki/User:Ab_fab Il n'y a pas de pas perdus, Nadja ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. Et j'en profite pour saluer l'outil mis à disposition par Paulla Merci. Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 12:02 +0100, Christophe Merlet a écrit : Le mercredi 19 décembre 2012 à 11:46 +0100, Ab_fab a écrit : Je n'arrive pas à visualiser le résultat de mes ajouts du 27/11 (avec Nomino) de la balise name:fr pour les relations des provinces de Corée (niveau 4) http://www.openstreetmap.org/browse/changeset/14064905 http://tile.paulla.asso.fr/openlayers.html?zoom=7lat=36.02407lon=127.7179layers=B000FF même souci sur le toolserver http://toolserver.org/~osm/locale/fr.html?zoom=7lat=36.02407lon=127.7179layers=BT Une idée de ce qui peut clocher ? Je viens de regarder pour la relation Jeju http://www.openstreetmap.org/browse/relation/2398560 La traduction n'apparait pas sur la carte car cette relation utilise un noeud label qui lui n'est pas traduit http://www.openstreetmap.org/browse/node/1900155946 Or c'est ce label qui est affiché sur la carte... donc pas de traduction en français. J'imagine que c'est la même chose pour tes autres relations traduite avec Nomino. En fait j'ai un doute. Je viens de greper les sources d'osm2pgsql et des feuilles de styles mapnik, à la recherche du mot label et je n'ai rien trouvé oO Donc j'ignore a quel moment le label est pris en compte... Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Voila c'est annoncé pour le Québec sur talk-ca. Un gros merci au père Noël et à Christophe. Pierre De : Christophe Merlet red...@redfoxcenter.org À : talk-fr@openstreetmap.org Envoyé le : Mercredi 19 décembre 2012 5h25 Objet : Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server Le mercredi 19 décembre 2012 à 11:14 +0100, Pieren a écrit : 2012/12/19 Christophe Merlet red...@redfoxcenter.org: Merci et bravo pour l'effort. Mais il faut rappeler ici que ce cache n'est utile qu'à l'infrastructure globale d'OSM. Pour la France et les francophones en général, la seule solution restera de mettre en place notre propre server de tuiles avec rendu adapté (par exemple, utilisant de préférence les labels name:fr). Ca serait dommage qu'au final, on se repose uniquement sur l'infrastructure de wikipedia qui n'a pas les mêmes besoins de rendu que nous. (eux visent des cartes OSM internationalisées et exploitables pour leur encyclopédie alors que nous voulons un rendu utile aux contributeurs). Ce rendu de tuiles existe déjà... http://tile.paulla.asso.fr/openlayers.html Il vous suffit de piocher sur http://[abc].tile.paulla.asso.fr/osm-fr/ et est aussi dispo osm-br, osm-ca, osm-eu et osm-oc. Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
On mercredi 19 décembre 2012, Christian Quest wrote: Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Je ne suis pas membre et encore moins décideur du groupe technique, donc de l'utilisation que nous devrions faire des serveurs qui y sont, mais je recommande vivement de réfléchir avant de proposer notre candidature pour monter un serveur de cache chez free. Et j'aurais plus coeur à défendre la création d'un serveur de rendu autonome pour toutes les raisons que j'ai évoqué sur dev-fr. Ce à quoi, je n'ai pas qu'une grande gueule, c'est exactement ce que je prévois de faire (moins quelques variations) -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
C'est vrai que le problème de facturation concerne avant tout les applications très asymétriques en bande passante. Installer un cache Squid bien positionné dans la topologie du réseau est une solution pour réduire le déséquilibre des liens de peeering (sinon soit on paye le surplus, soit un se voit réduire drastiquement la bande passante). La Fondation Wikimedia ne diffuse pas que du contenu statique : les nombreuses pages de discussions et modifs de pages imposent que ce contenu change et n'entre plus dans les caches, même avec l'aide d'un CDN ou d'une série de serveur Squid managés par la fondation elle-même dans quelques GIX mondiaux stratégiques. Mais elle a aussi le même problème de charge sur ses moteurs de rendu MediaWiki : un cache ou un CDN ne peut pas tout résoudre, et il faut nécessairement monter aussi le nombre de serveurs de rendus et les mettre en réseau avec un système de distribution de la charge de travail (tout en veillant à ce que les serveurs de rendu puissent aussi disposer d'une bande passante suffisante et d'un bon temps de réponse pour rester synchronisés avec la base de données, la distribution de charge de travail sur la base de données elle-même étant un problème bien plus difficile (sauf si, comme actuellement, on accepte que les serveurs de rendus travaillent sur des réplications de la base avec un certain délai acceptable). Bref que l'on parle de la base de données OSM ou celle de Wikipédia, les difficultés pour monter en charge et garder la synchronisation acceptable en cas de distribution sont de même nature (la plus grosse difficulté est tout de même sur l'interface permettant de soumettre des modifications car on doit nécessairement s'appuyer sur une base maître chargée de lever les conflits et gérer le versionnement des contenus). Mais on n'est pas à la même échelle : le nombre de contributeurs actifs à Wikimédia est beaucoup plus élevé que ceux d'OSM, si on y inclut les pages de discussions, et surtout les envois massifs de photos vers Commons, qui sont eux aussi versionnés mais distribués par un système de répartition des répertoires, le goulot restant dans l'index général des fichiers et des catégories pour leur mise à jour). Heureusement les photos chargées sur Commons changent très peu, et pour ensuite les transférer vers les visiteurs les serveurs Squi ou les alliances avec les CDN ou FAI réduisent considérablement la bande passante de ces photos (mais très peu les pages de discussions et les données des profils d'utilisateurs qui nécessitent une modification des pages en cache pour y rajouter les données personnelles de profils, telles que les notifications en tête de page). Donc même pour les wikis de Wikimedia,les serveurs cache ou CDN ne sont pas suffisants pour la charge des pages HTML qui changent pour chaque visiteur et même à chaque rechargement d'une page par le même utilisateur. Le 19 décembre 2012 10:41, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 00:26 +0100, Christian Quest a écrit : Constat proche pour moi (aussi chez free), le ping est quasiment identique (dans les 40/45ms) et même nombre de hops. Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Le GeoDNS redirige les IP par pays entier. Il ne semble pas y avoir de subdivision. De plus pour fournir un cache de tuiles à la fondation OSM, il y a quelques conditions à réunir... https://wiki.openstreetmap.org/wiki/Servers/Tile_CDN Concernant les temps d'accès, c'est un problème connu. Il y a un GIX à Pau sur lequel Axione et RENATER échangeait du trafic. Mais cela posait un petit problème... lorsqu'une université francilienne souhaitait accéder à un client citéFibre (à paris donc), il faisait un aller-retour à Pau... Les joies du routage Internet ! De plus, le routage n'est pas qu'un problème technique, c'est aussi et surtout un problème financier. Les opérateurs de transit facture la bande passante dans des rapports pouvant aller de 1 à 20 ! Donc il revient facilement moins cher d'aller faire son peering sur un GROS GIX fédérateur, voire à l'étranger que sur un nœud local. Des discussions d'il y a quelques années faisant un état des lieux... http://lafibre.info/paubc/index.php/topic,1704.0.html Pour ceux qui l'ignore, Pau est la première ville^Wagglo de France a avoir déployé son propre réseau FTTH. Il dessert plusieurs dizaines de milliers d'habitants https://fr.wikipedia.org/wiki/Pau_Broadband_Country Aujourd'hui, le plus grand FAI a destination du grand public utilisant ce réseau est SFR. Il a été rejoint cette année par Orange http://www.larepubliquedespyrenees.fr/2012/04/19/fibre-optique-premieres-offres-d-orange-avant-noel,232898.php On peut donc espérer qu'avec 4 gros opérateurs nationaux (RENATER, Axione, SFR, Orange) ils voient un intérêt financier à
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Il semble que la cause de tout ça vienne de Mapnik et non de l'installation du proxy-cache Qquid : au lieu de mettre une réponse au client en attente sur sa session, il préfère retourner une version ancienne déjà calculée (mais avec une durée de péremption trop longue pour cette réponse qui ne devrait être qu'instantanée et pas recachable en aval) en attendant pour terminer la session plus tôt (et cela pose des problèmes de cohérence de cache, un problème qui existe depuis assez longtemps même avant l'entrée en scène des serveurs proxy Squid). Squid ne semble pas en cause (cela marche très bien par exemple avec Wikipédia qui parvient très bien à suivre les mises à jour), mais bien le frontend de Mapnik (autrement dit le serveur WMS qui lui pilote son travail à faire). L'avantage de répondre immédiatement au client est d'économiser des sessions en attente du côté du serveur (et donc éviter la non disponibilité de nouveaux ports TCP pour d'autres sessions HTTP s'il y a du monde), mais ici le problème est la non péremption immédiate (ou la péremption trop longue) des tuiles obsolètes qui sont en attente de recalcul. A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut un temps de réponse correct, étant donné que les FAI français ont tous leur routage au départ de Paris avec un peering efficace vers Londres et Amsterdam. Même chose pour les FAI espagnols ou italiens qui feront leur peering efficace vers Pau en passant par Paris ou Amsterdam d'abord. Le peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il n'a pas été tellement taillé pour un usage massif. La situation serait meilleure si la Fondation trouvait un partenariat avec des CDN mondiaux, comme Level3 qui a des serveurs proxy dans pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI français qui ont des peerings régionaux et qui y sont directement connectés sans faire transiter tout le trafic de leurs abonnés par Paris). Le 18 décembre 2012 23:53, Eric Marsden eric.mars...@free.fr a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mercredi 19 décembre 2012 à 20:02 +0100, Philippe Verdy a écrit : C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Le serveur de Pau fonctionne de la même manière que celui de Londres. Il n'y a aucune différence entre les deux. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Le serveur GeoDNS de Londres ne calcule pas les tuiles. Pas plus que celui de Pau. Donc encore une fois tu digresses. A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut un temps de réponse correct, C'est quoi un temps de réponse correct ? Le peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il n'a pas été tellement taillé pour un usage massif. ? oO La situation serait meilleure si la Fondation trouvait un partenariat avec des CDN mondiaux, comme Level3 qui a des serveurs proxy dans pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI français qui ont des peerings régionaux et qui y sont directement connectés sans faire transiter tout le trafic de leurs abonnés par Paris). Un de tes problèmes parmi tant d'autres, c'est que tu passe tellement de temps à rédiger tes pavés, que tu ne lis pas les autres mails ! Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Christophe Merlet a écrit à Philippe Un de tes problèmes parmi tant d'autres, c'est que tu passe tellement de temps à rédiger tes pavés, que tu ne lis pas les autres mails ! humour bref Christophe, c'est ce qui arrive quand le duo diabolique Sly et Philippe unit ses forces ! /bref humour :) Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 21:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mercredi 19 décembre 2012 à 20:02 +0100, Philippe Verdy a écrit : C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Le serveur de Pau fonctionne de la même manière que celui de Londres. Il n'y a aucune différence entre les deux. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Le serveur GeoDNS de Londres ne calcule pas les tuiles. Pas plus que celui de Pau. Donc encore une fois tu digresses. Où ai-je parlé d'un serveur GeoDNS ? On parlait du serveur Squid jusquà présent. TU digresses. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19/12/2012 21:17, Philippe Verdy a écrit : TU digresses. Et toi Philippe TU radotes : 2 mails à même pas 24h d'intervalle avec les 5 premiers pavés (pardon, paragraphes) identiques : http://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052507.html http://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052549.html À quoi ça rime ? S'il y a un intérêt dis-le, mais en moins de 20 mots. Chiche. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le 19 décembre 2012 09:48, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.166 ms 2.835 ms 2.808 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 72.387 ms 76.436 ms 76.420 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 76.396 ms 78.996 ms 80.110 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 85.690 ms 85.684 ms * 6 linx-gw1.ja.net (195.66.224.15) 97.748 ms 66.202 ms 54.794 ms 7 ae1.lond-sbr4.ja.net (146.97.35.181) 55.726 ms 57.377 ms 58.669 ms 8 ae12.read-sbr1.ja.net (146.97.33.141) 61.820 ms 63.552 ms 64.568 ms 9 be1.londic-rbr1.ja.net (146.97.35.150) 72.247 ms 72.251 ms 73.140 ms 10 imperial-college.ja.net (146.97.137.154) 74.123 ms 75.037 ms 75.920 ms 11 me-rach.net.ic.ac.uk (194.82.153.92) 77.125 ms 82.417 ms 82.379 ms Voilà, maintenant ça route bien vers Pau traceroute to b.tile.openstreetmap.org (193.55.222.229), 30 hops max, 60 byte packets 1 neufbox (192.168.1.1) 1.267 ms 1.398 ms 1.832 ms 2 * * * 3 153.226.70.86.rev.sfr.net (86.70.226.153) 46.273 ms 47.299 ms 49.233 ms 4 81.255.103.84.rev.sfr.net (84.103.255.81) 50.902 ms 52.396 ms 54.108 ms 5 146.133.64.86.rev.sfr.net (86.64.133.146) 56.113 ms 57.018 ms * 6 renater-ix1.sfinx.tm.fr (194.68.129.102) 67.690 ms 60.264 ms 63.042 ms 7 te0-3-1-0-lyon1-rtr-001.noc.renater.fr (193.51.189.126) 81.720 ms 66.789 ms 65.824 ms 8 te1-1-clermont-rtr-021.noc.renater.fr (193.51.189.170) 64.392 ms 63.986 ms 63.873 ms 9 te1-1-bordeaux-rtr-021.noc.renater.fr (193.51.189.165) 62.016 ms 61.153 ms 61.932 ms 10 po0-1-0-0-pau-rtr-011.noc.renater.fr (193.51.180.162) 65.149 ms 65.460 ms 65.965 ms 11 uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr (193.51.183.241) 63.892 ms 63.615 ms 65.481 ms -- Cyrille. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. Le 19 décembre 2012 22:39, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 19/12/2012 21:17, Philippe Verdy a écrit : TU digresses. Et toi Philippe TU radotes : 2 mails à même pas 24h d'intervalle avec les 5 premiers pavés (pardon, paragraphes) identiques : http://lists.openstreetmap.**org/pipermail/talk-fr/2012-** December/052507.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052507.html http://lists.openstreetmap.**org/pipermail/talk-fr/2012-** December/052549.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052549.html À quoi ça rime ? S'il y a un intérêt dis-le, mais en moins de 20 mots. Chiche. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le jeudi 20 décembre 2012 à 00:43 +0100, Philippe Verdy a écrit : Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. T'es sûr ? C'est possible ? ya 3h tu nous disais tous le contraire.. je te cites : Je les ai lu au moment où je les ai reçus sans retard, et je sais même avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout de suite pratiquement à la seconde : je le sais lorsque je suis en discussion au téléphone et que j'envoie un mail à la même personne, le délai pour que la personne au bout du fil ait le mail n'excède pas quelques secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est pratiquement la seconde dans les deux sens, si on est tous les deux sur Gmail). Maintenant il est possible que tu ne reçoives pas les messages dans le même ordre et que des réponses des uns et des autres se croisent. Donc n'interprète pas un désordre apparent entre des messages des uns et des autres qui se succèdent en quelques minutes (selon la vitesse que met chaque FAI à livrer ses mails dans les boites aux lettres). Je t'épargnes les en-têtes de tes mails qui prouve qu'ils ont circulé en temps et en heure ! En tout cas tu nous fait bien rire, on a anticipé ta réponse ! [23:33] xx RedFox: ça serait un bug de la mailing list visant notre pauvre philippe que ça m'étonnerait pas [23:34] xx c'est toujours sur lui que ça tombe [23:34] RedFox arfff :D Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
tracert b.tile.openstreetmap.org Détermination de l'itinéraire vers pau.tile.openstreetmap.org[193.55.222.229] avec un maximum de 30 sauts : 1 8 ms13 ms13 ms 10.33.128.1 212 ms13 ms21 ms ip-4.net-80-236-5.static.numericable.fr[80.236.5.4] 333 ms40 ms36 ms ip-190.net-80-236-0.static.numericable.fr[80.236.0.190] 434 ms30 ms31 ms ip-185.net-80-236-0.static.numericable.fr[80.236.0.185] 548 ms43 ms65 ms 172.19.130.14 652 ms45 ms51 ms renater.franceix.net [193.105.232.19] 768 ms62 ms63 ms te0-1-0-0-orleans-rtr-011.noc.renater.fr[193.51.189.146] 861 ms67 ms62 ms te0-2-0-0-poitiers-rtr-011.noc.renater.fr[193.51.189.158] 956 ms56 ms57 ms te1-3-bordeaux-rtr-021.noc.renater.fr[193.51.189.94] 1067 ms63 ms87 ms po0-1-0-0-pau-rtr-011.noc.renater.fr[193.51.180.162] 1166 ms66 ms63 ms uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr [193.51.183.241] 12 *** Délai d'attente de la demande dépassé. 1356 ms55 ms59 ms reserve1.paulla.asso.fr [193.55.222.229] Itinéraire déterminé. (Test effectué en WiFi N, au lieude l'Ethernet Gigabit que je pourrais tester aussi, mais cela rajoute moins de 2ms). Pour Numericable (fibre FTTB), ça part de Niort à Paris en 8-13 ms mais le plus gros du temps est sur les routeurs internes de Numéricable à Paris, vers le GIX parisien de Renater (pas loin de 40ms). Ensuite 8-10ms pour redescendre à Pau (en repassant par Poitiers...). Visiblement là où ça coince le plus c'est sur le peering d'interconnexion du GIX vers RENATER. Renater n'est pas en cause mais bien le FAI vers FranceIX (j'ai à peu près le même délai sur les GIX d'interconnexion internationale, mais beaucoup moins vers les autres FAI grand publics (Orange, SFR, Free) ou vers Google (total voisin de 40ms, inclus les 8-13ms de Numéricable entre Niort et son premier routeur publiquement accessible à Paris), car il perd moins de temps sur ces autres peerings mieux dimensionnés. Toi tu passe par Sfinx Lyon où SFR se connecte à Renater, et c'est encore moins bon alors que ça emprunte une route régionale transversale sans aller-retour à Paris (mais entre Sfinx et Pau ça marche bien). Ça confirme qu'il vaut mieux en France être hébergé à Paris, même si le traffic fait l'aller-retour. Les FAI sont stupides (là je parle de SFR, mon ancien opérateur, mais aussi de Numericable et les autres qui ont mis en place leur peering en étoile qui devient un goulet à Paris dès qu'on change de réseau). Le 20 décembre 2012 00:29, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 09:48, Cyrille Giquello cyrill...@gmail.com a écrit : Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Merci pour ce travail, c'est une excellente nouvelle. Ok le chemin vers Pau va être plus long mais le serveur de rendu sera moins chargé et c'est à mon avis ce qui compte le plus, partager la charge. Sinon, on dirait que de chez moi le routage n'est pas encore actif traceroute to a.tile.openstreetmap.org (193.63.75.98), 30 hops max, 60
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Bogue de Gmail alors (dans son interface web). Je n'ai qu'une seule copie reçue et je n'ai certainement fait aucun copier-coller d'un mail à l'autre. Je ne sais pas pourquoi le 1er mail est parti plus tôt mais incomplet et réexpédié complet 20h plus tard. Le 20 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : Le jeudi 20 décembre 2012 à 00:43 +0100, Philippe Verdy a écrit : Le premier n'était pas parti selon Google, et je n'ai reçu qu'une copie, la deuxième. C'est sans doute le serveur de mail de cette liste qui a eu un raté le première fois, expliquant pourquoi Google l'a gardé, ou alors il a été mal reçu la première fois (non confirmation de la transaction) et renvoyé automatiquement le lendemain. T'es sûr ? C'est possible ? ya 3h tu nous disais tous le contraire.. je te cites : Je les ai lu au moment où je les ai reçus sans retard, et je sais même avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout de suite pratiquement à la seconde : je le sais lorsque je suis en discussion au téléphone et que j'envoie un mail à la même personne, le délai pour que la personne au bout du fil ait le mail n'excède pas quelques secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est pratiquement la seconde dans les deux sens, si on est tous les deux sur Gmail). Maintenant il est possible que tu ne reçoives pas les messages dans le même ordre et que des réponses des uns et des autres se croisent. Donc n'interprète pas un désordre apparent entre des messages des uns et des autres qui se succèdent en quelques minutes (selon la vitesse que met chaque FAI à livrer ses mails dans les boites aux lettres). Je t'épargnes les en-têtes de tes mails qui prouve qu'ils ont circulé en temps et en heure ! En tout cas tu nous fait bien rire, on a anticipé ta réponse ! [23:33] xx RedFox: ça serait un bug de la mailing list visant notre pauvre philippe que ça m'étonnerait pas [23:34] xx c'est toujours sur lui que ça tombe [23:34] RedFox arfff :D Librement, -- Christophe Merlet (RedFox) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le jeudi 20 décembre 2012 à 01:04 +0100, Philippe Verdy a écrit : tracert b.tile.openstreetmap.org Toi tu passe par Sfinx Lyon où SFR se connecte à Renater, et c'est encore moins bon alors que ça emprunte une route régionale transversale sans aller-retour à Paris (mais entre Sfinx et Pau ça marche bien). Ça confirme qu'il vaut mieux en France être hébergé à Paris, même si le traffic fait l'aller-retour. Les FAI sont stupides (là je parle de SFR, mon ancien opérateur, mais aussi de Numericable et les autres qui ont mis en place leur peering en étoile qui devient un goulet à Paris dès qu'on change de réseau). Il n'y a pas de sfinx à Lyon, il est a paris. Donc SFR ne peer pas avec Renater à lyon, donc ce que tu as écrit n'a pas de sens ! Tu as une imagination débordante. Pourquoi n'utilises tu pas ce talent pour écrire des contes pour enfant pour les endormir ? Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
SFINX c'est déjà Renater (sur 2 POP parisiens). Mais toi (en fait SFR, aussi Free à Telehouse 2) tu transites par la branche lyonnaise de Renater, Numericable fait son peering sur un autre POP de Renater et transite par la branche vers Bordeaux et c'est un peu plus rapide. Je ne vois pas Orange se connecter à Renater via SFINX, mais Renater a un autre POP à Aubervilliers pour le peering avec Orange. Le 20 décembre 2012 01:16, Christophe Merlet red...@redfoxcenter.org a écrit : Il n'y a pas de sfinx à Lyon, il est a paris. Donc SFR ne peer pas avec Renater à lyon, donc ce que tu as écrit n'a pas de sens ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Quel dommage que les Pyrénées-Atlantiques soient eux-même toujours aussi incomplets pour les limites administratives (et au passage puisqu'il va servir aussi l'Espagne et l'Andorre, il serait temps de finir les communes manquantes des Pyrénées françaises (l'Espagne est à peu près complète au plan administratif sauf concernant les comarques à peine commencées, surtout en Catalogne et en Pays valencien). 2012/12/18 Pierre Béland infosbelas-...@yahoo.fr Voir .l'annonce du serveur de tuiles Pau sur talk. Pierre - Mail transféré - *De :* Richard Weait rich...@weait.com *À :* t...@openstreetmap.org t...@openstreetmap.org *Envoyé le :* Mardi 18 décembre 2012 13h14 *Objet :* Re: [OSM-talk] New OpenStreetMap tile server On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. ... to which I had intended to link. :-) http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Il dit qu'il voit pas le rapport ;) Le 18/12/2012 20:03, Philippe Verdy a écrit : Quel dommage que les Pyrénées-Atlantiques soient eux-même toujours aussi incomplets pour les limites administratives (et au passage puisqu'il va servir aussi l'Espagne et l'Andorre, il serait temps de finir les communes manquantes des Pyrénées françaises (l'Espagne est à peu près complète au plan administratif sauf concernant les comarques à peine commencées, surtout en Catalogne et en Pays valencien). 2012/12/18 Pierre Béland infosbelas-...@yahoo.fr mailto:infosbelas-...@yahoo.fr Voir .l'annonce du serveur de tuiles Pau sur talk. Pierre - Mail transféré - *De :* Richard Weait rich...@weait.com mailto:rich...@weait.com *À :* t...@openstreetmap.org mailto:t...@openstreetmap.org t...@openstreetmap.org mailto:t...@openstreetmap.org *Envoyé le :* Mardi 18 décembre 2012 13h14 *Objet :* Re: [OSM-talk] New OpenStreetMap tile server On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com mailto:rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. ... to which I had intended to link. :-) http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ ___ talk mailing list t...@openstreetmap.org mailto:t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Philippe, nous avons oublié l'essentiel, soit de féliciter Christophe Merlet, et sans doute OSM-France pour cette belle contribution. Pierre De : Philippe Verdy verd...@wanadoo.fr À : Pierre Béland infosbelas-...@yahoo.fr; Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Mardi 18 décembre 2012 14h03 Objet : Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server Quel dommage que les Pyrénées-Atlantiques soient eux-même toujours aussi incomplets pour les limites administratives (et au passage puisqu'il va servir aussi l'Espagne et l'Andorre, il serait temps de finir les communes manquantes des Pyrénées françaises (l'Espagne est à peu près complète au plan administratif sauf concernant les comarques à peine commencées, surtout en Catalogne et en Pays valencien). 2012/12/18 Pierre Béland infosbelas-...@yahoo.fr Voir .l'annonce du serveur de tuiles Pau sur talk. Pierre - Mail transféré - De : Richard Weait rich...@weait.com À : t...@openstreetmap.org t...@openstreetmap.org Envoyé le : Mardi 18 décembre 2012 13h14 Objet : Re: [OSM-talk] New OpenStreetMap tile server On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. ... to which I had intended to link. :-) http://blog.osmfoundation.org/2012/12/18/new-tile-server-in-pau-france/ ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. Cool ! Bravo à Redfox pour la coordination, et merci à PauLLA l'Université de Pau et des Pays de l’Adour (UPPA) et la Communauté d’Agglomération de Pau Pyrénées (CDAPP). J'aurais des doutes à émettre sur le bien fondé de la solution technique retenue par l'OpenStreetMap Foundation qui continue (cf blog) à demander ce genre d'initiative, mais là n'est point le lieu et j'accorde que ma pensée reste malgré tout : c'est mieux que rien -- sly, DWG member since 11/2012 Coordinateur du groupe [ga] http://wiki.openstreetmap.org/wiki/User:Sletuffe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mardi 18 décembre 2012 à 20:16 +0100, sly (sylvain letuffe) a écrit : On Tue, Dec 18, 2012 at 1:13 PM, Richard Weait rich...@weait.com wrote: The OpenStreetMap Foundation is pleased to announce new OSM infrastructure, in the form of a new tile server, located in Pau, France. Details on the OSMF Blog. Cool ! Bravo à Redfox pour la coordination, et merci à PauLLA l'Université de Pau et des Pays de l’Adour (UPPA) et la Communauté d’Agglomération de Pau Pyrénées (CDAPP). J'aurais des doutes à émettre sur le bien fondé de la solution technique retenue par l'OpenStreetMap Foundation qui continue (cf blog) à demander ce genre d'initiative, mais là n'est point le lieu et j'accorde que ma pensée reste malgré tout : c'est mieux que rien bah si, on peut en discuter. Moi-même je ne suis pas totalement séduit par la solution actuelle (Cache Squid). Je trouve que le ratio hit/miss n'est pas fantastique mais néanmoins suffisant pour décharger un peu le Master. Mais cette solution a plusieurs avantages. C'est facile à administrer à distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en 9h, 18 Go de tuiles distinctes ont été demandées). Il semble que les sysadmins osm réfléchissent à d'autres solutions, genre des générateurs de tuiles autonomes. Mais là, il faut du matos beaucoup plus costaud. Et s'assurer de la disponibilité d'une chaine complète de rendu de tuiles me semble bien plus compliquer à gérer. Pas sûr que les internautes y gagne avec cette solution. Mais tout compte fait, la seule vraie bonne solution à long terme est que les gros consommateurs de tuiles installe leur propre serveur... Tu vois quoi comme autres solutions ? Librement, -- Christophe Merlet (RedFox) signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Constat proche pour moi (aussi chez free), le ping est quasiment identique (dans les 40/45ms) et même nombre de hops. Un cache de tuile chez free Bezons diviserai mon ping presque par 2 (23ms en moyenne sur osm11) ;) Le geodns pourrait-il rediriger les requêtes provenant des AS de free vers un serveur chez free ? Christophe, ça serait possible de rajouter ce serveur dans le munin d'OSM-FR ? Le 18 décembre 2012 23:53, Eric Marsden eric.mars...@free.fr a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. -- Eric Marsden ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
C'est vrai que le gain n'est pas flagrant et en tout cas pas en vitesse c'est même plus long qu'avant en cas de cache-miss, j'ai déjà eu plusieurs interruptions de sessions (avec des tuiles incomplètes de taille zéro) à cause du temps de réponse du serveur de tuile principal à répondre à son serveur proxy Squid. Les problèmes commencent avec le zoom niveau 12 et on a des rafraîchissements qui ne se font quasiment plus concernant les tuiles obsolètes : il faut maintenant rafraîchir la même tuile deux fois avec quelques minutes d'écart entre chaque pour que ce soit dispo sur le Squid de Pau. Certes cela soulage certainement le serveur de Londres en bande passante, mais pas en travail à faire pour calculer les tuiles (qui du coup sont calculées et rendues disponibles pour finalement ne jamais être utilisées car la première requête a retourné l'ancienne version et remplis le cache Squid à Pau qui va donc continuer aussi à retourner cette version (le truc du /dirty ne semble plus fonctionner : oui il demande le rafraichissement mais cela ne force pas l'invalidation de tuiles du serveur de Pau (sauf si on modifie l'URL avec un paramètre GET ajouté dans lURL des tuiles tel que ?1, ?2 pour lui demander d'ignorer son cache et retourner la version du serveur de Londres ; le /dirty répété ne forcera plus non plus une nouvelle demande au serveur de rendu et le /status continue alors d'aficher l'ancien statut même si la tuile a bien été rafraichie à Londres). Il semble que la cause de tout ça vienne de Mapnik et non de l'installation du proxy-cache Qquid : au lieu de mettre une réponse au client en attente sur sa session, il préfère retourner une version ancienne déjà calculée (mais avec une durée de péremption trop longue pour cette réponse qui ne devrait être qu'instantanée et pas recachable en aval) en attendant pour terminer la session plus tôt (et cela pose des problèmes de cohérence de cache, un problème qui existe depuis assez longtemps même avant l'entrée en scène des serveurs proxy Squid). Squid ne semble pas en cause (cela marche très bien par exemple avec Wikipédia qui parvient très bien à suivre les mises à jour), mais bien le frontend de Mapnik (autrement dit le serveur WMS qui lui pilote son travail à faire). L'avantage de répondre immédiatement au client est d'économiser des sessions en attente du côté du serveur (et donc éviter la non disponibilité de nouveaux ports TCP pour d'autres sessions HTTP s'il y a du monde), mais ici le problème est la non péremption immédiate (ou la péremption trop longue) des tuiles obsolètes qui sont en attente de recalcul. A mon avis le serveur Squid pour la France, l'Espagne ou l'Italie serait mieux à Londres ou à Amsterdam, voire à Paris, plutôt qu'à Pau si on veut un temps de réponse correct, étant donné que les FAI français ont tous leur routage au départ de Paris avec un peering efficace vers Londres et Amsterdam. Même chose pour les FAI espagnols ou italiens qui feront leur peering efficace vers Pau en passant par Paris ou Amsterdam d'abord. Le peering de Paris vers Pau via le réseau RENATER n'est pas foundroyant, il n'a pas été tellement taillé pour un usage massif. La situation serait meilleure si la Fondation trouvait un partenariat avec des CDN mondiaux — comme Level3 qui a des serveurs proxy HTTP dans pratiquement tous les pays, et même dans les GIX régionaux (pour les FAI français qui ont des peerings régionaux et qui y sont directement connectés sans faire transiter tout le trafic de leurs abonnés par Paris où se concentre leur réseau de collecte national). Ou même avec d'autres fournisseurs de CDN comme Google/Youtube, Amazon, Microsoft/Bing, Yahoo (d'abord pour leurs propres services en ligne mais aussi pour leurs offres commerciales aux sites tiers)... La Fondation Wikimedia par exemple a bénéficié du partenariat avec Yahoo (ou avec d'autres FAI internationaux comme Orange pour l'Europe et l'Afrique) pour déployer des serveurs Squid correctement localisés dans le monde avec des peerings efficaces (cela a été plus payant que de chercher à gérer elle même des serveurs Squid à gérer elle-même), et même une distribution gratuite pour les visiteurs (offre gratuite non décomptée du forfait data sur un réseau mobile). OSM France utilise une plateforme de Free qui marche bien grâce à sa présence directe sur un GIX parisien rapide (Freeix) qui a de bonnes connexions de peering avec la plupart des FAI français et européens. La présence sur le GIX de RENATER ne marche bien que si les visiteurs français passent par un FAI universitaire ou si ce sont des collectivités, mais pas très bien pour les abonnés résidentiels (le peering gratuit d'un FAI classique vers RENATER a une bande passante limitée et des restrictions pour l'équilibrage des flux trop asymétriques). Sur quel GIX est connecté le serveur de Pau, seulement RENATER ? Le 19 décembre 2012 00:26, Christian Quest cqu...@openstreetmap.fr a écrit : Constat proche pour moi (aussi chez free), le ping est
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
Le mardi 18 décembre 2012 à 23:53 +0100, Eric Marsden a écrit : cm == Christophe Merlet red...@redfoxcenter.org writes: cm Mais cette solution a plusieurs avantages. C'est facile à administrer à cm distance. ça ne nécessite pas de serveur puissant, juste de la RAM (en cm 9h, 18 Go de tuiles distinctes ont été demandées). L'intérêt d'un serveur distinct de celui à Londres pour les utilisateurs français me semble discutable. Depuis ma connexion Free au domicile à Toulouse, je suis à 63 ms (16 hops) de uppa-vl10-gi0-3-0-0-pau-rtr-011.noc.renater.fr, alors que je suis à 52 ms (15 hops) de me-rach.net.ic.ac.uk. J'imagine que c'est pareil pour la majorité des FAI français, qui font du peering vers Renater uniquement à Paris. Et en cas de miss la requête part quand même à Londres ... Ensuite depuis mon travail (connexion Renater) je suis à 3.8ms (7 hops) du serveur paulla, mais ça n'est pas très representatif des utilisateurs en général ... De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... Par contre au boulot, je suis à 0,3 ms... 2 switchs et 1 routeur ;o) Ceci dit, j'imagine que ça décharge un peu le lien vers Imperial College, ce qui doit leur être utile, donc merci et bravo à RedFox pour cela. Je pense que le serveur principal à gagné entre 10 et 20 mbs de bande passante sur plus de 100. Voir graphique en pièce jointe sur la courbe d'aujourd'hui par rapport aux jours précédents. C'est pas si mal pour commencer. Librement, -- Christophe Merlet (RedFox) attachment: if_eth0-week.png signature.asc Description: This is a digitally signed message part ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server
On a en France le problème typique des FAI grand public qui concentre TOUT le trafic de leurs abonnés à Paris ou autour (sauf pour leurs propres services à leurs propres abonnés par exemple pour la télévision ou la téléphonie) et n'ont encore jamais fait l'effort de déployer des peerings régionaux pour aussi inciter d'autres opérateurs européens à y assurer une présence. Pour passer d'un FAI à l'autre tout remonte donc toujours à Paris. C'est leur façon de faire une économie d'échelle, même si ça perpétue la fracture numérique entre Paris et le reste de la France du côté des offres résidentielles, avec un décalage croissant des performances et pléthores de solutions par chères quand on est à Paris. Renater a fait cet effort, mais les FAI continuent de remonter tout le routage des sessions ADSL et même câble ou fibre en faisant terminer la session VPN de l'abonné sur un routeur à Paris. La France est pour les FAI un pur réseau étoilé et pas une boucle maillée comme dans d'autres pays européens comme le Royaume-Uni ou les Pays-Bas... où du coup ils restent dépendant des solutions (et tarifs) des grands groupes internationaux, principalement américains. Même Orange fait remonter tout son traffic des abonnés résidentiels français à Paris/Aubervilliers et ne fait du Peering que vers les autres GIX français sur leur POP Parisien (Téléhouse/Courbevoie) ou délègue presque tout le reste vers Amsterdam ou Londres (sauf vers les US où les FAI ont un peering vers les 2 côtes océaniques de NYC et LA, et parfois Miami, Dallas et Chicago). Tout cela vient du fait que nos FAIs sont presque tous nationaux (et peu nombreux) et qu'on n'a pas beaucoup de FAI régionaux. SFR ne fait pas mieux pour ses abonnés non plus, pas plus que Numéricable ou Free, eux aussi déployés en étoile et non en boucles régionales. Du coup les GIX régionaux sont minuscules et progressent bien peu. L'ennui c'est qu'avec un tel déploiement on donne à tout le monde une latence (ping) voisine de 30 ms et cela va consituter un frein sérieux au très haut débit en TCP (à cause de la taille maxi des fenêtres TCP, cette latence impose un débit maximum impossible à dépasser, loin de la capacité des fibres, ou alors il faut augmenter démesurément la taille des fenêtres TCP et on barre la route aux accès THD mobiles : pas étonnant que la 4G/LTE tarde tant en France à démarrer). Le 19 décembre 2012 01:00, Christophe Merlet red...@redfoxcenter.org a écrit : De chez moi (a Pau évidemment), en fibre optique, Londres est à 30ms, Pau est à... 40ms !! SFR m'envoie au SFINX, puis direction Lyon, et retour au point de départ via Bordeaux oo' Pire, il est censé y avoir un petit GIX local mais il ne fait pas preuve d'une grande efficacité :/ On espère voir la situation évoluer... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
