> The offset is practically 0 ranging within nanoseconds range.
Uhm, no, the graph clearly shows that the offset is varying between 0-2 microseconds, which is 0 - 2,000 nanoseconds.
2,000 nanoseconds is not "practically zero". PTP precision is supposed to be in the 10ns range.
Also, how did they get 40us precision on (what I assume to be) a normal kernel on a normal x86 box? I would have assumed that in a datacenter environment, with traffic levels being random, the jitter introduced in the kernel networking stack alone would be in the hundreds of microseconds at least.
Addenda: Intel networking chips, so even in AMD or ARM systems this actually works (assuming that you have the correct OS and drivers/modules/support software).
Also, this isn't exclusive to Intel: most modern (server) NICs at least support TCXO-based timings, and some built for precision uses OCXO for even better precision.
When most normal people talk about 2+2=4, they are referring to addition of natural numbers under the axioms of Peano arithmetic, where 2+2 indeed equals 4.
Sabine Hossenfelder's point is that if we abandon the Peano axioms then we can arrive at different results. For example, under the rules of modular arithmetic, 2+2 may not equal 4. Which is perfectly obvious. Of course if you define "+" to mean something different, then you get a different result. Why is that worth mentioning?
The purpose of language is for clear communication. In ordinary contexts, when someone uses the addition operator, everyone would understand that they're referring to integer addition under the Peano axioms and not modular addition or polynomial addition or something else. Engineering manuals do not need to preface all calculations with "Under the Peano axioms...".
When NASA engineers design a rocket, do they need to worry "what if 2+2 doesn't equal 4?"? Do we need to redesign all of our computer systems and rethink all of our scientific theories? If I'm writing a function which requires 2+2=4 to be always true, do I now need to write code to deal with the case where 2+2 does not equal 4? Of course not, but this is the most natural interpretation of the phrasing "2+2 doesn't always equal 4" which is the title of the video.
Of course it is just clickbait, but it seems to me that this kind of content only serves to confuse people and does not really help anyone. I don't want to use the word "sophistry" here but I can't think of a more appropriate word to describe this video.
I didn't read his comment as condescending. He said the world needs both engineers and plumbers. The world needs more plumbers than engineers, that doesn't mean that plumbers are useless.
Your example is not a good one because 1 month of practice would not be sufficient for most people to get into FAANG. See: the guy who grinded Leetcode for a year and failed to get into Google (though he did get into Amazon). If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise.
He classified his work as engineering and everything else as plumbing. That is condescending.
> If you only need to grind Leetcode for 1 month to get into FAANG, then that means you're already pretty good algorithms wise
That's the point. That person should be pretty damn familiar with LeetCode questions, yet they still had to grind for a month and they're scared of it.
> He classified his work as engineering and everything else as plumbing. That is condescending.
Most real world programming work kind of is plumbing though? We take data from over here and put it over there. We build pipes. And for good, sensible reasons, most of the pipes we make use standard fittings (REST, JSON, etc).
This is the whole point of this thread - you don't need to be good at leetcode questions to do this sort of work. I agree with that and I think we're all on the same page here.
Leetcode tests something else. That other thing is also a real skillset. I hear you that calling it engineering is condescending. But I still wish we had a good name for it..?
no... i’ve worked with a fair number of leet code all stars at startups and they are rarely capable programmers in a product development sense (taken in isolation). I would say the reason the plumber vs engineer analogy is condescending is the implication that non algo work operates with well defined problems and criteria and rarely requires any engineering. my experience has been the opposite. To solve problems effectively and pragmatically it requires understanding the system constraints in addition to the people constraints. Generally speaking even identifying the key problem and constraints is a relatively rare skill, much less selecting a solution that fits the people, budget, and timelines. I’ve since realized it’s that most software developers — algo skills or not — are simply not great engineers. Having accomplished anything rigorous like leet code helps (demonstrates diligence and effort), although it is still no substitute for a history of shipping working software and personally even if i’m tasked with interviewing a candidate using an algo whiteboard, i don’t do it.
