Jeff Liebermann wrote:> On Mon, 25 Feb 2013 09:54:28 -0800, Joerg <invalid@invalid.invalid> > wrote: > >> Jeff Liebermann wrote: >>> On Sun, 24 Feb 2013 15:42:39 -0800, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> Well, it's already done. So not I am wondering about the laptops. >>>> They've got to have such batteries as well. Maybe time to check those out. >>> Laptops do not have button cell holders. They have wire leads spot >>> welded or soldered to the button battery, a short pair of wires, and a >>> tiny connector. The battery is insulated in shrink tube. The ritual >>> is the same if you want to preserve the settings. Leave the power >>> applied to the laptop and the laptop running. Unplug the old battery >>> and quickly insert the new battery. Most such batteries are easily >>> accessible through a door on the bottom of the laptop, although there >>> are a few abominations where the manufacturer elected to hide the >>> battery in difficult to find location. > >> Why does the change have to be quick? Isn't the circuit powered as long >> as the laptop is? > > In the dark ages of laptops, the clock and CMOS memory were powered by > the main battery with the button cell as a diode isolated backup. The > button cell would draw no current until the main battery was either > removed or depleted. Somewhere about 10 years ago, the clock chips > and CMOS (serial) memory started drawing less power than the self > leakage on the button cell. So, it was decided to just run them on > the CMOS battery and not involve the main battery. ...That was not a very smart decision by the industry. Serviceablity has suffered as a consequence.> ... I found this out > the hard way by unplugging the battery with the computer running, and > losing both the clock and CMOS settings. There's usually an > electrolytic capacitor across the battery to deal with battery > changes. I don't know how long it is expected to last, but it's > probably measured in seconds. >And we know how that does. Battery is out ... cell phone rings ... oh, got to take this one real quick ... :-)> I'm not 100% sure of the above, but I can check when I get to the > office tomorrow, where I have some laptop schematics. > >> Because then one could solder in a new battery and >> re-use the connector instead of shelling out lots of dough for a >> specialty battery plus shipping charges. > > If your soldering iron is grounded and your charger grounds the laptop > case, you'll probably short the battery terminals as soon as you hit > it with the soldering iron tip. Also, replacement batteries are > something like $3 to $8/ea, which is not a big deal. If you must roll > your own, you can salvage a battery connector and cable from a dead > laptop at the local recycler, and use that with a new battery. >My iron can be operated sans ground. With a laptop it's not really that tough anyhow because one can unplug the charger (many of those aren't grounded anyhow). Just watch for ESD.>> Hey, it's nice, this morning the PC showed the correct time again :-) > > Every time your PC loses an interrupt, the clock drops 15.6 msec. > That's because most I/O devices have priority over the timer ticks. If > you're doing lots of disk bashing or playing a DVD movie, you're going > to see the clock slow down. How much depends on how many interrupts > are lost. > > Drivel: Many years ago, I decided that I wanted GPS accuracy on my > office Unix server. I took the NEMA 183 output from an old Garmin 65 > GPS, parsed the data with a shell script, and reset the PC clock > according to the GPS time. What I forgot to include was a sanity > check on the data. When the receiver lost sync, the GPS would produce > 00:00:00 etc as the current time. It took a while to clean up my log > files and recover from that mistake. This is another reason why I > don't do much programming. >Whoops :-)>> What I really don't understand why in this day and age they don't write >> the settings into flash. I mean, we even successfully do that on totally >> cheapo uC design. > > Here's what's stored in the CMOS: > <http://www.bioscentral.com/misc/cmosmap.htm> > Note that the first few bytes are the RTC current time and date (but > not the TZ time zone). This info gets written to the CMOS chip once > every second. If that were flash memory with an optimistic 100,000 > write/erase cycles, the flash chip would be dead in several days. >Not really. Almost everything beyond 0Fh gets written once and then left alone the next five years of so. Ok, maybe someone buys a new drive and enters that. This would cause two write cycles to that location in five years. -- Regards, Joerg http://www.analogconsultants.com/
OT: Can CMOS battery on PC motherboard be hot-swapped?
Started by ●February 24, 2013
Reply by ●February 25, 20132013-02-25
Reply by ●February 25, 20132013-02-25
On Mon, 25 Feb 2013 10:51:52 -0800, Joerg <invalid@invalid.invalid> wrote:>That was not a very smart decision by the industry. Serviceablity has >suffered as a consequence.#begin rant() The industry does not care about serviceability, reparability, longevity, recycling, and cost of ownership. All of these have front end costs associated with them, that are more expensive than simple replacement. Welcome to toss and replace, where the only things of importance is initial cost. With the current trend in irreparable iPads and iPhones, I would expect the industry to follow providing us with an irreparable laptop. The Retina MacBook Pro is close. Little things, like battery replacement become a non-issue when the battery is glued into the case, and where replacing the battery implies replacing the entire laptop. Even Intel has become part of the war on repair. New chips will all be of the non-socketed variety and are expected to be soldered directly to the main board. When you blow up a USB port on the motherboard, you can no longer move the expensive CPU to a new motherboard. <http://www.ifixit.com/Manifesto> #end rant()>My iron can be operated sans ground. With a laptop it's not really that >tough anyhow because one can unplug the charger (many of those aren't >grounded anyhow). Just watch for ESD.I like my soldering irons grounded. It makes for better pyrotechnics when I hit the power bus after forgetting to unplug the device.>Whoops :-)My abilities to write defective software is well known. I can do many things, but programming is not one of them.>>> What I really don't understand why in this day and age they don't write >>> the settings into flash. I mean, we even successfully do that on totally >>> cheapo uC design. >> >> Here's what's stored in the CMOS: >> <http://www.bioscentral.com/misc/cmosmap.htm> >> Note that the first few bytes are the RTC current time and date (but >> not the TZ time zone). This info gets written to the CMOS chip once >> every second. If that were flash memory with an optimistic 100,000 >> write/erase cycles, the flash chip would be dead in several days.>Not really. Almost everything beyond 0Fh gets written once and then left >alone the next five years of so. Ok, maybe someone buys a new drive and >enters that. This would cause two write cycles to that location in five >years.True. It's the clock and status registers below 0Fh that get scribbled to constantly. One could split the CMOS function in half, with the lower half continuing to be CMOS, while the rest is changed to flash. However, that will add front end cost and additional complexity, which are not good things. -- Jeff Liebermann jeffl@cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
Reply by ●February 25, 20132013-02-25
Jim Thompson <To-Email-Use-The-Envelope-Icon@on-my-web-site.com> wrote:> On Mon, 25 Feb 2013 10:28:41 -0500, JW <none@dev.null> wrote: >>On Mon, 25 Feb 2013 07:47:15 -0700 Jim Thompson >><To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote in Message id: >><t4umi895422qgofrhvoi0c9pja7fqf2cic@4ax.com>: >> >>> RTC's are often rather crappy. >>> >>> I use Socketwatch from... >>> >>> http://www.robomagic.com >>> >>> I'm currently within 50ms of UTC/ >> >> That's $10. I use Time synchronizer from Softnik Technologies. > > Sounds like that synchronizer is functional only at boot or > manually...If you're using Windows (XP and up for sure, don't remember about 2000), it has a built-in time sync functionality, *as long as the machine is not part of a domain*. Just go to the time and date settings in Control Panel and you should have an option for "Internet Time". It will default to the server time.windows.com (which probably round-robins to several machines at Microsoft) but you can add other servers if you like. If your Windows machine is part of a domain, its time is synchronized from the domain controller as part of the networking protocol. If the domain controller is listening to an Internet time server, then it will propagate the correct time to its clients. If you have old Windows or otherwise want some kind of independent time-setting software, nistime-32bit.exe is free of charge from http://www.nist.gov/pml/div688/grp40/its.cfm . It says: "The program can be configured to query the server periodically and run in the background." I have used it before on Windows 98 and it seems to work OK; the minimum query interval is one hour. That NIST page also has a link to a list of other time-setting software for various OSes. (Trivia: it's called -32bit.exe, not to distinguish it from the 64-bit version, but from the 16-bit version!) If you have Linux, you can run ntpd. Most recent distributions do this and provide some kind of happy clicky control panel. The real skinny is in /etc/ntp.conf . ntpd can get its reference time over the Internet, or from a local GPS receiver. I don't know what OS X runs under the hood but I wouldn't be surprised if it's some flavor of ntpd. The knobs are apparently at Applications > System Preferences > Date & Time . Matt Roberds
Reply by ●February 25, 20132013-02-25
Jeff Liebermann wrote:> On Mon, 25 Feb 2013 10:51:52 -0800, Joerg <invalid@invalid.invalid> > wrote: >[...]> My abilities to write defective software is well known. I can do many > things, but programming is not one of them. >Same here, I think we somehow must have the same forefathers :-) Although my dad was a pro when it comes to programming, and so is my sister, so maybe it's just me who didn't get the programmer's gene or where it mutated into a circuit design gene.>>>> What I really don't understand why in this day and age they don't write >>>> the settings into flash. I mean, we even successfully do that on totally >>>> cheapo uC design. >>> Here's what's stored in the CMOS: >>> <http://www.bioscentral.com/misc/cmosmap.htm> >>> Note that the first few bytes are the RTC current time and date (but >>> not the TZ time zone). This info gets written to the CMOS chip once >>> every second. If that were flash memory with an optimistic 100,000 >>> write/erase cycles, the flash chip would be dead in several days. > >> Not really. Almost everything beyond 0Fh gets written once and then left >> alone the next five years of so. Ok, maybe someone buys a new drive and >> enters that. This would cause two write cycles to that location in five >> years. > > True. It's the clock and status registers below 0Fh that get > scribbled to constantly. One could split the CMOS function in half, > with the lower half continuing to be CMOS, while the rest is changed > to flash. However, that will add front end cost and additional > complexity, which are not good things. >Wouldn't it be a zero-cost piece of cake to at least write those to hard disk and in case of finding a blank offer the user to restore from there? Also, the BIOS is in flash so why not store there instead? It would behove the industry to think about this because there is one major reason why PC sales are slumping: The things became to darn complicated for ol'Leroy. He does not want to face a pricey Geek Squad call every time some obtuse "unrecoverable error" has occurred. So he invests his money into a smart phone instead. Because that's not complicated. A PC is complicated. -- Regards, Joerg http://www.analogconsultants.com/
Reply by ●February 26, 20132013-02-26
>> Internet updates are prone to latency errors , so do not expect better >> than plus or minus about 1.5 seconds in that realm. > > NTP is much better than that. > >Yep, though on windows you need Meinberg for NTP. Windows Time service isn't as good. Linux real real NTP. Tuning up NTP is a bit of work if you want to be optimal. Even though people claim the accuracy is independent of the time reference, I make it a point to find servers close to me (less hops) and that experience low jitter, which can be determined via logging features of NTP. I have found that running the antivirus check will effect the NTP accuracy. It pays to plot the time error and then correlate it to known time dependent programs. You should be able to get the time error under 20ms.
Reply by ●February 26, 20132013-02-26
On Mon, 25 Feb 2013 20:12:00 -0800, miso <miso@sushi.com> wrote:>>> Internet updates are prone to latency errors , so do not expect better >>> than plus or minus about 1.5 seconds in that realm. >> >> NTP is much better than that. >> >> > >Yep, though on windows you need Meinberg for NTP. Windows Time service >isn't as good. Linux real real NTP. > >Tuning up NTP is a bit of work if you want to be optimal. Even though >people claim the accuracy is independent of the time reference, I make >it a point to find servers close to me (less hops) and that experience >low jitter, which can be determined via logging features of NTP. > >I have found that running the antivirus check will effect the NTP >accuracy. It pays to plot the time error and then correlate it to known >time dependent programs. > >You should be able to get the time error under 20ms. > >Get it to synch to your phone and you'll get better accuracy than that. Call NIST directly with a hard connected modem and you can get within 2ms. Regularly. Every time.. repeatably. Your claim of 20ms is falsely based. Do it 25 times, and I'll bet you get 25 different offsets from the real. So more likely plus or minus about 80ms. You could probably get closer by hand synching to your phone with the mouse click.
Reply by ●February 26, 20132013-02-26
On 2013-02-26, SoothSayer <SaySooth@TheMonastery.org> wrote:> On Mon, 25 Feb 2013 20:12:00 -0800, miso <miso@sushi.com> wrote: > >>>> Internet updates are prone to latency errors , so do not expect better >>>> than plus or minus about 1.5 seconds in that realm. >>> >>> NTP is much better than that. >>> >>> >> >>Yep, though on windows you need Meinberg for NTP. Windows Time service >>isn't as good. Linux real real NTP. >> >>Tuning up NTP is a bit of work if you want to be optimal. Even though >>people claim the accuracy is independent of the time reference, I make >>it a point to find servers close to me (less hops) and that experience >>low jitter, which can be determined via logging features of NTP. >> >>I have found that running the antivirus check will effect the NTP >>accuracy. It pays to plot the time error and then correlate it to known >>time dependent programs. >> >>You should be able to get the time error under 20ms.>> >> > Get it to synch to your phone and you'll get better accuracy than that. > > Call NIST directly with a hard connected modem and you can get within > 2ms. Regularly. Every time.. repeatably.11000km in <2ms ! I don't think so.> Your claim of 20ms is falsely based. Do it 25 times, and I'll bet you > get 25 different offsets from the real. So more likely plus or minus > about 80ms. You could probably get closer by hand synching to your phone > with the mouse click.25 times? Fuck! do it a million times the offset is still always under 5ms, and that's using third tier timeservers. These graphs are from someone else's server but are typical of a carelessly installed NTP setup: http://www.papy-team.org/munin/org/papy-team.org/ntp_offset.html -- ⚂⚃ 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply by ●February 26, 20132013-02-26
On 26 Feb 2013 06:43:34 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:>> Call NIST directly with a hard connected modem and you can get within >> 2ms. Regularly. Every time.. repeatably. > >11000km in <2ms ! I don't think so.With a hard modem, the connection you get is timed. They account for the entire trip time, and even for your serial port latency, and the resultant determination as way more accurate than Any NTP method EVER was. Phones even used satellites, and they compensated for that "hop" too. So you jump to conclusions without knowing what men did back then. Yes... I think so. The NTP "utilities" take several samples and picks the most commonly returned result. They bounce around so much, you get a different result every time. Just pay attention and it is easy to see. It sets the time differently every time. Call these NIST guys with a modem, and your hard link will get you consistent sub 5ms time sets. That is what it was/is meant for. IIRC, there is a similar phone line set-up over on that half.
Reply by ●February 26, 20132013-02-26
On 2013-02-26, SoothSayer <SaySooth@TheMonastery.org> wrote:> On 26 Feb 2013 06:43:34 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: > >>> Call NIST directly with a hard connected modem and you can get within >>> 2ms. Regularly. Every time.. repeatably. >> >>11000km in <2ms ! I don't think so. > > > With a hard modem, the connection you get is timed. They account for > the entire trip time, and even for your serial port latency, and the > resultant determination as way more accurate than Any NTP method EVER > was. Phones even used satellites, and they compensated for that "hop" > too.Ah, I thought were proposing to just dial some tty "time of day" service and subtract the time it takes to clock the bits through the UART.> The NTP "utilities" take several samples and picks the most commonly > returned result. They bounce around so much, you get a different result > every time. Just pay attention and it is easy to see. It sets the time > differently every time.> Call these NIST guys with a modem, and your hard link will get you > consistent sub 5ms time sets.I get that from NTP already.> IIRC, there is a similar phone line set-up over on that half.half=hemisphere? Yeah, I think I dialed it once or twice, when it was a free call. it was very similar to what I have read about ACTS. It appears to have been discontinued. -- ⚂⚃ 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply by ●February 26, 20132013-02-26
On Mon, 25 Feb 2013 08:48:26 -0700 Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote in Message id: <rf1ni8pnj3rs2gpmmqvai5kod808gl3nnk@4ax.com>:>On Mon, 25 Feb 2013 10:28:41 -0500, JW <none@dev.null> wrote: > >>On Mon, 25 Feb 2013 07:47:15 -0700 Jim Thompson >><To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote in Message id: >><t4umi895422qgofrhvoi0c9pja7fqf2cic@4ax.com>: >> >>>On Sun, 24 Feb 2013 10:59:35 -0800, Joerg <invalid@invalid.invalid> >>>wrote: >>> >>>[snip] >>>>> >>>> >>>>That's odd. Because the PC here is always sent to hibernate and the >>>>power is turned off. But it remains connected to 120VAC. Still, this >>>>morning the RTC was off again by more than five minutes from yesterday. >>>> >>>> >>>[snip] >>> >>>RTC's are often rather crappy. >>> >>>I use Socketwatch from... >>> >>> http://www.robomagic.com >>> >>>I'm currently within 50ms of UTC/ >>> >> >>That's $10. I use Time synchronizer from Softnik Technologies. Better yet, >>it's free. http://time-synchronizer.software.informer.com/ > >Sounds like that synchronizer is functional only at boot or >manually... > >"A simple time synchronizer that may be configured to startup at >Windows boot, automatically connect to an atomic clock based time >server, synchronize the system clock and then quit." > >My machines run 24/7. My Socketwatch set-up automatically >synchronizes every 60 minutes (you can set it to any interval you >want).It can be configured to run in the system tray and update the clock at any interval you choose with any timeserver you want.>Socketwatch also has a convenient tool to synchronize your watch to >the second... count down and "beep-beep-beep-BOING" like the old time >signals on your AM radio.Doesn't do that, though...
