La Fibre
Télécom => Télécom => 
Veille technologique => Discussion démarrée par: BadMax le 15 juin 2014 à 22:36:23
-
Emission de France 5 sur la conséquence de la pollution liée à l'activité d'Internet prévue le mardi 17/06 : http://www.france5.fr/emissions/le-monde-en-face/diffusions/17-06-2014_246765 (http://www.france5.fr/emissions/le-monde-en-face/diffusions/17-06-2014_246765)
Note: j'ai juste vu la bande annonce, je n'ai pas d'avis sur le contenu qui pourrait etre orienté dans un sens ou dans l'autre, mais ça pourrait etre intéressant à regarder.
Jeu: quel est l'équipement dont on voit la face arrière en fin de bande annonce ?
-
Si internet consomme de l'énergie, il permet aussi d'en économiser : Dématérialisation des factures de plus en plus courant, Achat de bien dématérialisés (fabriquer un CD audio, cela coûte de l'énergie), Vidéo conférence, ne plus avoir besoin de se déplacer à sa banque économise de l'énergie, les virements qui remplacent les chèques ect...
Le souci c'est que cela crée de nouveau besoins.
Avec des besoins qui resteraient identique, Internet diminuait la consommation d'énergie.
Pour les équipements à la fin, cela ressemble à des serveurs...
-
Non, c'est pas des serveurs .... :)
Bon, si c'est diffusé un peu tard, je ne pourrai pas regarder mais je pense que certains aspects sur les besoins en terres rares sont abordés. On a un tel taux de renouvellement de nos équipements que notre consommation de silicium, or, etc est très très élevée et consomme aussi beaucoup d'énergie. Si on prend le cout énergétique de toute la chaine Internet, est-ce qu'on s'y retrouve tant que cela ?
Je n'ai pas la réponse et j'ai hate de voir de quelle manière le sujet est abordé. J'espère qu'ils auront évité le parti-pris.
-
C'est clair qu'il y aurais de grosses économie est réduisant l'obsolescence programmée.
Si un PC se garde de 4 à 8 ans, pour les téléphones et les tablettes, c'est beaucoup plus court.
-
Ce sera de 21h35 à 22h45.
-
Y'a moyen d'enregistrer ce genre d'émission ?
-
Pour ceux qui ne peuvent pas enregistrer, je ne le fais pas. Donc pas de faux espoir avec moi.
Certaines émissions de France 5 du même genre se retrouvent sur Youtube. Donc à voir si ce sera le cas avec celle-là.
-
France5 a un replay qui fonctionne même sous Linux.
-
MODÉRATION :
J'ai déplacé la discussion sur le nucléaire :
https://lafibre.info/techno-du-web/nucleaire-accident-de-la-centrale-lenine-pierre-pellerin/
-
France5 a un replay qui fonctionne même sous Linux.
Oui, mais c'est limité dans le temps.
Aujourd'hui, je ne peux remonter que jusqu'au 9 juin. Soit une semaine.
Si c'est juste pour le voir peu de temps après la diffusion TV, pourquoi pas. Sinon, c'est Youtube (et peut être des alternatives comme dailymotion, vimeo, wat.tv, etc).
Merci de cette précision, car je l'avais oublié.
-
Si internet consomme de l'énergie, il permet aussi d'en économiser : Dématérialisation des factures de plus en plus courant, Achat de bien dématérialisés (fabriquer un CD audio, cela coûte de l'énergie), Vidéo conférence, ne plus avoir besoin de se déplacer à sa banque économise de l'énergie, les virements qui remplacent les chèques ect...
Le souci c'est que cela crée de nouveau besoins.
Avec des besoins qui resteraient identique, Internet diminuait la consommation d'énergie.
C'est quoi "Internet"?
Tout ce qui est fait dans un data-center fait parti d'Internet?
-
Ben justement, c'est là où j'aimerai voir comment le sujet a été abordé. Est-ce qu'on parle juste du "Cloud" avec Google, Facebook, Amazon, Twitter, etc ou est-ce qu'on parle de toute la chaine IT qui gravite autour du NET : les Datacenters, les tuyaux, les abonnés, les entreprises, etc.
-
Enregistrement programmé ;)
Le synopsis laisserait penser que le débat tournera essentiellement autour de la consommation électrique des datacenters.
-
Le synopsis laisserait penser que le débat tournera essentiellement autour de la consommation électrique des datacenters.
Eh bah, ce sera aussi passionnant que de polémiquer sur l'énorme consommation d'eau d'une brasserie. A la vôtre :)
-
Alors vous avez vu cette émission ? Y a eu des trucs intéressants de dit ?
-
Voilà mon enregistrement : http://vps.thibault01.com/videos/Internet%20pollution%20cach%C3%A9e-France5-17-6-2014.mp4 (http://vps.thibault01.com/videos/Internet%20pollution%20cach%C3%A9e-France5-17-6-2014.mp4)
Vous pouvez regarder en live ou télécharger.
Si il y a des petites coupures c'est normal, j'ai un PC qui à download en même temps et il y a un petit problème de TV sur le routeur quand on commence à monter en débit.
-
Merci de tes efforts mais l'emission est également disponible ici : http://pluzz.francetv.fr/videos/internet_la_pollution_cachee_,103999435.html (http://pluzz.francetv.fr/videos/internet_la_pollution_cachee_,103999435.html)
-
Bon, un volontaire pour en faire une fiche de lecture ? J'ai meme la flemme de regarder tellement je le sens pas ce sujet...
-
En gros le souci c'est la production électrique.
Il est question de limiter le minage du charbon en Amérique qui sert à alimenter les Datacenters.
D'après certaines personnes, il serai intéressant d'alimenter un Datacenter par des panneaux solaires.. Mais je ne suis pas d'accord car la construction d'un panneau solaire pollue plus que ce qu'il produit de vert pendant sa phase de vie..
Alors il y a un aspect que je ne comprend pas dans ce reportage, c'est celui d'avoir des portions de Datacenter dans nos immeubles.. Comment techniquement parlant pourrions-nous avoir des portions de Datacenter chez nous?
Bref, reportage assez peu intéressant car le problème ne vient pas des Datacenters mais bien de la production électrique.. Je pense que les compagnies de production sont au courant et c'est aussi pour cela que des recherches et tests sont fait chaque jour..
-
J'ai regardé les 2 émissions France 5 de la soirée. Autant la première sur la place de nos écrans dans la société était plutôt bien faite.
Par contre, la 2ieme émission sur la pollution du monde numérique, bof bof. De belles images de datacenter, d'infrastructures télécom, comme je les aime.
Mais on tombe rapidement dans le sensationalisme journalistique. Le sujet n'est pas creusé, on nous balance des chiffres "tel datacenter consomme l'équivalent de tant de milliers d'habitants", pour nous faire peur, mais c'est tout. Pas d'analyse approfondie du sujet. On ne sait pas quelle proportion de l'électricité est consommée par le business numérique, ni quelles sont les solutions pour diminuer.
Beaucoup de données très discutables : 1 e-mail consommerai 30Wh selon le reportage, je n'y crois pas une seule seconde! Vu qu'un serveur e-mail de quelques centaines de watts sait traiter des milliers/dizaines de milliers d'e-mails par heure.
Et puis la partie optimiste du reportage (on connait le scénario de ce genre de reportages type "national geographics") sur les "smartgrid" et les "serveurs-radiateurs à la maison", c'est juste une lecture de la pub des fournisseurs de ces 2 solutions, rien de plus. Là non plus, aucune analyse sur la pertinence du truc. Pour moi, les "smartgrid" ne pourront pas changer fondamentalement la production/consommation électrique. Pour les "serveurs-radiateur à la maison", là aussi, ça me semble anecdotique par rapport au problème. Il me parait impensable de généraliser la pratique à une portion significative des serveurs.
Leon.
-
Un DC à la maison, déjà fait :D
Ca fait chauffage d'appoint l'hiver...
L'idée n'est pas mauvaise, utiliser les ressources CPU inutilisées du grand public... ça a été testé à l'époque de Distributed.Net et Seti@Home, ça a pas mal marché.
Mais peu importe on retombera sur le meme problème à savoir la production d'électricité. Le PV je n'y crois guère, l'énergie est trop intermittente, l'éolien me semblerait plus adapté meme malgré son faible rendement. Mais tant que l'énergie "de réseau" coutera moins chère que l'énergie "en propre", aucune chance que ça ne se développe vraiment.
Reste à baisser la consommation des DC en travaillant le PUE. Merci je ne perdrais pas mon temps à regarder ce doc.
-
Un DC à la maison, déjà fait :D
Ca fait chauffage d'appoint l'hiver...
L'idée n'est pas mauvaise, utiliser les ressources CPU inutilisées du grand public... ça a été testé à l'époque de Distributed.Net et Seti@Home, ça a pas mal marché.
Juste pour préciser: dans le reportage, ils font la pub pour la startup française "qarnot computing", et leurs serveurs-radiateur.
http://www.qarnot-computing.com/technology (http://www.qarnot-computing.com/technology)
Mais peu importe on retombera sur le meme problème à savoir la production d'électricité. Le PV je n'y crois guère, l'énergie est trop intermittente, l'éolien me semblerait plus adapté meme malgré son faible rendement. Mais tant que l'énergie "de réseau" coutera moins chère que l'énergie "en propre", aucune chance que ça ne se développe vraiment.
OVH au Canada pourrait très bien annoncer qu'il fonctionne 100% à l'énergie renouvelable, vu qu'il est alimenté par des barrages d'Hydro-Quebec. Mais ça ne veut pas dire que cette forme d'énergie renouvelable est sans impact sur l'environnement.
Reste à baisser la consommation des DC en travaillant le PUE.
En fait, je crois que beaucoup de monde se trompent en ne regardant que le PUE du datacenter. Pour gagner beaucoup, il faut d'abord travailler sur les serveurs eux-même et la façon de les utiliser.
* Utiliser des composants moins énergivores
* Pour tout ce qui est redondant dans un serveur/installation IT, essayer au maximum de laisser la partie redondante en veille (alim serveur, serveur de secours, etc...)
* Apprendre à coder de manière économique (en terme de ressource / conso électrique)
* dans un groupe de serveurs (frontaux web par exemple), éteindre des serveurs lors des périodes creuses
* développer le maximum de code en "accélération hardware" (nous en sommes au tout début)
Leon.
-
L'idée n'est pas mauvaise, utiliser les ressources CPU inutilisées du grand public...
Mouais, c'est surtout un déplacement du problème.
Un PC du grand public qui ne fait rien, ne consomme rien;
Et si tu le fait travailler, il faut temperer le gain dans le DC par l'augmentation de la consommation chez le grand public.
-
* développer le maximum de code en "accélération hardware" (nous en sommes au tout début)
Leon.
C'est marrant ce que tu dis car c'est l'inverse de la tendance : il y a 20ans et plus, on programmait souvent en assembleur. Puis on ne l'a conservé que pour les sections critiques (vitesse d'exécution, code embarqué, etc). Enfin, on a tout passé en Java ou autre langage de haut-niveau. Bref, on s'est vachement éloigné du hardware et on a perdu en optimisation du code. Y'a bien un effort qui a été fait niveau graphique mais on doit encore utiliser des API spécifiques.
-
Voilà mon enregistrement : http://vps.thibault01.com/videos/Internet%20pollution%20cach%C3%A9e-France5-17-6-2014.mp4 (http://vps.thibault01.com/videos/Internet%20pollution%20cach%C3%A9e-France5-17-6-2014.mp4)
Vous pouvez regarder en live ou télécharger.
Si il y a des petites coupures c'est normal, j'ai un PC qui à download en même temps et il y a un petit problème de TV sur le routeur quand on commence à monter en débit.
Merci de tes efforts mais l'emission est également disponible ici : http://pluzz.francetv.fr/videos/internet_la_pollution_cachee_,103999435.html (http://pluzz.francetv.fr/videos/internet_la_pollution_cachee_,103999435.html)
laquelle des deux 'sources' consomme le moins d'électricité par minute de vidéo regardée ? :)
-
C'est marrant ce que tu dis car c'est l'inverse de la tendance : il y a 20ans et plus, on programmait souvent en assembleur. Puis on ne l'a conservé que pour les sections critiques (vitesse d'exécution, code embarqué, etc). Enfin, on a tout passé en Java ou autre langage de haut-niveau. Bref, on s'est vachement éloigné du hardware et on a perdu en optimisation du code. Y'a bien un effort qui a été fait niveau graphique mais on doit encore utiliser des API spécifiques.
Je pense qu'il ne faut pas confondre les 2 concepts:
* programmer proche du hardware (assembleur)
* utiliser de l'accélération matérielle (hardware)
L'accélération matérielle, c'est utiliser un hardware dédié (ASIC) ou configuré (FPGA) pour effectuer une tâche assez simple, et surtout très répétitive, de manière beaucoup plus efficace que ne sait le faire un processeur (qui est avant tout flexible). On pourrait imaginer des serveurs où une énorme partie du travail est réalisé par des FPGA/GPU/ASIC. Des serveurs moins flexibles, mais plus efficaces. Mais on sait mal le faire aujourd'hui. Il faut avoir les bons outils pour développer de telles applications. Et le monde de la micro-électronique cherche à développer des outils de développement "haut niveau" pour ce genre d'application, donc en laissant le programmeur éloigné du hardware. Je pense que nous ne sommes qu'au début de cette tendance, beaucoup de choses restent à inventer.
Leon.
-
A part le monde des cartes graphiques et matériel spécialisé (routeur, swich), pour le reste c'est pas terrible. J'ai vu des tentatives ratées de faire tourner du Linux "classique" sur une architecture matérielle spécialisée réseau. La faute à un écart trop important entre le code originel et la partie matérielle. On va dire que ça coute pas cher de tout gérer en soft alors que les développements hard coutent très cher. Y'a qu'à regarder l'aéronautique : on faisait à l'époque du Concorde des calculateurs entièrement mécaniques (pour certains qu'on ne sait plus refaire) et aujourd'hui on essaye de tout faire en soft.
Tiens un autre exemple: une montre GPS Garmin exploite le signal au max de ses possibilités pour une taille réduite et une autonomie maximale grace à des traitements en hard. Avec un smartphone, on n'a ni l'un l'autre et pas le meme résultat. Dans ce dernier, le traitement GPS est fait au maximum en soft au détriment de la conso CPU et donc de l'autonomie. La précision s'en ressent.
-
Bref, reportage assez peu intéressant car le problème ne vient pas des Datacenters mais bien de la production électrique.. Je pense que les compagnies de production sont au courant et c'est aussi pour cela que des recherches et tests sont fait chaque jour..
Elles sont d'ailleurs bien plus qu'au courant : elles font tout pour proposer l'électricité la moins chère possible pour des clients aussi gros et prestigieux comme Google, Facebook ou autres. Et plus tu consommes, plus tu peux négocier le prix, forcèment. Rien ne t'incite donc à réduire ta consommation.
Après, moi je trouve que c'est aussi les internautes qu'il faut éduquer. C'est vrai, Greenpeace tape sur les acteurs du web, mais bon c'est aussi les internautes qui font le truc. Si un site ou pire, que l'Internet ne fonctionne plus, bah c'est l'occasion idéale de faire autre chose, redécouvrir les plaisirs charnels & cie, faire la vaisselle qui s'entasse, on revient après, c'est pas grave, les données sont toujours là.
Du coup, j'ai justement posé la question à mes abonnés : est-ce que vous pourriez supporter la coupure du service pendant quelques heures en cas de panne/maintenance contre une bonne diminution du prix ? A l'unanimité c'était un OUI. Bah voilà, moins de housing, moins de matos, moins d'EDF, moins d'entretien, c'est vite vu...
Évidemment chaque service est différent hein (pour moi c'est facile), mais la question mérite d'être posée rien que pour faire prendre conscience aux gens qu'on n'a pas forcèment besoin de redondance et que tout le monde y gagne : l'internaute, l'opérateur et la planète. Surtout que la redondance c'est bien joli surtout avec un pb software qui fait tout merder ^^
A part le monde des cartes graphiques et matériel spécialisé (routeur, swich), pour le reste c'est pas terrible. J'ai vu des tentatives ratées de faire tourner du Linux "classique" sur une architecture matérielle spécialisée réseau. La faute à un écart trop important entre le code originel et la partie matérielle. On va dire que ça coute pas cher de tout gérer en soft alors que les développements hard coutent très cher.
CPU Haswell mobile, qq Go de RAM, un petit SSD, 2 NIC Intel 4p 1G aux fesses, un Linux + Bird, 500€ c'est bon, 8Gbps de capa de routage pour seulement 50 watts en charge. C'est cheap, mais ça fait le job.
-
C'est marrant ce que tu dis car c'est l'inverse de la tendance : il y a 20ans et plus, on programmait souvent en assembleur. Puis on ne l'a conservé que pour les sections critiques (vitesse d'exécution, code embarqué, etc). Enfin, on a tout passé en Java ou autre langage de haut-niveau. Bref, on s'est vachement éloigné du hardware et on a perdu en optimisation du code. Y'a bien un effort qui a été fait niveau graphique mais on doit encore utiliser des API spécifiques.
En total désaccord avec toi.
L'assembleur est clairement quand tu as besoin d'une opération que le langage ne propose pas et que le compilateur ne générera jamais :
choses qui sont beaucoup rapides avec de l'assembleur :
- lire le status word : retenue, overflow, underflow
- add avec retenue (pour faire des additions à plusieurs chiffres, chaque chiffre étant un mot)
- arithmétique en décimal (sur 68000)
- opération arithmétique avec exception en cas de débordement
- opération crypto (notamment AES)
choses qui ne sont possibles qu'en assembleur :
- test and set, compare and swap (atomique)
- opération arithmétique non interruptible (incrèmentation atomique...) sur Intel
- gestion des interruptions
- changement de mode
- gestion de la pagination, visibilité mémoire, accessibilité mémoire
bref pour une primitive. Ces primitives peuvent être présentées dans des macros ou fonctions en-lignes.
Au delà de ça, la programmation en assembleur parle le langage du processeur, mais n'est pas proche du métal : les instructions en assembleur sont complexes (surtout sur "CISC") et décomposées en opérations élèmentaires (fetch, op, store), le tout sur des registres physiques qui ne correspondent pas aux registres nommés en assembleur. Les opérations peuvent être exécutées en même temps (en l'absence de dépendance de données) et spéculativement (en présence de dépendance de contrôle); en cas d'anti-dépendance sur un registre, le processeur contourne le problème en utilisant plusieurs registre et parallélise les opérations. Il est très difficile pour un programmeur assembleur de gérer ce niveau d'abstraction, alors qu'un compilateur est fait pour ça.
La programmation assembleur a eu ses grandes heures sur des processeurs proches de leur langage assembleur, où la relation entre les instructions et leur exécution était relativement simple. Sur un processeur "moderne" disons à partir du Pentium c'est de moins en moins le cas.
La programmation assembleur n'incite pas du tout à optimiser les traitements, mais juste à micro-optimiser. Comme tout est très laborieux, on utilise souvent en assembleur des structures de données très simples (*), comme les listes chaînées, que des structures plus difficiles à implèmenter mais meilleurs quand il y a beaucoup de données (table de hachage, arbre rouges-noirs, arbres B...); comme une réorganisation du code avec modification d'une structure de donnée est une tâche très difficile sans le niveau d'abstraction nécessaire dans le code, cela a lieu rarement.
(*) Il est vrai que pour un petit nombre d'éléments, les structures les plus simples sont souvent plus efficaces en temps et en mémoire, car le raffinement a un coût (un B-tree est passablement complexe) et que les structures compliquées impliquent des algo compliqués avec plein de branchements qui bloquent la pipeline.
De plus, les choses qu'on faisaient "à la main" à une époques comme des calculs graphiques lourds (textures dans un jeu 3D par exemple) sont sous-traités à une carte graphique.
Les programmes sont gros et lourds principalement parce que les programmeurs sont indifférents à cela, qu'ils utilisent des "framework" monstrueux pour faire le moindre truc, et aussi parce que beaucoup de programmeurs sont vraiment très médiocres.
Une fois que les opérations lourdes comme les calculs de textures dans un jeu sont sous traités, le reste est d'assez haut niveau, certains jeux sont programmés dans des langages interprétés (pour les réactions de l'IA).
Les programmes sont souvent limités par le nombre d'opérations disques ou de BDD qu'ils font : par exemple ce forum, pour fabriquer la moindre page HTML il faut plusieurs requête SQL; là tout va se jouer sur le fait d'avoir les bons index et de formuler les requêtes pour qu'ils soient utilisables. C'est tout l'art de bien décomposer et formaliser un problème.
-
Un PC du grand public qui ne fait rien, ne consomme rien;
Et si tu le fait travailler, il faut temperer le gain dans le DC par l'augmentation de la consommation chez le grand public.
Et il faut tempérer l'augmentation de conso par la diminution du chauffage en hiver, mais l'augmenter de la consommation de climatisation en été!
-
Tiens un autre exemple: une montre GPS Garmin exploite le signal au max de ses possibilités pour une taille réduite et une autonomie maximale grace à des traitements en hard. Avec un smartphone, on n'a ni l'un l'autre et pas le meme résultat. Dans ce dernier, le traitement GPS est fait au maximum en soft au détriment de la conso CPU et donc de l'autonomie. La précision s'en ressent.
Un ordiphone peut télécharger les éphémérides via Internet et l'utiliser pour décoder immédiatement le signal GPS, est-ce que la montre peut faire ça?
-
je ne sais pas pour la montre mais en tout cas pour ma caméra avec gps intégré le téléchargement est fait a chaque raccordement au pc!
-
Le téléchargement des éphémérides t'aide à faire le point plus rapidement, ma monte Garmin peut en effet avoir besoin de 20 minutes pour se remettre à jour sauf si ta position n'a pas beaucoup changé de la dernière connue, ça ne prend qu'une minute. Mais là, tu ne parles que de la recherche de la position, moi je parle du traitement du signal GPS par une puce SIRFstart3 (https://en.wikipedia.org/wiki/SiRFstarIII) qui élimine toutes les interférences liées à la végétation et au relief. Un ordiphone doit faire ce traitement en logiciel et du coup ne peut rivaliser en précision. J'ai fait des tests de comparaison en ski de fond : la montre Garmin me voit systématiquement passer au meme endroit, quelle que soit ma vitesse et la trace se superpose parfaitement à une carte 1/25000e. L'ordiphone enregistre des écarts de traces d'un tour à l'autre de quelques dizaines de mètres. On est dans le respect de la norme GPS (soit 100m de précision garantie en norme "civile") MAIS un traitement matériel est bien plus efficace en terme de résultat, de consommation et d'espace qu'un traitement logiciel. Par contre, en terme de cout, l'ordiphone gagne allègrement.
Sur la programmation assembleur, pas besoin d'en écrire un roman, tu preches un convaincu, je fais seulement un constat, c'est tout. Je me rappelle qu'il y a 10 ans encore on utilisait de l'assembleur pour certains portions de code dans les jeux vidéos. Le but était clairement d'avoir un code rapide, il n'y avait aucun accès matériel. Tiens d'ailleurs, je me rappelle qu'il y avait des portions en asm x86 dans le code Quake 1 volé à Id Software en 96 qui ont ensuite disparu de la version opensource. Aujourd'hui, hormis le kernel Linux, ça fait bien longtemps que je n'ai pas vu passer de bout de code en assembleur. Certes c'est désuet, c'est pas pratique, un langage objet correct c'est quand meme 20x mieux mais putain ça roxx le 68k !
-
CPU Haswell mobile, qq Go de RAM, un petit SSD, 2 NIC Intel 4p 1G aux fesses, un Linux + Bird, 500€ c'est bon, 8Gbps de capa de routage pour seulement 50 watts en charge. C'est cheap, mais ça fait le job.
Peut mieux faire :)
Core i5 2400S / 8Go RAM / 2x 2To 5400rpm + 1x 500Go / ESXi 5.0 = 50watts
Mais ça reste énorme à mon gout. Un RaspberryPi fait partie de mes références en terme de rapport puissance/consommation meme si ça reste encore un peu limité/spécialisé à certaines utilisations. L'écart peut faire sourire mais multiplié par le nombre d'internautes, ça donne une idée du potentiel d'économie d'énergie.
Toute chose mesuré, y'a quand meme plus à faire en matière de chauffage et de transport que sur Internet.