I have my own travel story involving DB. I had a ticket for a Lufthansa flight from Frankfurt am Main to Warsaw. When I tried to check-in online a day before the flight it told me I had to do it at the airport. I fly a bit, so I knew what that meant - they overbooked the flight. The next day I got my "no aircraft entry guaranteed" boarding card of shame at the airport and learned at the gate that they overbooked the plane by three persons! After explaining my EU passenger rights, I got them to confirm my €250 compensation and since I was in an adventurous mood headed for the Frankfurt Flughafen Fernbahnhof train station.
The manned DB Travelcenter was still open so I walked in and asked for an international ticket to Warsaw. The gentleman (who spoke fluent English) typed a bit on the computer and told me he cannot sell a ticket for the Berlin-Warsaw leg of the journey due to a "system error on the Polish side". I knew that probably meant the Berlin-Warsaw-Express is at full capacity again and they don't sell tickets with no seat indicated for that route. I asked for a ticket to Berlin instead (€207, 2nd class) and went for a hamburger - still had about an hour until the train.
The train was initially supposed to arrive delayed 5 minutes but that was soon to change. The delay kept ticking up to 20 minutes, 45 minutes, 1 hour (around this time the DB travelcenter closed for the night) then two hours then cancelled altogether. I wasn't sure if my ticket is valid for the next train (the DB website was a bit vague about that) so I called my friend in Hamburg who confirmed I was good to jump onto the next train which would arrive on schedule in another three hours. I tried getting a Capri-Sun from a vending machine but it got stuck and wouldn't fall out. So I sat at the empty station with noting but rats as company until 3AM when the next Berlin-bound train arrived on time. In Berlin I got out at Sudkreutz and jumped onto a FlixBus to Poznań (€22) and stayed the night over at my friend's place (I badly needed a shower at that point) before taking a train to Warsaw the next day (€16, 2nd class).
Now, I technically did eventually use my Frankfurt-Berlin ticket but I was quite annoyed at DB so I applied for a reimbursement due to a cancelled train, which was granted in full. I also applied for reimbursement of the plane ticket from Lufthansa which was also granted. With the additional €250 compensation for denied boarding I actually made money on that little adventure but I probably wouldn't do that again. Gotta check in earlier from now on.
The step to go to ARM or risc v based controllers is easy. That's what I did with V3. Gives a tremendous performance boost and costs 1/2 of that old AVR.
I'm curious what MCU you landed on, but also a suggestion. If you could move the pictures to a different repo (or branch at least) that would make much easier to download. Even now a shallow clone takes ≈20 MB.
I think people have a wrong idea of what a modern atomic clock looks like. These are readily available commercially, Microchip for example will happily sell you hydrogen, cesium or rubidium atomic clocks. Hydrogen masers are rather unwieldy, but you can get a rubidium clock in a 1U format and cesium ones are not much bigger. I think their cesium freq standards are formerly a HP business they acquired.
woah hold on a sec. that's not how these clocks are actually used though.
It's a huge huge huge misconception that you can just plunk down an "atomic clock", discipline an NTP server with it and get perfect wallclock time out of it forever. That is just not how it works. Two hydrogen masers sitting next to each other will drift. Two globally distributed networks of hydrogen masers will drift. They cannot NOT drift. The universe just be that way.
UTC is by definition a consensus; there is no clock in the entire world that one could say is exactly tracking it.
Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard. Their goal is to keep events correlated on their own network, and for that they just need good internal distribution and consensus, and they are at the point where doing that internally makes sense. But this is the same problem on any size network.
Honestly for just NTP, I've never really seen evidence that anything better than a good GPS disciplined TCXO even matters. The reason they offer these oscillators in such devices is because they usually do additional duties like running PtP or distributing a local 10mhz reference where their specific performance characteristics are more useful. Rubidium, for instance, is very stable at short timescales but has awful long term stability.
> Google probably has the gear and the global distribution that they could probably keep pretty close over 30-60 days, but they are assuredly not trying to keep their own independent time standard.
It is also important to realize that an atomic clock will only give you a steady pulse. It will count seconds for you, and do so very accurately, but that is not the same as knowing what time it is.
If you get a rubidium clock for your garage, you can sync it up with GPS to get an accurate-enough clock for your hobby NTP project, but large research institutions and their expensive contraptions are more elaborate to set up.
Sure, but F2 is a bit more accurate: "As of February 2016 the IT-CsF2 cesium fountain clock started reporting a uB of 1.7 × 10−16 in the BIPM reports of evaluation of primary frequency standards." ( from https://web.archive.org/web/20220121090046/ftp://ftp2.bipm.o... )
Thanks! In such serial articles usually there's link to the end pointing to the next one so, since there wasn't any, thought next one hadn't been written. This one indeed addresses the thesis. The TL;DR, taken directly from the article,
>The core problems I see with Python as a language for data science are call-by-reference semantics, lack of built-in concepts of missing values, lack of built-in vectorization, and lack of non-standard evaluation.
reply