Intel Bay Trail Continues To See Linux Fixes In 2020 - This Time For Time Drifting

[phoronix]

Phoronix: Intel Bay Trail Continues To See Linux Fixes In 2020 - This Time For Time Drifting

It's been seven years since Intel launched the "Bay Trail" Atom processors and the Linux fixes for it and the succeeding Cherry Trail continue to materialize for the kernel...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Bay-Trail-Time-Drift

[tildearrow]

Nice.

I remember having this Bay Trail tablet I bought a few years ago.
It was buggy, even under Windows o-o:

- It can't turn off without turning on again. It worked as follows.

1. The power off action actually set a bit in the firmware to ensure it will turn off.
2. Then it actually rebooted (it was incapable of turning off).
3. The firmware logo popped up for a slit second, and then the tablet shut down properly.
Linux beat Windows to this because in a later kernel version it was able to actually shut the tablet down without panicking (but it still required me to turn it on again to ensure it will turn off).

- Sometimes under Windows putting the tablet to sleep would cause it to shut down o-o

Also some users report that some of those chips are designed to self-destruct after a year or so for some odd reason...


...it's 2020 and the sound still does not work. But I can't really complain. I don't use that tablet at all now; plus the battery is almost dead.

[milkylainen]

I've always been under the impression that trusting a computer with "knowing time" without external synchronization (NTP, PTP, PPS, GPS etc, etc..) is like trusting Intel to get CPU security right. For whatever reasons, it's going to go horribly wrong. But it's a good fix anyhow.

[schmidtbag]

I've always been under the impression that trusting a computer with "knowing time" without external synchronization (NTP, PTP, PPS, GPS etc, etc..) is like trusting Intel to get CPU security right. For whatever reasons, it's going to go horribly wrong. But it's a good fix anyhow.

In the vast majority of cases, the clocks in computers are very accurate and run completely independently of the OS. This is why, for example, your entire PC can be locked up (or off, for that matter) and still keep track of time. Your clocks only need to be synced every once in a while. Bay Trail was just a really terrible platform that wasn't designed properly, and I guess that includes the clock.

[milkylainen]

In the vast majority of cases, the clocks in computers are very accurate and run completely independently of the OS. This is why, for example, your entire PC can be locked up (or off, for that matter) and still keep track of time. Your clocks only need to be synced every once in a while. Bay Trail was just a really terrible platform that wasn't designed properly, and I guess that includes the clock.

Are they? I have done a few projects with nanosecond precision and accuracy in Linux. To me, there is no end to how cheap and worthless high-precision timekeeping is.
Battery RTCs are usually horribly inaccurate. CPU clock generators are somewhat accurate, but also yielding accuracy to stuff like spread spectrum to flatten EMI energy in the frequency domain. Frequency scaling and other software/hardware effects do not help either. Also. Everything is affected by vibration, temperature and time. Oscillators degrade over time. Enough shock will damage an oscillator accuracy severely, although your equipment seemingly runs "fine".

Cheap quartz oscillators (typical consumer electronics) are susceptible to all sorts of crap. Syncing in steps are for desktop and server usage mostly. If you have _any_ real time requirements you don't deal in steps other than the initial one from start. You always do frequency skew over different synchronization mechanisms.

But sure. If you count keeping second-ish accuracy over a day or so as accurate... then well. Yes, they are accurate.

[torsionbar28]

Bay Trail was just a really terrible platform that wasn't designed properly, and I guess that includes the clock.

Amen to that, I remember spending way too many hours fighting with that trash. Mine was a Celeron J1900 mITX board that (on paper) would have made an excellent HTPC, which was my goal with it at the time... except it was complete garbage, constantly locking up, rebooting, the bugs were insane on that thing *years* after release even. All kinds of suggestions for tweaks and kernel options in the various forums, but nothing really solved it.

Quite frankly I'm not sure how a class action lawsuit didn't materialize for how awful Bay Trail was. Just another reason I refuse to give intel any more of my money.

Whoever the Bay Trail product manager was at intel should be fed some Wuhan chicken with spicy flu sauce.

[schmidtbag]

Quite frankly I'm not sure how a class action lawsuit didn't materialize for how awful Bay Trail was. Just another reason I refuse to give intel any more of my money.

Because on Windows, it was "adequate". The hardware was crap/crappy enough that nobody using it had real money to bring Intel to court.
I have an Asus laptop based on Bay Trail. Right now it's sitting in a drawer collecting dust because it was too crappy. I actually didn't buy it myself, but I don't like throwing away functional hardware. I'll likely find some use for it some day, probably for some robotics project (like I do with all of my outdated crap).

[willmore]

But sure. If you count keeping second-ish accuracy over a day or so as accurate... then well. Yes, they are accurate.

As someone who's (tried to at least) done high precision timing work on PC hardware, I can attest to this. MB vendors will often tweak base clocks so that CPU frequencies derived from them will be faster (built in overclock), but don't represent that time change elsewhere--leaving it to the OS to realize that things aren't running correctly. If you're basing your measurements from the clocks in the PC and they're all off by some percentage (they are normally derived from one xtal by an IC that uses PLLs to generate a variety of clocks), how do you know? There isn't some absolute truth built into the machine. Linux distros and similar OSs will run some kind of NTP daemon to sync with a trusted external time source. From that, it's *possible* to at least get some idea of the errors in the clock on the PC and to maybe compensate for some of them. But that only gets you so far.

There may have been a time when PC MB makers cared about proper timekeeping and used decent XTALs and other components, but that's a very long time in the past. Modern PC timing hardware is just crap. SBCs are even worse as they rarely even have a battery to run an RTC while their power is off. They rely on a network connection to know what time it is. If you're super lucky, they at least have a header for an RTC battery. Otherwise, adding a working RTC is up to the user.

[pigpen]

Bay trail rules !

I have 2 Bay trails widgets (10" laptop & 8" dell tablet ... sadly the wifi is on the sd bus and sux) running Fedora.

Just got a 10" dell cherry trail tablet from eBay.

[ferry]

Bay trail rules !

I have 2 Bay trails widgets (10" laptop & 8" dell tablet ... sadly the wifi is on the sd bus and sux) running Fedora.

Just got a 10" dell cherry trail tablet from eBay.

Indeed. I have a Bay trail NUC always on as a Kodi player + Intel Edison to play with.