Re: [ntp:questions] Selective peerstats collection
On 08/12/2012 06:23, Hal Murray wrote: [] What's the cost of a SD card? Pick a medium size one and run the experiment with full logging. You might get lucky or unlucky, but it will give you one data point. Anybody interested in this area should be sure to read: (bunnie's blog) On MicroSD Problems http://www.bunniestudios.com/blog/?p=918 The problem is that if it takes, say, 3 months to wear out the SD card, I don't really have that long to wait! My time costs a lot more than the SD card. Likely I will turn off statistics collection outside major NTP changes. Thanks for the micro-SD card blog - I recall reading that some time back, but it's still a great great investigation tale. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Selective peerstats collection
Hal Murray wrote: In article k9q1fg$vd0$1...@dont-email.me, David Taylor david-tay...@blueyonder.co.uk.invalid writes: Thanks for your suggestions, Hal. At the moment, I don't have a handle on what to expect the lifetime of an SD card used as a Linux system disk, so therefore how much effort to put into finding a solution. What's the cost of a SD card? Pick a medium size one and run the experiment with full logging. You might get lucky or unlucky, but it will give you one data point. I presume this is being done as a hobbyist project, where the value put on human time is very subjective. Even commercially, you can have situations where SD card is part of hardware sold as part of some managed service, and where one is expected to send a technician out to replace it, making the cost more like £50-100. The real problem, though is there seems to be no reliable information on life times. It is fairly easy to find the raw lifetime of a cell (3000-5000 cycles) but the actual way that external writes are mapped into row writes tends to be a carefully guarded secret and any clues seem to be missing from packaging and marketing material. What I found out is a suggestion that more expensive, branded, controllers are likely to do wear levelling. However, there is was also a suggestion that all cards, do not update in place, except for some sort of index memory, which is more resilient than the main memory. They copy a row to a new location on each update. How wear levelling can improve on the basic copy operation was not clear and nor where things like the row size and when the rewrite actually took place (using a write back cache of one or more rows would reduce the actual number of physical updates, but what is the policy for forcing a write). All this sort of information seems to fall under the class of trade secrets that a buyer needs to know, to make intelligent buying and design decisions, but the release of which is vetoed by the vendor's marketing people, nervous of their IPR. In the case of the Pi, they are designed for an extremely price sensitive market, and good quality SD cards cost about 25% of the cost of the computer board. Cheap cards may well expire very quickly when used as a computer filesystem, rather than a still camera's film. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Selective peerstats collection
On 08/12/2012 10:25, Hal Murray wrote: In article k9uqvn$mf2$1...@dont-email.me, David Taylor david-tay...@blueyonder.co.uk.invalid writes: The problem is that if it takes, say, 3 months to wear out the SD card, I don't really have that long to wait! My time costs a lot more than the SD card. Likely I will turn off statistics collection outside major NTP changes. I think it will last years. I can't prove that. I might be wrong. I don't know how to evaluate your time. A low cost SD card is ballpark of $10. If your time is worth anything, you have already spent more than that discussing this. :) Just logging to the SD card is simple and doesn't waste time trying to figure out how to do something else. If it dies after 3 months, you go Oh shit and put the system back together. I'm assuming you backup the log files over to another system occasionally, say once a day. So if the SD disk dies, you lose at most a day of log files. Then you get to decide if swapping in a new SD card every now and then is cheaper than working out the alternatives. -- I have a small embedded type box generating lots of log files. It's on a UPS. I'd like to minimize the power it burns to maximize the time it can run on the UPS. Several years ago, I put all the log files into ramdisk so the disk could spin down and occasionally copied them to the real disk. After I got that stuff all debugged, I discovered that it didn't save enough power to be worth the effort. So I ripped out that stuff and went back to just logging to disk. I suppose I'm prepared to put the time in to understanding the issues involved, but not into getting half a dozen different brand of SD cards and seeing when they fail. Yes, having a 4 GB or 8 GB SD card which can be loaded from the most recent backup of the working SD card would be more than adequate in this particular case. As it happens, the log files are backed up daily with a scheduled task on the Windows PC and PKZip25 (yes, that old) accessing the data through a Samba share. Even then, I'm interested to know how well does NTP work, and that should be normally constant. Retaining the log files is in no way critical. However, what I would like to know is the answer to: What is causing the most write activity on the SD card, what effect does that have on its life, and how can such activity be minimised? But if I don't find that out it doesn't really matter. Thanks for the information on your own system. The nice thing about this NTP server is that it takes less than 4 watts ... so I'm definitely /not/ worrying about power consumption! G (But people are telling me that that are employing these devices remotely, e.g. on mountain tops, solar powered perhaps, so if they are going to fail after just a few weeks or months it would be helpful to be warned in advance.) -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Win7: ntpd adjusting time backwards
If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source:Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to 2012-12-08T14:18:52.34700Z from 2012-12-08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.142 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.2022 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30193.79.237.142 u 16 64 377 18.963 34.747 13.242 Any hints/tips? -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08, Jeroen Mostert jmost...@xs4all.nl wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): Log Name: System Source:Microsoft-Windows-Kernel-General Date: 2012-12-08 15:18:52 Event ID: 1 Task Category: None Level: Information Keywords: Time User: PORTIA\ntp Computer: PORTIA Description: The system time has changed to ???2012???-???12???-???08T14:18:52.34700Z from ???2012???-???12???-???08T14:18:52.569674500Z. As I understand it, it's not supposed to be doing this, instead it should slow the clock down. No. ntpd jumps the time, forward or backward, if the time is out by more than 128 microseconds. Since ntpd puts a limit of 500PPM on the clock rate adjust, it would take a minimum of 3 hours to fix a 1 second error. (and a year to fix a 1 hr error) if it only used the slew rate to fix the time error. On Linux there are two clock rate fix machanisms-- a fine rate adjust and a coarse one. The coarse one can change the rate up to 10PPM so could in principle fix a 10 hr offset in 4 days, but ntpd does not use that mechanism. It jumps instead (Ie, it has a fine rate adjust and an infinite rate adjust only). I do not know if windows has the same coarse rate adjust mechanism. Note that both operating systems use the coarse adjust at bootup when they calibrate the system clock rate. If your timer rate is out by a lot, you can recalibrate by hand and readjust the system clock rate using that coarse adjust. The main question is whether or not your jumping indicates more severe problems-- ie why is the clock finding itself so far out that it has to jump. Why is the usual ntpd fixing mechanism not working properly. Do you get this behaviour only at the beginning, or after ntpd has been running for days? Event log entries from NTP (using the Meinberg install on Win7 64-bit): ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2) Raised to realtime priority class MM timer resolution: 1..100 msec, set to 1 msec Performance counter frequency 3.215 MHz Clock interrupt period 15.600 msec (startup slew 0.2 usec/period) Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.100 usec This is just a client machine syncing with NTP pool machines, no PPS. If my Googling indicates anything, those last two lines might indicate a problem since NTP is supposed to be using interpolation and it doesn't. There's also hints that the crazy huge precision value indicates a problem with a driver. However, I've checked two other machines and they log the same thing, so maybe this is normal. I've tried 4.2.7p310 binaries as well, but they log nearly the same thing: ntpd 4.2.7p310-o Oct 09 17:56:01.10 (UTC-00:00) 2012 (1): Starting Raised to realtime priority class Clock interrupt period 15.600 msec (startup slew -0.3 usec/period) Performance counter frequency 3.215 MHz MM timer resolution: 1..100 msec, set to 1 msec Windows clock precision 1.000 msec, min. slew 6.410 ppm/s using Windows clock directly proto: precision = 1000.000 usec (-10) proto: fuzz beneath 0.201 usec The clock is now being adjusted forwards instead of backwards, but still with big increments. Current ntpq -pn output: remote refid st t when poll reach delay offset jitter == +89.188.26.129 193.79.237.142 u 56 64 377 24.989 20.536 8.671 +91.148.192.49 193.67.79.2022 u 35 64 377 17.968 35.173 13.029 -85.12.35.12 134.221.205.12 2 u 37 64 377 16.989 25.143 10.667 *83.98.155.30193.79.237.142 u 16 64 377 18.963 34.747 13.242 Any hints/tips? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08 21:12, unruh wrote: On 2012-12-08, Jeroen Mostertjmost...@xs4all.nl wrote: If my event log is to be believed, ntpd is adjusting the clock to times in the past (with pretty big intervals): snip As I understand it, it's not supposed to be doing this, instead it should slow the clock down. No. ntpd jumps the time, forward or backward, if the time is out by more than 128 microseconds. I think you mean 128 milliseconds. That's what I'm getting from the docs, anyway. I thought ntp could adjust the time forwards in big steps, but would never adjust the time backwards. I'm guessing I got confused with the slew-only option (-x) for servers that absolutely cannot tolerate the clock going backwards, even if it takes forever to adjust it through slew only. Note that both operating systems use the coarse adjust at bootup when they calibrate the system clock rate. If your timer rate is out by a lot, you can recalibrate by hand and readjust the system clock rate using that coarse adjust. Since this machine more or less serves as a guinea pig/model for deployment in a network, calibrating stuff by hand is basically not going to be an option in the production environment. I'm just going to have to count on that working out. The main question is whether or not your jumping indicates more severe problems-- ie why is the clock finding itself so far out that it has to jump. Why is the usual ntpd fixing mechanism not working properly. Do you get this behaviour only at the beginning, or after ntpd has been running for days? At the time of the event, ntpd had been running for 19 hours (same as system uptime). This is of course not that long in NTP terms. The first clock adjustment (logged in the event log) came at 40 seconds uptime, then 4 hours later, and after that it started adjusting about every hour. With your explanation, I'm perfectly willing to blame crappy network conditions and/or crappy pool servers on the frequent adjustments. Looking at another machine, I see zero (0) adjustments there since ntpd was configured to use a central, local time server (stratum 2). This machine has no time-critical services, so as long as it's accurate to within 1 sec/day I can't complain. I was just confused about the clock going backwards. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Win7: ntpd adjusting time backwards
On 2012-12-08 22:03, David Woolley wrote: If you suffer from temporary severe asymmetric delays, you can use the huff and puff tinker option to try and compensate. Given that the adjustments come about every hour, and the machine is not doing anything particularly interesting with the network, *and* I've seen this behavior on other Win7-machines configured to use the NTP pool servers (with radically different network setup/use) I doubt that would do the trick. But I'll keep it in mind. For now I've tried setting NTPD_USE_INTERP_DANGEROUS, because 1) it has DANGEROUS in the name, FOR SCIENCE! and 2) it's reported that the interpolation may actually work again on Windows 7 machines, sometimes (it didn't work well on Vista, which is why ntpd started using the clock directly). Though it's really too early to tell, it's interesting that the offset has kept to 40 ms since the last restart 2 hours ago and no adjustment to the system time has been logged, so this may be a keeper. -- J. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
