[jedberg]

I feel like they could get almost 100% uptime with a lot less effort if they just put a second server on the other side of the world.

The antipode of Barcelona (where this is based) is pretty close to New Zealand.

If they put a second server there and then used a anycast IP, chances are one of the servers would be up at all times with no battery at all.

Edit: Changed multicast to anycast because for some reason my computer wants to auto-correct it. :(

[kragen]

That is an excellent idea. With three or four servers they could entirely avoid batteries.

I think you mean anycast, not multicast, but a less exotic option would be to use DNS failover, or even just round-robin DNS with no explicit failover: https://webmasters.stackexchange.com/questions/10927/using-m... https://www.nber.org/sys-admin/dns-failover.html

[driverdan]

You wouldn't want to power directly from the panels without a battery. It would cause high instability on cloudy days, possibly leading to file system corruption.

[kragen]

The panel voltage is pretty stable until the illuminance gets really low (unless you're drawing a lot of current). Diodes such as solar cells are roughly constant-voltage devices. You can get a pretty long way avoiding filesystem corruption by mounting things read-only, but (I've heard) some SSDs aren't really read-only even when they're read-only, because of read disturb and the attempt to compensate for it in the FTL. 10 seconds of 2 W at 3–6 V is about two farads, so you might be able to get acceptable stability with a supercapacitor in the 1–10 farad range instead of a battery.

[lightedman]

"The panel voltage is pretty stable until the illuminance gets really low"

I'd like to see what panels those are, because the ones I've built while working as a PV manufacturing tech, both mono and poly (roughly 21% efficiency,) will have greatly varying voltages with even the tiniest hint of cloud cover over one cell, even with the junction box working to help separate out sections of the panel to maintain better voltages. Typical 60 cell 30-32V panel will drop to ~18-20 with just two cells on one 20-cell section of the panel covered. Sure this is still enough for the paltry voltage this specific server needs, but if they used smaller and more affordable panels like those used for cell phone chargers or similar size (within about 18"x18" form factor,) I can guarantee you those do not take to shading or even bad orientation well at all. 45 degrees off direct-exposure and you could be looking at that smaller panel producing a mere 2V or less.

[kragen]

Is that the MPPT voltage or the open-circuit voltage? I was thinking of a near-open-circuit voltage (which is what you have if you're powering a 2-watt webserver from a 50-watt solar panel), but MPPT will vary a lot more. Also, covering 6% of your cells will drop your voltage a lot more than covering all your cells 6%.

[lightedman]

Open circuit. This is one specific behavior we looked out for when testing panels before shipping, after the EL test, lamination, and junction box installation.

[driverdan]

That's a reasonable point. So long as the panel's output voltage is higher than the controller's minimum required input it would be stable.

I still wouldn't want to run a Pi directly off solar. I'd want enough warning to shut it down rather than killing the power.

[yjftsjthsd-h]

Could you use a (big) capacitor then? Enough to smooth power out, but AFAIK doesn't degrade like batteries.

[jedberg]

Yeah I meant anycast (fixed above). And it's true, the other options would work too, but there would be added latency.

[kragen]

With DNS failover there is only added latency during the time interval between when a server goes down, causing the DNS to get updated, and when the dead IP times out everywhere, which can easily be a few minutes. If the server can anticipate that it is going to go down it can remove itself, and then only people using shitty ISPs that don't respect the TTL will ever see extra latency.

[jedberg]

> and then only people using shitty ISPs that don't respect the TTL will ever see extra latency.

In my experience running large websites, that's about 10% of the internet, if not more.

When I made a DNS change, only about 70% of the traffic dropped off in the TTL. The rest took anywhere between a few hours and a few weeks (and some never dropped off, we had to just let them fail after a while).

[kragen]

Thanks, I didn't realize it was that large. :'(

Do you think the advent of DoH will improve that situation?

[jedberg]

I don't think so. DoH deals more with streamlining the transmission of requests and responses, but I don't recall any part of the RFC dealing with TTLs.

You'll still be talking to your local DNS server with its own caching rules.

[dragontamer]

For more local purposes, solar + wind is a nice complement. Wind is strongest at night, while solar is best in the day.

Nuclear usually needs to keep running, and fewer people use electricity at night (unless you live in Philippines where it is common to only run AC at night to save on electricity).

[tr352]

> Wind is strongest at night

This depends on where you are. In many places wind is actually strongest during daytime.

[lgats]

Depending on elevation, among other things. https://www.researchgate.net/figure/Comparison-of-the-diurna...

[EGreg]

Also, you can use a refrigerator at night... the cold IS the battery.

[falcolas]

That makes me wonder the viability of using a peltier as the pump/sink for a temperature differential battery.

[ozim]

Peltier eficiency sucks, so not really an option.

[jandrese]

Multicast doesn't work on the big-I Internet.

A battery system is almost certainly easier than physical servers spread across the globe, even when you account for the cost of the battery.

[jedberg]

I meant anycast (fixed now). But based on this writeup, they don't seem to care about how much of their own time it takes, only to prove it is possible. It was in that vain that I suggest two servers would be better.

[labawi]

I have feeling that internet infrastructure material and energy costs for a anycast IP/site would dwarf the energy/material costs of hosting the site in a datacentre.

[wtracy]

That assumes that each location receives enough sunlight to keep the server operational for at least twelve hours a day, which doesn't sound realistic for a setup with no batteries. Three servers spaced equidistant around the world might work.

If you're going down that route anyway, you could add redundant servers at different latitudes to hedge against cloudy weather.

[jedberg]

> That assumes that each location receives enough sunlight to keep the server operational for at least twelve hours a day

Only one of them needs to be up at a time. By choosing the antipode, by definition one of them will be in sun when the other is not (weather notwithstanding). The equinox would be the hardest day to deal with because they would both be at low energy at sunrise/sunset.

So yes, you're right, a third server would probably make it work almost 100% of the time.

[bacon_waffle]

I don't think the equinox is special in this regard - as the days at one point get longer, they shorten at the antipode.

As a practical matter insolation at dawn/dusk won't be able to power much, without a PV array that would be quite oversize during the day.

Lots of interesting optimisation problems in this area. But at this scale batteries and solar panels come in discrete sizes, so it's a bit academic.

[jedberg]

Ah, I see what you mean. If they are antipodes, then dusk and dawn will happen together every day. This is a good point. I was thinking there would be more overlap on the other days, but you're right, there wouldn't be.

[toast0]

Getting one anycast IP really means getting a /24, which is pretty expensive. I would definitely go with a DNS solution instead, even though some users are going to be stuck behind brain dead caches that don't follow the TTL at all. Like others, I have seen traffic continue for weeks after a DNS change.

[anonsivalley652]

Or twice as many panels and a battery.

Problem solved.