I look forward to your review of my code.
2,337 karma · joined June 15, 2010
I can change how their computers synchronize time.
But obviously: if I had throught it was just the thing, I wouldn't have started writing Ntimed.
I also don't expect Ntimed to out-compete Chrony, and if it did, I'd have to start a fourth alternative myself, to keep competition healty.
A very large part of NTPDs problem was that there were no competition, which meant that everything got crammed into NTPD, come hell or 300KLOC.
We saw this also with GCC, which had become a stagnated arrogant monopoly, and suddenly LLVM forced them to care about users again.
Having competing projects is good thing, and I hope Chrony sees things that way too.
Second, have you checked the memory footprint of NTPD ? "machine resources" is more than CPU cycles.
And don't forget: That number was one quarters purchase of servers, running for half a year. All the servers bought in 2010, 2011, 2012, 2013 and the other half of the year were not included.
Things add up.
About 2 million servers were sold world-wide in 2014Q2
Assume 25% runs UNIX and NTPD -> half a million servers
Assume NTPD uses 0.1% of machine resources -> 500 fully loaded servers.
Assume 100W/server -> 50 kW
50kW for half a year -> 220,000 kWh
Assume 500g CO2/kWh -> 110 tons of CO2
QED: I think CPU overhead is a very relevant concern for time synching programs.
This is more a matter of "the right language for the job" and for timing-critical systems programming running as root, that language is C.
And there are plenty of common abstractions I would love see added to the C language: basic linked lists, byte-endianess and packing for struct members, validity intervals for integers and FP variables (like Ada!)
Unfortunately my taste seems to be the direct opposite of ISO-C which have instead wasted time giving us another thread-API.
2. Because this is exactly the kind of task C was intended for: systems programming.
3. Because I want this to be a light-weight and portable program.
4. Because I have 30+ years of C-experience and happen to like the language.
Second, the 100.000 is my guesstimate of what is necessary for "core functionality" and I think that is still a pretty staggering size for what that "core functionality" is.
There is a lot of ancient infrastructure which complicates otherwise very simple tasks, some design-choices, perfectly valid in 1980 should have been revisited no later than 2000, far too much duplicated functionality, because people didn't know or couldn't get the other copy working etc.
My initial plan was to do a serious rebuild of the existing code, in deference to Prof. Dave Mills and NTPDs long legacy (probably one the longest running open source projects!), but in the end I had to admit that such a strategy would be inefficient on any relevant metric.
I think I could write a bare-bone NTP client in well less than 1000 lines, but it wouldn't be very user-friendly, net-friendly or clock-friendly.
Usability in particular soaks up space, but we're not in 1980 any more, so there is no excuse for stuff like this any more:
#define DEFPROPDELAY 0x00624dd3 /* 0.0015 seconds, 1.5 ms */
critter phk> ./ntimed-client -p pll_std_capture_time
Parameter:
pll_std_capture_time
Minimum:
2.000e+01
Maximum:
1.000e+06
Default:
3.000e+02
Description:
Capture time before stiffning PLL.
After this many seconds, the PLL will start to stiffen the P
and I terms to gain noise immunity. Decreasing risks that
initial frequency capture is not finished, which will increase
the offset-excursion. Increasing just delays this stiffning.
Failure: Stopping after parameter query.
... and that will still be less than 3% of the current NTPD.
I've already written about most of this in my little "time-blog" related to this project: http://phk.freebsd.dk/time/index.html
Feel free to ask any questions not already answered there.
Right now ntimed is less than 4KLOC and while it isn't complete yet, it does contain precision timekeeping, a data collector to record simulation input, a simulator to chew on those tracefiles and the real-time clock-steering code.
It really isn't rocket size.
OpenBSD's NTP implementation is similar size, but they sort of threw their hands op on smart clock-steering, opting instead for "KISS" from a security point of view.
The main reason I didn't start from OpenBSD's NTP implementation is that it is not aimed at being part of a larger family of time-keeping programs, like I intend to deliver, so it wouldn't save me any time in the end.
(I'll be proud if OpenBSD adopts my ntimed, but I'll fully understand and accept if they do not.)
Adding support for being a NTP server is mostly a matter of writing code to defend against packet storms (See: http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#D-L...)
Adding refclocks should never happen in the "main" process, but rather they should be separate processes, suitably sandboxed and interfaced via a good simple API. (I have radical plans for this, which will allow refclocks to be implemented in PL/1, REXX or INTERCAL if that's how you roll :-)
But right here, right now, my focus is to get the vast majority of all machines away from running NTPD, purely as a matter of security and robustness, while improving their timekeeping at the same time.
If ntimed-client ever grows above 10KLOC, I've failed that goal.
First preview release of the source code will happen this weekend.
Most of that source code is there for different and wrong reasons.
It doesn't take much source code to steer your clock precisly, we are talking less than 100 lines.
What takes up space is all the "extras" and "nice to haves".
Unfortunately people seem to have confused "this DEVFS implementation" with "The idea of DEVFS" and thrown the baby out with the bathwater.
For comparison FreeBSD has had DEVFS for 14 years and had a prototype for a good number of years before that.
And yes, I wrote that DEVFS for FreeBSD :-)
The BFO-bias is calibrated why the plane is on the ground, and they assume it is constant over time, temperature, air-pressure etc.
This is probably not a valid assumption under any circumstances, given that there is no atomic frequency standard involved and probably not even an OCXO.
Given that MH370's inmarsat-terminal was powered off for something like an hour during which environmentals may have been extreme and even outside specs, the assumption of a constant bias certainly have no legs to stand on in this particular case.
If the terminal used something like a 1PPM milspec 100MHz TCXO, I would guess is that the BFO bias could be anywhere between 0 and 300Hz after the 18:25Z logon.
I have not tried to replicate their trajectory estimation using this uncertainty, but by eye-balling it, it vastly increases the uncertainty of the resulting location.
The validations they have done using other aircrafts involves BFO's running in nominal mode throughout, and therefore provides no information about how the BFO bias might change after power on/off or extreme environmentals.
And SVR4 and SCO binaries too for that matter.
The idea that your kernel can only give you one syscall-API is so 1990-ish.
My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session.
A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time.
This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.
For instance moving cookies to the server side would just require a simple key-value store lookup.
The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms.
Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them.
Using information-free session nonces would have neither of these problems, and take up much less bandwidth.
I'm opposed to a protocol which claims to "improve privacy" while leaving some of the most troubling privacy invasions in place.
If we are going to the trouble to upgrade HTTP, we fix all the serious problems we can.
If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on.
Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way.
But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP.
Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause.
And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol.
Nobody seems to have heard the expression "Festina Lente" in this WG.
Poul-Henning
But I think the major problem with OpenSSL is that it never had anything resembling architectural leadership: Things just got bolted on to the side and hung from any convenient nail people could find.
PS: Yes, I wrote that piece.
The ICC-ID identifies a SIM card, not a person ?
The two big changes which will affect the VCL you link are:
Purge is now treated as a special kind of transaction, which should make life easier for everybody using it.
And the client/backend split.
vcl_fetch{} in general becomes vcl_backend_response{} whereas the stuff usually done in both vcl_pass{} and vcl_miss{} becomes vcl_backend_fetch{}
Hope this helps.
PS: And yes, I wrote Varnish, and I'm very interested in any bugs, problems, or just plain stupidities you may find.
You can fit all of it on a 16GB SD card for your eBook reader, and you will never be bored again, at least not if you skip some of the calculus :-)
The AIs are of the "hive mind" kind and it is common to refer to it as "A transnational corporation."
Known identities are "IBM", "Google", "Unilever", "Monsanto" etc.
These AI's are beholden to nobody, define and persue their own goals, by manipulating their environment to their advantage.
And they're better at it than humans: They decide for themselves when, where and how much tax they want to pay, and they are not afraid to remind parliamentary inquiries about this fact.
For at least 10 years, it has been evident that these AI's are politically far more astute and successful than humans, and the latest "trade-agreement" negotiations, what little we get to know about them, is clearly an unmitigated powergrab by these AIs.
The fact that the hive-minds are composed of humans does not in any way change this conclusion.
And now: Imagine how your life would be, if Google, the company, truly hated you, personally, and were out to get you.
Read "The curve of binding energy", and you will learn from Ted Taylor, one of the worlds best nuclear warhead designers, that you can make the simplest atomic bomb by dropping one piece of fissile material on another, provided they are big enough to become a critical mass.
It won't be tens of megatons, but it will be a perfect terror weapon, spreading panic, making a large-ish area uninhabitable and costing a fortune and many years to clean up.
If the terrorists are smart enough bring a couple of sacks of salt, it makes the mess much worse.
There are damn good reasons to go out of the way to prevent access to the funny end of the periodic table.