Also, it’s typically not that expensive to upgrade your panel, if you live in a zoned area. Buildings in the unzoned area typically have good electrical connections since in the countryside you typically want access to three phases.

As an example for moving from older single phase service to 3x25A, it costs around 810 € typically, with 2000-3000 € as a worst case scenario. That’s in Lahti, Finland – in Espoo it seems to be around 500 €

Of course there’s then the need to upgrade the panel as well, but that’s a relatively simple operation.

My childhood home had 3x90A breakers since it originally had a resistive heat setup, in a relatively large building (plus some other energy intensive equipment housed there). In reality it was far too much even then, the max load we calculated under full load was more like 25-30 kW.

Well, true. Fair enough

Ok, so the US-style GFCI-breakers are indeed a lot more expensive than similarly rated DIN-rail alternatives. TIL

one of us

1. Hadn’t considered that one TBH, no practical limits with actuations (rated in the thousands) but they’re probably not rated for that many trips under a fault condition – now I’m curious, will have to dig up a spec sheet at some point
2. Not really, unless you have equipment that’s poorly designed everything should be fine. It’s not much different from a brownout, and things should be configured to deal with that anyways if you don’t have a UPS
3. If there are a lot of reactive loads, then yes – e.g. electric motors, large capacitors. Those will have a large inrush when started again. Typically there isn’t that much reactive loading in a residential home though, and it should be covered by the latency designed into the breaker.

The first point is actually a really good one, and one I didn’t really remember to consider. I’d guess it has at least something to do with that (and would explain why many homes around here are still configured with traditional fuses for the main connection – no need to worry about lifetime when you have to replace them anyways)

Not talking about the circuits, but the main electrical connection to the grid. To me it often seems like there’s reluctance in overcommitting overprovisioning that capacity: as an example, four 16A circuits on a 25A main breaker. Here that’s quite common, but even in Tech connections videos I’ve seen him bring up smart electric cabinets or automatic load monitoring when putting enough capacity on the mains to possibly go over.

What I’m asking is, why bother? If you trip the mains by having too much load, just reset the breaker and be done with it. No need to automate things to not run into that situation, one will learn to not have the oven on while charging the car full blast. No need to gimp the charger amperage since you’re running a new circuit anyway, and it’s not like it’s much different running a 20A circuit vs a 40A one. If that’s 70% of your total available capacity, it doesn’t matter – worst you have to do is walk downstairs and flip a switch.

I might’ve been unclear, I don’t mean 230 V by itself, but three-phase distribution. The standard socket is labeled either 3x16A 230V alternatively labeled 380V 16A. Typically uses an IEC 60309 plug that looks like this:

(Source: https://www.plugsocketmuseum.nl/IEC60309_2.html)

Three phase has other benefits besides just more power, the US has it with their lower voltage as well, but typically reserved just for larger buildings.

Are they somehow more expensive in the US? 40A 230V rated ones cost something like 30-50 € around here which doesn’t feel that expensive to me. I’ll admit it’s considerably more expensive (~4x the price) than a standard breaker, but it’s still more like a rounding error in overall costs.

Although EVSE’s projection doesn’t require you to periodically trip the GFCI so it doesn’t get stuck, which is a major plus.

One thing I really don’t get in the discussion around EVs and charging is, why are people so afraid of tripping the main breaker? If you have a total of e.g. 17 kW available and happen to go over, just reset the main breaker (or replace it in case it’s still a traditional one). It’s there precisely so that you wouldn’t need to care about overloading the connection.

In my experience people get by with a 3x25A (17 kW available, matches approximately a 70A service in the US) while using the available power to

• heat/cool a single family home (in -20 °C weather mind you)
• run all appliances (including the oven, stove, dryer etc.)
• heat up a sauna
• charge an EV
• whatever else you typically would want to plug in, kettles and such

While it’s true you can trip the main breaker if you have everything on at the same time, typically it never happens even if there are no lockouts in place preventing overuse. And it’s not like tripping it causes any permanent harm.

Why is an electrical service upgrade constantly brought up as a solution when any home with >15 kW of available power won’t need it? Is it against code to purposefully overcommit your mains in the US or something?

Edit: there were valid concerns raised over how long-lived the breakers are (probably won’t be rated for tens of fault-condition related trips), also that these smaller service specs aren’t as common as I’ve gathered from the media. That might have something to do with this at least. Thanks for the replies – it’s been an interesting discussion.

Yep – US also doesn’t generally do residential three-phase unlike many countries in the EU. A lot of garages around here have 3x16A 230V, not (only) due to the power requirements but because having three phases allows for simplest induction motors for things like blowers and circular saws. When you have three phases having a proper outlet in the garage starts making sense.

Around here (Finland more specifically) we have three-phase even in most apartments. My two bedroom apartment has a 3x25A main breaker, and two devices on 3x16A circuit’s – the sauna stove and oven+stovetop. Most single-family homes have 3x25A or 3x36A as well.

US households are missing out on a lot of things due to their split-phase system.

Yep, precisely.

It’s also quite literally one of the recommended methods of installation for e.g. UHB, for which there’s even a pre-made script in the repo.

Edit: Also, Chromium devs are aware of this use case and have even added optimizations for it in the past, as visible in the highlighted comment. And the max hosts file size defaults to 32 MiB which is well over the size I’m using (24 MiB). Makes it even weirder for it to bog down completely when experimenting with a ~250 MiB hosts file, as it should just reject it outright according to implementation.

Don’t seem to be any disk reads on request at a glance, though that might just be due to read caching on OS level. There’s a spike on first page refresh/load after dropping the read cache, so that could indicate reading the file in every time there’s a fresh page load. Would have to open the browser with call tracing to be sure, which I’ll probably try out later today.

For my other devices I use unbound hosted on the router, so this is the first time encountering said issue for me as well.

You’re using software to do something it wasn’t designed to do

As such, Chrome isn’t exactly following the best practices either – if you want to reinvent the wheel at least improve upon the original instead of making it run worse. True, it’s not the intended method of use, but resource-wise it shouldn’t cause issues – at this point one would’ve needed active work to make it run this poorly.

Why would you even think to do something like this?

As I said, due to company VPN enforcing their own DNS for intranet resources etc. Technically I could override it with a single rule in configuration, but this would also technically be a breach of guidelines as opposed to the more moderate rules-lawyery approach I attempt here.

If it was up to me the employer should just add some blocklist to their own forwarder for the benefit of everyone working there…

But guess I’ll settle for local dnsmasq on the laptop for now. Thanks for the discussion 👌🏼

TLDR: looks like you’re right, although Chrome shouldn’t be struggling with that amount of hosts to chug through. This ended up being an interesting rabbit hole.

My home network already uses unbound with proper blocklist configured, but I can’t use the same setup directly with my work computer as the VPN sets it’s own DNS. I can only override this with a local resolver on the work laptop, and I’d really like to get by with just systemd-resolved instead of having to add dnsmasq or similar for this. None of the other tools I use struggle with this setup, as they use the system IP stack.

Might well be that chromium has a bit more sophisticated a network stack (than just using the system provided libraries), and I remember the docs indicating something about that being the case. In any way, it’s not like the code is (or should be) paging through the whole file every time there’s a query – either it forwards it to another resolver, or does it locally, but in any case there will be a cache. That cache will then end up being those queried domains in order of access, after which having a long /etc/hosts won’t matter. Worst case scenario after paging in the hosts file initially is 3-5 ms (per query) for comparing through the 100k-700k lines before hitting a wall, and that only needs to happen once regardless of where the actual resolving takes place. At a glance chrome net stack should cache queries into the hosts file as well. So at the very least it doesn’t really make sense for it to struggle for 5-10 seconds on every consecutive refresh of the page with a warm DNS cache in memory…

…or that’s how it should happen. Your comment inspired me to test it a bit more, and lo: after trying out a hosts file with 10 000 000 bogus entries chrome was brought completely to it’s knees. However, that amount of string comparisons is absolutely nothing in practice – Python with its measly linked lists and slow interpreter manages comparing against every row in 300 ms, a crude C implementation manages it in 23 ms (approx. 2 ms with 1 million rows, both a lot more than what I have appended to the hosts file). So the file being long should have nothing to do with it unless there’s something very wrong with the implementation. Comparing against /etc/hosts should be cheap as it doesn’t support wildcard entires – as such the comparisons are just simple 1:1 check against first matching row. I’ll continue investigating and see if there’s a quick change to be made in how the hosts are read in. Fixing this shouldn’t cause any issues for other use cases from what I see.

For reference, if you want to check the performance for 10 million comparisons on your own hardware:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>


int main(void) {
	struct timeval start_t;
	struct timeval end_t;

	char **strs = malloc(sizeof(char *) * 10000000);
	for (int i = 0; i < 10000000; i++) {
		char *urlbuf = malloc(sizeof(char) * 50);
		sprintf(urlbuf, "%d.bogus.local", i);
		strs[i] = urlbuf;
	}

	printf("Checking comparisons through array of 10M strings.\n");
	gettimeofday(&start_t, NULL);

	for (int i = 0; i < 10000000; i++) {
		strcmp(strs[i], "test.url.local");
	}

	gettimeofday(&end_t, NULL);

	long duration = (end_t.tv_usec - start_t.tv_usec) / 1000;
	printf("Spent %ld ms on the operation.\n", duration);

	for (int i = 0; i < 10000000; i++) {
		free(strs[i]);
	}
	free(strs);
}

Thanks for the suggestion – I’ll have to give a try to the ungoogled version.