News for hackers. Stuff that matters.
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by pwmtr on Wednesday February 19, 2025 @08:10AM (#43101737)
Author of the blog post here.

Yeah, this is generally a good practice. The silver lining is that our suffering helped uncover the underlying issue faster. :)

This isn’t part of the blog post, but we also considered getting the servers and keeping them idle, without actual customer workload, for about a month in the future. This would be more expensive, but it could help identify potential issues without impacting our users. In our case, the crashes started three weeks after we deployed our first AX162 server, so we need at least a month (or maybe even longer) as a buffer period.

Re:Debugging Hetzner: Uncovering failures with powerstat, se... by ThePowerOfFuet on Wednesday February 19, 2025 @08:16AM (#43101797)
>The silver lining is that our suffering helped uncover the underlying issue faster.

Did you actually uncover the true root cause? Or did they finally uncap the power consumption without telling you, just as they neither confirmed nor denied having limited it?

Re:Debugging Hetzner: Uncovering failures with powerstat, se... by pwmtr on Wednesday February 19, 2025 @08:28AM (#43101918)
The root cause was a problem with the motherboard, though the exact issue remains unknown to us. I suspect that a component on the motherboard may have been vulnerable to power limitations or fluctuations and that the newer-generation motherboards included additional protection against this. However, this is purely my speculation.

I don't believe they simply lifted a power cap (if there was one in the first place). I genuinely think the fix came after the motherboard replacements. We had 2 batches of motherboard replacements and after that, the issue disappeared.

If someone from Hetzner is here, maybe they can give extra information.

Re:Debugging Hetzner: Uncovering failures with powerstat, se... by oz3d on Wednesday February 19, 2025 @08:40AM (#43102027)
hetzner is currently replacing motherboards of their dedicated servers [1] But I dont know if thats the same issue that was mentioned in the article.

[1] https://status.hetzner.com/incident/7fae9cca-b38c-4154-8a27-...

Re:Debugging Hetzner: Uncovering failures with powerstat, se... by ubanholzer on Wednesday February 19, 2025 @08:54AM (#43102177)
Thats the same issue, yes.
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by axus on Wednesday February 19, 2025 @08:41AM (#43102034)
Customers are the best QA. And they pay you too, instead of the reverse!
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by rat9988 on Wednesday February 19, 2025 @10:45AM (#43103317)
I'm pretty sure they pay for QA. QA cannot always catch every possible bug.
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by knowitnone on Wednesday February 19, 2025 @11:30AM (#43103998)
these crashes should have been caught easily
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by crishoj on Wednesday February 19, 2025 @06:06PM (#43108921)
Were you able to identify the manufacturer and model/revision of the failing motherboards? This would be extremely helpful when shopping for seconds hand servers.
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by babuskov on Thursday February 20, 2025 @04:06AM (#43112633)
I cannot find the link now, but it was mentioned that it was ASRock mobos.
Re:Debugging Hetzner: Uncovering failures with powerstat, se... by crishoj on Thursday February 20, 2025 @01:32PM (#43118312)
Thanks. This comment above does mention ASRock: https://news.ycombinator.com/item?id=43112594

On the other hand, dmidecode output in the article shows:

Manufacturer: Dell Inc. Product Name: 0H3K7P