enfin l’ADEME, sur ce sujet c’est un peu une blague. Quand on voit la méthodologie adoptée pour calculer l’équivalent CO2 sur la facture - pour ne citer que quelques exemples :
on fait une modélisation en repartant de 0 (et beaucoup moins précise) des réseaux plutôt que des modèles déjà bien fournis de l’Arcep (qui ont fait l’objet de plusieurs années de développement et qui ont été soumis à consultation publique plusieurs fois) et de chercher à les compléter,
on fait un modèle unique pour tous les opérateurs,
on ne prend absolument pas en compte la maintenance des infras (bah oui ça tombe jamais en panne c’est bien connu)
on peut se dire qu’en fait tout le monde cherche le sensationnalisme et absolument pas des chiffres fiables.
A ma connaissance, ça n’est pas tout à fait comme ça que ça se passe (ni s’est passé) :
le modèle est développé avec la contribution des opérateurs Français, qui contribuent aussi à celui de l’Arcep
L’arcep n’a pas, à la connaissance, de modélisation permettant un calcul des émissions des réseaux
Il ne s’agit pas d’un modèle unique pour tous les opérateurs mais d’une méthodologie de comptage (le PCR FAI) , qui doit être nécessairement commune pour pouvoir comparer les résultats
je ne vois pas ce qui te fait dire que la maintenance des infra n’est pas prises en compte. Le support ne l’est pas (boutiques, R&D, etc.) mais la maintenance si pour moi.
Le
15/03/2023 à
12h
50
MisterDams a dit:
[…] De la même façon, ma voiture à 110g de CO2/km “officiels” qui fait près de 100km de moins chaque semaine compense largement ma surconsommation de bande passante pour accéder à notre réseau interne en télétravail et faire des visio et du chat sur Teams à la place d’une réunion physique ou une demande orale. Le tout en ne parlant que de CO2, car la voiture rejette bien d’autres choses !
Le calcul est malheureusement bien plus complexe que ça, on ne peut pas se contenter de compter le nombre de km de voiture évités par le télétravail. Il faut aussi compter les éventuels effets rebonds et émissions induites. Par exemple, avec la généralisation du travail on observe une tendance à s’installer plus loin : un trajet de plus d’une heure n’était pas considéré comme acceptable 5 jours par semaine, mais s’il ne faut le faire qu’une fois … et cela rallonge d’autant les déplacement hors-travail (activités, enfants, courses, etc.). Il faut aussi compter les éventuels matériels dupliqués (le double écran par exemple), le surcroît de chauffage au domicile, etc. Bref c’est complexe est le bilan peu être moins avantageux qu’on l’imagine. Sur le cas du télétravail l’Ademe a fait une étude suite au confinement et le résultat semble rester positif, mais ce n’est pas le cas de toutes les activités du numérique !
Globalement, il n’y a actuellement aucun consensus sur le fait que le numérique, dans son ensemble, ai un effet de décarbonation supérieur à ses émissions. C’est sûrement le cas pour des exemples précis et bien choisis, mais à l’échelle globale ça reste à voir.
Relis la page wikipedia, la phrase que tu cites s’applique à IPV6 et explique justement pourquoi 6LoWPAN a été créé (et propose justement un mécanisme de compression d’en tête)…
Le
06/03/2021 à
09h
10
piwi82 a dit:
En terme de protocole domotique, mettre “IPv6” et “low-power mesh networking” dans la même phrase me paraît osé (comparé à ZigBee par exemple).
Thread, c’est un réseau 6LoWPAN, la déclinaisons d’IPV6 spécifique pour les réseaux basse conso ( IPv6 LoW Power wireless Area Networks), sur la couche radio de Zigbee, avec un mécanisme de routage mesh spécifique. Donc pas de soucis sur l’aspect conso, c’est totalement pensé pour (et plutôt bien pensé !)
En revanche, 6LoWPAN ne garantit aucune interopérabilité de niveau applicatif entre les équipements : les API de couche applicative ne sont pas standardisées (ça pourrait être du CoAP, avec les API standardisées spécifiques, mais c’est par dessus Thread, ce n’est pas forcément le cas), contrairement aux profils zigbee. Et ça c’est dommage …
Quand le serveur tourne à 20% ou a 80%, la conso lié à cette charge évolue globalement linéairement (encore très discutable, cf. la première réponse de votre lien, mais en première approche c’est exact) avec la charge CPU. En revanche, la conso “idle” est toujours la même, quelle que soit la charge, et elle correspond approximativement à 50% de la conso totale du serveur ! Donc 4 serveurs à 20% ça fait ~500W et un serveur à 80% ça fait ~200W, pour le même travail rendu.
Donc non, la charge des serveurs n’est pas du tout sans importance !! Et ça ne ce voit pas du tout dans le PUE malheureusement. Tu peux avoir un PUE de 1.2 avec un DC rempli de serveur à 20%, et tu pourrais dans l’absolu baisser sa conso de moitié (en diminuant le nombre de serveurs, pour le même travail rendu) sans améliorer le PUE.
Le
21/10/2020 à
10h
48
Pas mal de bonne idées dans ces indicateurs, je trouve. Par contre, il est dommage qu’ils ne prennent pas en compte le taux d’utilisation des serveurs, parce qu’on a beau avoir des PUE & WUE excellents, si les serveurs du DC tournent à 20% de charge moyenne ça n’aide pas beaucoup (et ne n’est pas visible dans le PUE).
Bof, le github en question spécifie qui sert a : “prototype non-commercial smart home accessories” Bref, pour faire le moindre service ou objet vendu, ça ne fonctionne pas et il faudra passer par la case certif et le programme MFi. Ce n’est pas vraiment de l’ouverture je trouve.
Le
16/10/2020 à
14h
24
Oui, et la deuxième différence pour l’utilisateur lambda, c’est que le logo thread ne garantit aucune interopérabilité entre les objets qui le portent, alors que le logo thread si ( sur le même profile, en tout cas…). ça fait quand même une grosse différence !
Le
15/10/2020 à
06h
41
Petite précision : Thread utilise 6LoWPAN, sur les mêmes couches radio (PHY et MAC) que Zigbee (et donc le même hardware que lui) . La différence principale réside en l’endroit où est spécifiée l’interface protocolaire applicative, et donc une éventuelle compatibilité : dans zigbee c’est intégré : si une ampoule respecte le profile lightning zigbee (comme les Philips Hue par exemple) elle sera automatiquement compatible avec tous les appareils zigbee du même profile, quel que soit le fabricant. Avec Thread par contre, la partie haute est simplement de l’UPD (via 6LoWPAN) et c’est l’application au dessus qui définit la façon dont elle l’utilise ( potentiellement avec CoAP ou autre, par exemple) ; le résultat est que deux produit thread n’ont aucun garantie d’être compatibles au niveau applicatif même s’il peuvent parler entre eux au niveau IP.
En gros, thread est plutôt comparable à du Wifi (du transport jusqu’à une couche IP) là ou Zigbee est un protocole métier tout en un (du transport jusqu’à l’application).
Si je comprends bien (ce qui est loin d’être sur !) une municipalité peut utiliser une système LAPI pour sanctionner un défaut de paiement sur une place de parking autorisée et payante, mais n’a pas le droit de l’utiliser pour verbaliser un stationnement dangereux (une piste cyclable, une voie pompier, etc.) ?? Si c’est bien ça, j’ai franchement du mal à voir la cohérence et l’intérêt du cadre législatif actuel !
12 commentaires
Mesurer l’empreinte environnementale du numérique, un vrai casse-tête
14/03/2023
Le 15/03/2023 à 13h 01
A ma connaissance, ça n’est pas tout à fait comme ça que ça se passe (ni s’est passé) :
Le 15/03/2023 à 12h 50
Le calcul est malheureusement bien plus complexe que ça, on ne peut pas se contenter de compter le nombre de km de voiture évités par le télétravail. Il faut aussi compter les éventuels effets rebonds et émissions induites. Par exemple, avec la généralisation du travail on observe une tendance à s’installer plus loin : un trajet de plus d’une heure n’était pas considéré comme acceptable 5 jours par semaine, mais s’il ne faut le faire qu’une fois … et cela rallonge d’autant les déplacement hors-travail (activités, enfants, courses, etc.). Il faut aussi compter les éventuels matériels dupliqués (le double écran par exemple), le surcroît de chauffage au domicile, etc.
Bref c’est complexe est le bilan peu être moins avantageux qu’on l’imagine. Sur le cas du télétravail l’Ademe a fait une étude suite au confinement et le résultat semble rester positif, mais ce n’est pas le cas de toutes les activités du numérique !
Globalement, il n’y a actuellement aucun consensus sur le fait que le numérique, dans son ensemble, ai un effet de décarbonation supérieur à ses émissions. C’est sûrement le cas pour des exemples précis et bien choisis, mais à l’échelle globale ça reste à voir.
Un article intéressant sur le sujet : https://gauthierroussilhe.com/articles/comprendre-et-estimer-les-effets-indirects-de-la-numerisation
Concours GeForce RTX 3060 Ti : et le gagnant est…
27/09/2021
Le 16/09/2021 à 07h 39
bah, j’ai jamais eu de CG de ce niveau, pourquoi pas tenter !
Concours Next INpact de rentrée : qui sont les gagnants ?
13/09/2021
Le 06/09/2021 à 07h 26
Tiens, ça fait longtemps que je voulais tester ces petites clefs … ;)
Domotique : Orange rejoint la Zigbee Alliance, le Thread Group et mise sur CHIP
05/03/2021
Le 07/03/2021 à 07h 45
Relis la page wikipedia, la phrase que tu cites s’applique à IPV6 et explique justement pourquoi 6LoWPAN a été créé (et propose justement un mécanisme de compression d’en tête)…
Le 06/03/2021 à 09h 10
Thread, c’est un réseau 6LoWPAN, la déclinaisons d’IPV6 spécifique pour les réseaux basse conso ( IPv6 LoW Power wireless Area Networks), sur la couche radio de Zigbee, avec un mécanisme de routage mesh spécifique. Donc pas de soucis sur l’aspect conso, c’est totalement pensé pour (et plutôt bien pensé !)
En revanche, 6LoWPAN ne garantit aucune interopérabilité de niveau applicatif entre les équipements : les API de couche applicative ne sont pas standardisées (ça pourrait être du CoAP, avec les API standardisées spécifiques, mais c’est par dessus Thread, ce n’est pas forcément le cas), contrairement aux profils zigbee. Et ça c’est dommage …
Scaleway rDCE : un indicateur de consommation pondérée (eau et électricité) pour les datacenters
21/10/2020
Le 22/10/2020 à 08h 41
Quand le serveur tourne à 20% ou a 80%, la conso lié à cette charge évolue globalement linéairement (encore très discutable, cf. la première réponse de votre lien, mais en première approche c’est exact) avec la charge CPU.
En revanche, la conso “idle” est toujours la même, quelle que soit la charge, et elle correspond approximativement à 50% de la conso totale du serveur ! Donc 4 serveurs à 20% ça fait ~500W et un serveur à 80% ça fait ~200W, pour le même travail rendu.
Donc non, la charge des serveurs n’est pas du tout sans importance !! Et ça ne ce voit pas du tout dans le PUE malheureusement. Tu peux avoir un PUE de 1.2 avec un DC rempli de serveur à 20%, et tu pourrais dans l’absolu baisser sa conso de moitié (en diminuant le nombre de serveurs, pour le même travail rendu) sans améliorer le PUE.
Le 21/10/2020 à 10h 48
Pas mal de bonne idées dans ces indicateurs, je trouve.
Par contre, il est dommage qu’ils ne prennent pas en compte le taux d’utilisation des serveurs, parce qu’on a beau avoir des PUE & WUE excellents, si les serveurs du DC tournent à 20% de charge moyenne ça n’aide pas beaucoup (et ne n’est pas visible dans le PUE).
Domotique : HomePod mini est le premier appareil HomeKit Thread d’Apple
14/10/2020
Le 16/10/2020 à 14h 29
Bof, le github en question spécifie qui sert a : “prototype non-commercial smart home accessories”
Bref, pour faire le moindre service ou objet vendu, ça ne fonctionne pas et il faudra passer par la case certif et le programme MFi.
Ce n’est pas vraiment de l’ouverture je trouve.
Le 16/10/2020 à 14h 24
Oui, et la deuxième différence pour l’utilisateur lambda, c’est que le logo thread ne garantit aucune interopérabilité entre les objets qui le portent, alors que le logo thread si ( sur le même profile, en tout cas…). ça fait quand même une grosse différence !
Le 15/10/2020 à 06h 41
Petite précision : Thread utilise 6LoWPAN, sur les mêmes couches radio (PHY et MAC) que Zigbee (et donc le même hardware que lui) .
La différence principale réside en l’endroit où est spécifiée l’interface protocolaire applicative, et donc une éventuelle compatibilité : dans zigbee c’est intégré : si une ampoule respecte le profile lightning zigbee (comme les Philips Hue par exemple) elle sera automatiquement compatible avec tous les appareils zigbee du même profile, quel que soit le fabricant.
Avec Thread par contre, la partie haute est simplement de l’UPD (via 6LoWPAN) et c’est l’application au dessus qui définit la façon dont elle l’utilise ( potentiellement avec CoAP ou autre, par exemple) ; le résultat est que deux produit thread n’ont aucun garantie d’être compatibles au niveau applicatif même s’il peuvent parler entre eux au niveau IP.
En gros, thread est plutôt comparable à du Wifi (du transport jusqu’à une couche IP) là ou Zigbee est un protocole métier tout en un (du transport jusqu’à l’application).
Quatre communes épinglées par la CNIL pour verbalisation assistée par ordinateur illicite
26/08/2020
Le 26/08/2020 à 15h 21
Si je comprends bien (ce qui est loin d’être sur !) une municipalité peut utiliser une système LAPI pour sanctionner un défaut de paiement sur une place de parking autorisée et payante, mais n’a pas le droit de l’utiliser pour verbaliser un stationnement dangereux (une piste cyclable, une voie pompier, etc.) ??
Si c’est bien ça, j’ai franchement du mal à voir la cohérence et l’intérêt du cadre législatif actuel !