Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
mlichvar
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
1.
▲
by
mlichvar
10mo ago
That's what the chrony tempcomp directive is for. But you would have to figure out the coefficients, it's not automatic. An advantage of constantly loading at least one core of the CPU might be preventing the deeper power states f
2.
▲
by
mlichvar
10mo ago
Current Debian, Ubuntu, Fedora, RHEL/CentOS (EPEL) have an ntpsec package, but no ntp package. It's not used by default (that's chrony on most of the distributions), but the users can install it and use it.
3.
▲
by
mlichvar
10mo ago
The major Linux distributions replaced ntp with ntpsec. A better question would be who is still running ntp. I know about FreeBSD and NetBSD. ntpsec as a project seems to be doing ok. They are releasing new versions, fix reported issues, ac
4.
▲
by
mlichvar
1y ago
I agree with most of what you said. The author has other posts in the series where he tried to measure the accuracy relative to the PHC (not system clock) using PPS: https://scottstuff.net/posts/2025/06/02
5.
▲
by
mlichvar
1y ago
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
6.
▲
by
mlichvar
1y ago
On Fedora it is setgid screen, not root.
7.
▲
by
mlichvar
2y ago
The Linux kernel keeps time as a 64-bit integer, but it's in nanoseconds, not seconds. It's a Y2262 problem.
8.
▲
by
mlichvar
2y ago
Another way to look at it is that MIT gives freedom to the developers and GPL gives freedom to the users. It's a conflict between the two groups.
9.
▲
by
mlichvar
3y ago
My current understanding of the wireless technologies wrt to home automation: - wifi is most reliable, secure, easiest to debug, but usable only for mains-powered devices due to higher energy consumption - bluetooth LE has lowest energy con
10.
▲
by
mlichvar
3y ago
To me that looks like they are reinventing NTP, but not addressing all the issues of PTP. A big problem with the PTP unicast mode is an almost infinite traffic amplification (useful for DDoS attacks). The server is basically a programmable
11.
▲
Comparison of Android ROMs
(eylenburg.github.io)
3 points
by
mlichvar
3y ago
|
0 comments
12.
▲
by
mlichvar
3y ago
Here is a nice animation of reflections I found useful: https://www.youtube.com/watch?v=ozeYaikI11g
13.
▲
by
mlichvar
3y ago
Fuzzing needs to cover all important bits of the code to be useful. The problem I see is that incomplete coverage creates a false sense of security. Projects have some minimal fuzzing coverage (e.g. in oss-fuzz) and care less about quality
14.
▲
by
mlichvar
3y ago
It's even less than that. Current OpenWrt versions work on devices with 8 MB of flash and 64 MB of RAM. OpenWrt 19.07 worked on 4MB/32MB devices.
15.
▲
by
mlichvar
3y ago
A better solution to secure bootstrapping of time would be NTP+NTS (RFC 8915) using self-signed certificates with unlimited time validity, which can be preloaded with the OS and updated via normal OS updates if the server key is compromised
16.
▲
by
mlichvar
3y ago
A major problem in synchronization of the system clock is PCIe. Hardware can timestamp PPS signal or PTP/NTP packets with accuracy of a few nanoseconds if everything is well compensated, but the PCIe bus between the CPU and the timesta
17.
▲
by
mlichvar
3y ago
When you are comparing performance to kitty, are they both scrolling line by line (xterm's default), or jumping as with the xterm jumpScroll or fastScroll option?
18.
▲
by
mlichvar
3y ago
> There's no networking hardware timestamp support for NTP because NTP has nothing to do with hardware timestamps. Both NTP and PTP don't care (as protocols) where the timestamps are coming from. That's an implementation d
19.
▲
by
mlichvar
3y ago
No, NTP and PTP are two different protocols. They can both use hardware timestamps and reach single-digit nanosecond accuracy in ideal conditions. The main difference is in existing support in switches and routers, which is needed to avoid
20.
▲
by
mlichvar
4y ago
The article missed an opportunity to describe how spectacularly can things break when the 32-bit time_t overflows in Y2038. If you still have such a machine (preferably without any valuable data), try setting the date right before the overf
21.
▲
by
mlichvar
4y ago
FWIW, from those 11 chrony CVEs: - 8 were found within the project itself (mostly by me) - none are memory-safety issues in the NTP-specific code - the last memory-safety issue is from 2015 and it was in the custom management protocol (expl
22.
▲
by
mlichvar
4y ago
One issue with TV displays I didn't see mentioned here is glossiness. TVs are mostly glossy and monitors are usually matte. I strongly prefer the latter.
23.
▲
by
mlichvar
4y ago
RFC 7808 specifies a TZDIST service. But most operating systems already have their own mechanism to update their timezone database. This is not a problem. Shifting timezones by 15 minutes every few thousand years would work with current sof
24.
▲
by
mlichvar
5y ago
Some models that are known to work well with chrony are Intel I210, I350, and X550. Those don't care about the protocol as they can provide hardware timestamps for all received packets. Other popular NICs like the Intel X540 or XXV
25.
▲
by
mlichvar
5y ago
The unicast PTP support can be limited to boundary clocks and the enterprise profile doesn't require transparent clocks to support the unicast mode. Also, there are different types of PTP transparent clocks. They can either be end-to-e
26.
▲
by
mlichvar
5y ago
Do the transparent clocks in your datacenter support unicast PTP? There is a possibility to use PTP as a transport for NTP to take advantage of PTP-specific hardware timestamping. It could also process the correction field, but it seems the
27.
▲
by
mlichvar
6y ago
That can work, but probably not very well. Without real-time resampling some buffer in the path will underrun or overrun depending on whether the recording soundcard is sampling slower or faster than the playback soundcard. The clocks are n
28.
▲
by
mlichvar
6y ago
Yes, NICs with support for hardware timestamping are common (it's typically in the MAC, not PHY), but switches that have a good support for PTP, either as a boundary clock, or transparent clock, are not cheap. At least I have not seen
29.
▲
by
mlichvar
6y ago
The main difference between PTP and NTP is that PTP relies on hardware support in switches and routers. Those are not cheap. If they had the same support for NTP, it would perform as well. A highly accurate stratum-1 NTP server can be build
30.
▲
by
mlichvar
6y ago
Do most TLS-based protocols and applications use session tickets? From the gnutls documentation it looks like it's something that needs to be supported in the code, on both servers and clients. Is a client that cannot resume a session
More ›