Hacker Newsnew | past | comments | ask | show | jobs | submit | diarmuidc's commentslogin

>After several weeks, between 2 and 3, the indexing process finished without failures. ... we could finally shut down the virtual machine. The cost was 184 euros on Hetzner, not cheap.

184euro is loose change after spending 3 man weeks working on the process!


That's the budget I'd have for the coffee shop with the team to discuss budget

That's the budget to discuss and approve the above coffee shop budget

This one is, oddly enough, higher

Pffft, that's the budget for the paperclips to hold the meeting notes together

You guys have budgets?

Wow, you still need to even ask questions.

184 Euro is about a day's wages for a software developer over there (40k EUR / 220 working days).

Why is there no mention of PTP here? If you want accurate time synchronisation in a network just use the correct tool, https://en.wikipedia.org/wiki/Precision_Time_Protocol

Linux PTP (https://linuxptp.sourceforge.net/) and hardware timestamping in the network card will get you in the sub 100ns range


Chrony over NTP is capable of incredible accuracy, as shown in the post. Most users who think they need PTP actually just need Chrony and high quality NICs.

Chrony is also much better software than any of the PTP daemons I tested a few years ago (for an onboard autonomous vehicle system).


NTP fundamentally cannot reach the same accuracy as PTP because Ethernet switches introduce jitter due to queueing delays and can report that in PTP but not NTP.


Chrony can do NTP encapsulated inside PTP packets so as to combine the best parts of both protocols


That's not exactly NTP though ;)

I'll also say PTP is superior since it syncs TAI rather than NTP's UTC. Which probably isn't going to change even with NTPv5.


chrony can be configured to encapsulate NTP messages in PTP messages (NTP over PTP) in order to get the delay corrections from switches working as one-step PTP transparent clocks. The current NTPv5 draft specifies an NTP-specific correction field, which switches could support in future if there was a demand for it.

The switches could also implement a proper HW-timestamping NTP server and client to provide an equivalent to a PTP boundary clock.

PTP was based on a broadcast/multicast model to reduce the message rate in order to simplify and reduce the cost of HW support. But that is no longer a concern with modern HW that can timestamp packets at very high rates, so the simpler unicast protocols like NTP and client-server PTP (CSPTP) currently developed by IEEE might be preferable to classic PTP for better security and other advantages.


With retail hardware, definitely, but there is boundary PTP support with enterprise gear.

For telco gear, there is PTP + SyncE.


Some NICs support hardware timestamping (though some only for PTP packets, looking at you, XL710).


Correct me if I am wrong, but wouldn't that be true only for testing accross comparable hardware? Would that be true in scenarios like the one that the author describes, where he uses 3 different systems (threadriper cpu, raspberrypi, and LeoNTP GPS-backed NTP server) and architectures?


On our GCP cloud VMs, cloud-init installs chrony and uninstalls ntp automatically.


You're probably looking for https://scottstuff.net/posts/2025/06/10/timing-conclusions/ which discusses the overall conclusions of NTP vs PTP and is the culmination of several blog posts on the topic.


PTP is discussed in the concluding article of the series: https://scottstuff.net/posts/2025/06/10/timing-conclusions/


The blog's next post is about PTP, if that's what you're interested in.

The Linux PTP stack is great for the price, but as an open source project it's hamstrung by the fact the PTP standard (IEEE1588) is paywalled; and the fact it doesn't work on wifi or usb-ethernet converters (meaning it also doesn't work on laptop docking stations or raspberry pi 3 and earlier)

This limits people developing/using for fun. And it's the people using it for fun who actually write all the documentation, the 'serious users' at high frequency trading firms and cell phone networks aren't blogging about their exploits.


> it doesn't work on wifi

802.1AS-2020 (gPTP) includes 802.11-2016 (wifi) support.

The IEEE's gatekeeping is indeed odious.

The biggest limitation is that many ethernet MACs do not support hardware timestamping. Nor do many entry-level ethernet switches.

For what it's worth, I'm interested in TSN for fun (music, actually), and I'm prepared to buy compatible networking hardware to do it. No difference to gamers spending money on a GPU.


Most new MACs do it, (cheap) switches are still a problem though.


There's a discussion on that in the comments at the bottom of the article, where the author explains why it wasn't analyzed.


A clear ad hominem


The talk was from 2010


And the point about Australian grain exports was as untrue in 2010 as it was in 2000 and today - see the peer linked Australian Agriculture dashboard for grain eports by volume.


Yeah there is a solution. Build more housing. It's a political issue and nothing more


Of course it's a political issue. Policies on housing ownership have pushed housing as an investment to normal people for decades, as something that will, almost certainly, go up in value. Many, many people have bought a house they might not even be very happy with just for the sake of parking their money in a "safe investment" that they can live inside in the meantime, until they can sell and purchase the next one, rinse and repeat.

If you want to crash prices by building more housing then you'll have a lot of angry common people who are paying a lot for their mortgages which will go under water, of course these people will push as much as possible, politically speaking, for that to not happen.

Personally I'd be extremely happy if more housing is built and housing prices are pushed down but we can't deny that the reality of policies that took us here, those policies were wrong, housing should have never been part of a speculative market and been traded as another kind of commodity. It's not a commodity, it's not a pure asset, it's shelter for humans, economical policies thought by and implemented by ideologues pushed down our throats that housing is just like any other tradable asset... And now we have a lot of people that would never want to see prices go down because they will lose their life savings.

So yes, how can this not be political? Saying that it's a "political issue and nothing more" is like denying the reality that it is political, there's no other way. You can't remove the political aspect of this issue, there's no "just build more housing" without the parties/politicians that implement it being absolutely hated by a segment of society. Would you still vote for a party that enacts policies that make your life investments lose 50% of value? In a democracy most things are political, that's the hard part of the solution for most social issues...


Ya turn the country into one massive council estate. Brilliant. I'd rather live on a boat


We're far away from any country becoming a housing estate.


dry Irish humour ;)



No. That's not what the "British" mean.


There are SOCs available with the DRAM on top already. eg https://www.microchip.com/en-us/products/microcontrollers-an...


Basically every smartphone ARM SoC for over 10 years now.

Some Raspberry PI SoCs also had the RAM soldered on top.


That's 2 weeks time


lol :)


I suspect people don't like comparing with the Netherlands because it doesn't support their biases in this argument


It's more that the Netherlands is a substantial outlier in terms of how they accommodate cyclists, so applying their attitudes towards helmets without also being as cyclist-friendly (infrastructurally and socially) as they are is asking for trouble.


So all drivers should be required to wear a helmet? If not, why not ?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: