Hacker News Reader

Comment by falcolas | Hacker News Reader

How much concern would non-standard architecture support matter for ntp? Given how many architectures Linux supports, I would think that C would still be the best choice, until these other languages gain support for those missing architectures.

Or perhaps it's a good opportunity for a language which offers transpilation with ANSI C as the target?

View on HN

In addition to squiguy7's point, I'd add that A: it may not be clear if this is your only contact with ntpsec.org [1], but this is actually a fork of the classic ntp, so they may be more willing to abandon some older architectures to produce a more secure product going forward than the core NTP project would and B: the older versions will still be around even so.

Also, it has been suggested by some experiences that older architectures often end up getting supported past when they really should be stopped out of sheer inertia, though I'm not having luck digging up the articles that prompt me to say this. Are there that many systems out there running ntp that can't run Go and/or Rust, and if there are, are there enough to be worth bending the project around? If the people running those things care, perhaps they should fork the project and maintain it themselves. Which is less harsh than it may sound, because they can still pull from upstream, and they probably just need to tread water rather than stay up with the latest & greatest.

(I should emphasize that the operative question is are there enough to be worth bending the project around, rather than whether there are any. Because there certainly are non-zero numbers of systems running ntpd that can't run Rust or Go. But who's going to pay to maintain them? Especially if classic ntp is still available?)

[1]: https://www.ntpsec.org/

Well, it's not just older architectures which are not currently supported, it's architectures used in IOT devices, mainframes, and other non-commodity hardware. Specific to LLVM based languages, if it's not a priority to Apple (or the other big LLVM players), it infrequently gets done.

Specific to IOT devices, I would personally love to see secure everyting. NTP, TLS, SSH, etc.

There is a lot of community interest in Rust with regards to running on embedded devices, so I wouldn't be so quick to point to IOT devices as a reason for not using Rust. That said, I don't know what the current state of support for these less popular architectures is. The official page for platform support is https://forge.rust-lang.org/platform-support.html.

LLVM's biggest weakness right now is micro controller support like PIC/AVR. But its getting better: http://lists.llvm.org/pipermail/llvm-dev/2016-November/10717...

That should hit most of the chips most people would care about. I presume rust would gain from the upstream LLVM support?

Yeah it should. AIUI Rust uses a fork of LLVM, but they should be regularly pulling in upstream changes (but I don't know how often this happens) as well as submitting their own changes back upstream.

We do, in both directions.

Is there a technical or political issue preventing Rust from using upstream LLVM? Either way, is there a possible resolution on the horizon?

Nope. You can use a stock LLVM if you want. Some tests might fail, since patches might not be in upstream yet.

It's not really something to resolve; it's just the usual situation with a big dependency.

I expect that most of these older devices don't receive much in the way of software updates anyway, so the point is moot. For things that do receive updates, I would much rather see a secure NTP implementation that the majority of the world can use, even if a few parts of the long tail get excluded... and they still have the old versions of the C-based NTPsec they can use; I would also expect there to be a niche market arising for releasing security updates to it after the transition.

(Specifically addressing IoT devices, IoT security is so abysmal in general that there are much easier ways to compromise one than targeting its NTP daemon, if it's even running one, and if it's even "bothering" to run a secure one like NTPsec.)

Dropping support for things is certainly not a decision you make lightly, but sometimes the greater good demands it.

If it's a business requirement, they should hire engineers and contribute. Expecting free support seems unreasonable. There's a high cost for supporting and maintaining features, so somebody ends up having to pay for it.

To be fair, I imagine most of those arch manufacturers simply think "embedded developers use C, we support C, job done."

LLVM support would benefit the developers more, but they have their own budgets and constraints, which are probably not conducive to submitting and maintaining a LLVM plugin.

We are getting some piece of it with companies that still sell safe system programming languages (e.g. MikroElektronika, Astrobe), expose mostly via Java or its variants (e.g. Oracle, Aicas, Aonix, IBM, IS2T, Google), .NET (Microsoft).

I'm never quite sure where MIPS and SPARC are in terms of llvm support. (And does llvm support automatically mean rust support?)

No, LLVM support does not automatically mean Rust support, though it's a prerequisite for it. There are several small things which have to be defined in the Rust compiler. For instance, which registers are used for stack unwinding, and other ABI details.

LLVM is generally usable on sparc, although a significant amount of optimisation work still needs to be done, and there are some specific variants/platforms that sparc is used by that need better support.

Is it likely that work will ever be done? Oracle is, well, Oracle, and Fujitsu used ARM instead of SPARC for their new supercomputer.

Rust has impressive support for different architectures. I ran `rustc --print target-list` and it returned 63.

That includes one line per architecture / platform (i.e. OS) combination. I only count about 14 architectures, though my rustc is old (GCC has 23 major, 24 minor, and 30 legacy as a point of comparison).

Last I checked, some of the popular IOT architectures (atmega, etc) were not included without some 3rd party plugins.

FWIW, with latest rustc:

    $ rustc --print target-list | cut -d- -f1 | sort | uniq | wc -l
    20

ATmega is not really a popular architecture any more. It only stuck around because of Arduino, and even that is moving towards ARM.

Nobody is going to be running NTPsec on it in any case!

What arduino-class (that is, low power microcontrollers) devices are moving towards ARM? Seems like a very different use case from portable computers (like the Raspberry Pi) - the power consumption differences are pretty major.

> Nobody is going to be running NTPsec on it

Never say never. :) There are wifi, ethernet, and clock shields for Arduino, all of which are running microcontrollers, and many applications which would benefit from using NTP.

Microcontrollers aren't moving towards application level processors like the Raspberry Pi uses, they're moving towards low power ARM cores like the Cortex M0/M3/M4.

It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature. Current generation ARM Cortex M0 devices are available at a similar cost and with significant performance gains, with the benefit that if you realise you need a more powerful core you can scale up to hundreds of MHz with effectively the same code base.

I dunno of many Cortex M0+ devices that can source/sink 40mA like an AVR while only sipping 200uA (microAmps) like the AtMega328pb. That's active mode btw, AtMega328pb drops down to 1.3 uA in sleep mode.

Cortex M0+ devices are "larger" than AVRs. You have more RAM, CPU power and unfortunately... complexity and power usage.

I'm thinking a good example is the LPC811 from NXP: very good specs and it really shows how good ARM M0+ systems have become: http://www.nxp.com/documents/data_sheet/LPC81XM.pdf

But its still got an order of magnitude more power usage and complexity over AVR's AtMega328pb. The ATMega's "active" mode is comparable to the LPC811's "sleep" mode.

Most of the LPC811's pins only can sink / source ~4mA, while the "biggest" pins can only sink / source 20mA. In contrast, all of the AtMega328pb pins can sink/source 40mA. Easily driving LEDs with only a resistor (instead of having to hook up a transistor or external buffer of some kind)

The LPC811 also shows what happens to cheap ARM chips: they are missing ADC converters, PWM, Real-time Counters (or a deep-sleep mode that still keeps the 32kHz clock active). Sure, you can buy these externally... but the AVRs and PICs have superior integration.

> It's not clear to me why you'd choose an AVR for a new product unless you really, really needed a specific feature.

Running an LED with just a resistor on any pin is a pretty nifty feature IMO.

------------

The AtMega328pb is a "bigger" and more expensive part though. Perhaps its more "fair" to compare the LPC811 against the AtTiny44A (which is also $1.50ish). ATTiny44A has similar power specifications as the 328pb.

I'd love to read more about this microcontroller migration towards ARM - any hints on where to look?

I don't have a single source about this. But some hints are: 10 years ago every µC manufacturer had it's own core and instruction set and basically sold them exclusively (maybe apart from some 8051 stuff). They were AVRs, PICs, V850, PPC, etc. Now when you look that the portfolio of those manufacturers they nearly all have at least one product with an ARM core in their portfolio. Some might even already stopped releasing new chips with their proprietary cores. Others have done that not yet but are planning to do this in the future (I've heard of at least one).

Another hint is when you actually get in touch with a lot of complete product designs. The amount of ARM cores that you will see in there seems steadily to incline.

I dunno if its a 'major' migration, but NXP is basically doubling down on ARM-only architectures.

Microchip / Atmel (same company now btw) are doing an "everything and anything" strategy. PIC, ATTiny, ATMega, UC3, AND ARM chips are available from them.

It seems like the smaller 8-bit microcontrollers use less power and have better features for embedded engineers (ie: ADC converters, PWM, Real-time clocks, deeper sleep modes).

While ARM has the general benefit of being much faster from a computational perspective. But if you want to read the voltage from a simple thermo-resistor and then output it on an I2C bus... I'm thinking a classic 8-bit AVR is going to be superior over any ARM.

--------

I'm still seeing 8051 stuff pop up everywhere, and that thing was supposedly dead years ago.

> Never say never. :) There are wifi, ethernet, and clock shields for Arduino, all of which are running microcontrollers, and many applications which would benefit from using NTP.

FYI: Microcontrollers really ought to just be interpreting the WWVB radio signal (aka: the 60,000 Hz Atomic Clock radio signal throughout the entire continental USA). Alternatively, Microcontrollers easily connect up to GPS modules for an alternative radio signal / alternative time source.

If anything, Microcontrollers are a great interface to the 60kHz Atomic Clock signal and are therefore would probably be the best NTP-server.

In any case, the "real" best architecture is probably a microcontroller doing Radio Logic / digital signal processing for WWVB, and that is connected through a simple connection (ex: I2C that says the last announced time from the WWVB signal) helping a "bigger" Raspberry Pi. And the Raspberry Pi can handle the ethernet / server stuff

> What arduino-class (that is, low power microcontrollers) devices are moving towards ARM?

Erm, like, all of them? ARM has a 24% market share in microcontrollers, and 70% in 32-bit microcontrollers.

Source (page 21): https://www.arm.com/zh/files/event/1_2015_ARM_Embedded_Semin...

Here are a ton of Arduino-style boards with ARM chips: https://developer.mbed.org/platforms/

>> though my rustc is old

I just counted on nightly and got 20 distinct architectures, including all the le variants; every distinct architecture value, iow.

Reply on news.ycombinator.com