Re: [recipe] FYI: [admin-discuss] REMINDER: IETF carbon emission measurement workshops on 20 and 21 September

[Toerless Eckert <[e-mail]>]

On Mon, Sep 26, 2022 at 11:32:08AM -0700, Bruce Nordman wrote:
> I left out an important NOT above. My network equipment is on continuously
> - it doesn't sleep. I don't see entire network eqt. devices as plausibly
> going to sleep (at least in res/comm bldgs) though individual links can
> (e.g. 802.3az).

Unfortunately, that 802.1az feature was AFAIK never perpetuated to optical ethernet,
and i think also not 100G or faster. Not sure about 10G copper or the new lower bitrates.
One of the main issues is i think that the higher speed codecs require an even longer time
to resync. Which i think makes the 802.1az approach less and less useful (startup time).

I would hope that ieee would take a new look at this issue. Maybe with periodic/phase
driven on/off mode to overcome the need for continuous-on clocking signal. 

> The power levels of my network equipment probably go up
> with higher traffic levels, but I expect that the increment is quite small.
> Making up some #s here, if my network equipment uses 20W with no traffic
> and 20.5W on average when there is significant traffic, then I should
> allocate only the 0.5W as the marginal cost of its use in determining the
> impact of more or less traffic. The equipment will use the 20W even if
> there is no traffic (but since I have a (very) few IoT devices like my
> water heater, there is always some traffic).

I would hope/think that the lower the bitrate, the higher the margial cost, aka: a higher
percentage of energy can be saved when not transmitting traffic. But of course, depending
on codec/modulation the same long-term-sync issue may exist here too.

> This comes up when considering something like streaming a movie vs. mailing
> a DVD. There is an issue about long-run effects, e.g. if many people stream
> movies, will that induce increases in infrastructure capacity so that one
> can consider short-run marginal and long-run marginal. For automobiles, a
> lot of costs are fixed no matter if you drive a little or a lot, but when
> not having a car at all (I didn't for many years), then the fixed costs can
> come into play.

This is almost a universal infrastructure issue. Road, Rail, Water, Gas, Electricity,
Internet - what have you. And several of those infrastructures only woke up recently
to this problem wrt. charging for infra vs. payload. And the even bigger iss ue
that you can not simply say that trying to reduce the cost of infrastructure
is always best: because ultimately you want to minimize the cost of infra plus payload
for the exact payload profile that customer would want to ideally have if they
could afford it. Which you maybe not even be able to predict as long as pricing is different.

Cheers
    Toerless

> > I didn’t know about the factor 10, but considering the main finding of
> > this paper: ttps://onlinelibrary.wiley.com/doi/10.1111/jiec.12630  and
> > some other things I came across, including this often-cited paper which
> > makes *extreme* predictions (I have trouble believing them… but then
> > predictions are what they are … just guesswork, really):
> > https://www.mdpi.com/2078-1547/6/1/117   … I also got the impression that
> > the edge is where most of the gains can be achieved.
> >
> Given the past 20 years of history, the 'realistic' worst case for 2030
> does not seem realistic to me.
> >
> > It would be interesting to know the relationship in terms of energy usage
> > between hosts, WiFi APs, and cellular equipment. Is it really just hosts
> > where we should reduce energy usage?
> >
> We should work on them all, though should prioritize hosts since there are
> a lot more savings potential there. Network providers do have an incentive
> to pay attention to operational energy use (though that doesn't guarantee
> that all cost-effective efficiency measures are taken).  Owners of
> residential and commercial buildings are much less capable of optimizing
> their purchase and use patterns.
> 
> --Bruce
> 
> 
> -- 
> *Bruce Nordman*
> Lawrence Berkeley National Laboratory
> *nordman.lbl.gov <http://nordman.lbl.gov>*
> [e-mail]
> 510-486-7089; m: 510-501-7943

-- 
---
[e-mail]