[time-nuts] time-nuts Digest, Vol 77, Issue 8

Jerry jreed123 at cox.net
Sun Dec 5 15:16:10 UTC 2010


Thanks to everyone I am learning more and more about my Z3801A/58503.
Thanks to Nigel the mystery of how a DC-DC converter with an input
marked as 48 volts can function with an input of 24 volts.  I just
didnt realize that the device was designed to function with that wide
of a input tolerance.  I have isolated the problem with my unit.  The
signal from the CPU to pin 8 of the power supply board P2 never goes
positive and therefor never turns on the outer oven of the oscillator.
 I found some information about this bit being stuck and pulling it
high with an external voltage with the pin disconnected and feed
through a 1K resistor, which I tried.  Pulling pin 8 of P2 up with an
external voltage turns on the outer oven control and it seems to work
fine however I cannot get the CPU to reset and control the outer oven.
 Any thoughts

On Fri, Dec 3, 2010 at 5:00 AM,  <time-nuts-request at febo.com> wrote:
> Send time-nuts mailing list submissions to
>        time-nuts at febo.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> or, via email, send a message with subject or body 'help' to
>        time-nuts-request at febo.com
>
> You can reach the person managing the list at
>        time-nuts-owner at febo.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of time-nuts digest..."
>
>
> Today's Topics:
>
>   1. Linux timekeeping / jiffy source (Mike S)
>   2. Re: Linux timekeeping / jiffy source (bownes)
>   3. Re: Linux timekeeping / jiffy source (Robert Darlington)
>   4. Re: Linux timekeeping / jiffy source (Christian Vogel)
>   5. Re: Linux timekeeping / jiffy source (Hal Murray)
>   6. Re: Linux timekeeping / jiffy source (Kasper Pedersen)
>   7. Z3801A Power Modules -- was time-nuts Digest, Vol 77,     Issue 4
>      (GandalfG8 at aol.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 02 Dec 2010 22:17:52 -0500
> From: mikes at flatsurface.com (Mike S)
> Subject: [time-nuts] Linux timekeeping / jiffy source
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID: <20101203031815.5A0F6A007E at locke.alientech.net>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
>
> Anyone familiar with Linux kernel timekeeping?
>
> I've recently upgraded a server to an AMD 890FX/SB850 based
> motherboard. After doing so, I observed a large (in time-nut terms)
> inconsistency in system timing, as seen in the rate of the system's
> Time Of Day clock.
>
> Sync'ing to a local GPS locked NTP server, I see up to an 80 ppm spread
> between reboots, which I've documented at
> http://www.flatsurface.com/AMD_SB850/index.html . I'm running kernel
> 2.6.32 (Debian squeeze).
>
> I think that kernel timekeeping ("jiffies") are linked to the "8254"
> timer in the SB850 south bridge, but maybe it's the HPET in the 890FX
> north bridge. Anyone know how to tell which the kernel is using for
> timekeeping?
>
> Also, is it possible to restart the Linux kernel without a full reboot
> (avoiding BIOS initialization), to see if it's a kernel or BIOS issue?
> I don't believe a simple change of runlevel restarts the kernel from
> scratch.
>
> I haven't seen this inconsistency on previous Intel or Serverworks
> based motherboards, but I've seen this behavior on 890FX/SB850
> motherboards from two different manufacturers (although I think both
> use Award BIOS).
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 2 Dec 2010 23:16:57 -0500
> From: bownes <bownes at gmail.com>
> Subject: Re: [time-nuts] Linux timekeeping / jiffy source
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Cc: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID: <7B2E95E8-7107-40D9-BE46-32C7221721A0 at gmail.com>
> Content-Type: text/plain;       charset=us-ascii
>
> Unfortunately, there is no way to restart the kernel without going through a BIOS re initialization.
>
> Changing the run level restarts the init process but does not reload the kernel.
>
>
>
> On Dec 2, 2010, at 10:17 PM, mikes at flatsurface.com (Mike S) wrote:
>
>> Anyone familiar with Linux kernel timekeeping?
>>
>> I've recently upgraded a server to an AMD 890FX/SB850 based motherboard. After doing so, I observed a large (in time-nut terms) inconsistency in system timing, as seen in the rate of the system's Time Of Day clock.
>>
>> Sync'ing to a local GPS locked NTP server, I see up to an 80 ppm spread between reboots, which I've documented at http://www.flatsurface.com/AMD_SB850/index.html . I'm running kernel 2.6.32 (Debian squeeze).
>>
>> I think that kernel timekeeping ("jiffies") are linked to the "8254" timer in the SB850 south bridge, but maybe it's the HPET in the 890FX north bridge. Anyone know how to tell which the kernel is using for timekeeping?
>>
>> Also, is it possible to restart the Linux kernel without a full reboot (avoiding BIOS initialization), to see if it's a kernel or BIOS issue? I don't believe a simple change of runlevel restarts the kernel from scratch.
>>
>> I haven't seen this inconsistency on previous Intel or Serverworks based motherboards, but I've seen this behavior on 890FX/SB850 motherboards from two different manufacturers (although I think both use Award BIOS).
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 2 Dec 2010 21:23:15 -0700
> From: Robert Darlington <rdarlington at gmail.com>
> Subject: Re: [time-nuts] Linux timekeeping / jiffy source
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID:
>        <AANLkTi=UU2nU08R=8kGKnAT9AmkaVDCovSW+VQCTcq1G at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Are you running ntp, and if so, did you kill the old drift file?
>
> On Dec 2, 2010 8:18 PM, "Mike S" <mikes at flatsurface.com> wrote:
>
> Anyone familiar with Linux kernel timekeeping?
>
> I've recently upgraded a server to an AMD 890FX/SB850 based motherboard.
> After doing so, I observed a large (in time-nut terms) inconsistency in
> system timing, as seen in the rate of the system's Time Of Day clock.
>
> Sync'ing to a local GPS locked NTP server, I see up to an 80 ppm spread
> between reboots, which I've documented at
> http://www.flatsurface.com/AMD_SB850/index.html . I'm running kernel 2.6.32
> (Debian squeeze).
>
> I think that kernel timekeeping ("jiffies") are linked to the "8254" timer
> in the SB850 south bridge, but maybe it's the HPET in the 890FX north
> bridge. Anyone know how to tell which the kernel is using for timekeeping?
>
> Also, is it possible to restart the Linux kernel without a full reboot
> (avoiding BIOS initialization), to see if it's a kernel or BIOS issue? I
> don't believe a simple change of runlevel restarts the kernel from scratch.
>
> I haven't seen this inconsistency on previous Intel or Serverworks based
> motherboards, but I've seen this behavior on 890FX/SB850 motherboards from
> two different manufacturers (although I think both use Award BIOS).
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 03 Dec 2010 08:17:57 +0100
> From: Christian Vogel <vogelchr at vogel.cx>
> Subject: Re: [time-nuts] Linux timekeeping / jiffy source
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID: <20101203081757.20971jyfkvge6tnk at webmail.df.eu>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
>        format="flowed"
>
> Hi bownes,
>
>> Unfortunately, there is no way to restart the kernel without going
>> through a BIOS re initialization.
>
> actually, there is. It's called "kexec".
>
> See, for example
> http://www.ibm.com/developerworks/linux/library/l-kexec.html .
>
> Greetings from Germany,
>
>         Chris
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 02 Dec 2010 23:22:32 -0800
> From: Hal Murray <hmurray at megapathdsl.net>
> Subject: Re: [time-nuts] Linux timekeeping / jiffy source
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID:
>        <20101203072232.DAC7280003B at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
>
>
>> Sync'ing to a local GPS locked NTP server, I see up to an 80 ppm spread
>> between reboots, which I've documented at  http://www.flatsurface.com/
>> AMD_SB850/index.html . I'm running kernel  2.6.32 (Debian squeeze).
>
> I'm not familiar with AMD, but there is a bug in the Intel world that matches
> your symptoms.
>
> The problem is in the TSC calibration routine.  If you patch the source code
> to call it multiple times and print each answer, you will get various
> answers.  They are all close enough that nobody but a time-nut or alert
> sysadmin would notice.  80 ppm is the right ballpark for a "good" glitch.
> I've seen bigger but don't have numbers handy.  [I did that experiment a
> while (months) ago and haven't rc-checked with a recent kernel.]
>
> If you are willing to recompile your kernel, you can patch the source to use
> a compiled in constant.
>
>> I think that kernel timekeeping ("jiffies") are linked to the "8254"  timer
>> in the SB850 south bridge, but maybe it's the HPET in the 890FX  north
>> bridge. Anyone know how to tell which the kernel is using for  timekeeping?
>
> Somebody "cleaned up" the Linux timekeeping code a year or two ago.  Scan
> your /var/log/messages for something like:
>  Nov  7 08:40:13 shuksan klogd: Detected 2792.933 MHz processor.
> and/or
>  Nov  7 08:40:14 shuksan klogd: Switching to clocksource tsc
>
> If you boot several times, the bottom digits of your processor speed will
> jump around.  (They should track temperature.)
>
> There are now several possible clock sources.  Not all of them are available
> on all CPUs.  At boot time, you can select from the ones that your hardware
> supports and were compiled into your kernel.  Look in <kernel-sources>
> /Documentation/kernel-parameters.txt and search for clocksource
>
> You might be happier with one of the alternate clock sources.  If you don't
> reboot very often, maybe you can just live with it.
>
>
>> Also, is it possible to restart the Linux kernel without a full reboot
>> (avoiding BIOS initialization), to see if it's a kernel or BIOS issue?
>
> I don't know how to do that.
>
>
>> I haven't seen this inconsistency on previous Intel or Serverworks  based
>> motherboards, but I've seen this behavior on 890FX/SB850  motherboards from
>> two different manufacturers (although I think both  use Award BIOS).
>
> Were they running recent kernels?
>
>
>
> --
> These are my opinions, not necessarily my employer's.  I hate spam.
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 03 Dec 2010 08:23:48 +0100
> From: Kasper Pedersen <time-nuts at kasperkp.dk>
> Subject: Re: [time-nuts] Linux timekeeping / jiffy source
> To: time-nuts at febo.com
> Message-ID: <4CF89B04.7000104 at kasperkp.dk>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/03/2010 04:17 AM, Mike S wrote:
>> Anyone familiar with Linux kernel timekeeping?
>>
>
> On boot, the kernel picks a clocksource. If the cpu is recent,
> and it is not forced, the tsc (cpu) counter gets chosen.
>
> The tsc increment rate is initially unknown, and is measured
> against pit (8253/8254), and the result may be off if SMI
> interrupts arrive (these are BIOS interrupts and can not be
> masked by the OS). The newer the kernel, the more
> attempts to work around SMI in that part of the code. If this
> code works, it does not matter what frequency the cpu (and
> thus tsc) is running, so I suspect this code is failing. Or pit
> is on drugs.
>
> http://n1.taur.dk/permanent/testpmt.c
>
> this bit of code will compare the timekeeping clock to the
> PMTimer, which runs off of plain 14.31818MHz/4. It gives you
> the frequency offset (in ppm) in a few seconds, and provided
> ntpd is not started on boot, gives you the scaling error.
>
> If you force the kernel to use another clocksource, either
>    clocksource=hpet
>    clocksource=acpi_pm
> then you may see a rather large error (12 or 127ppm)
> between PMTimer, and the clock running off of PMTimer.
> This is due to a rounding error in timekeeping.c, and for
> that there is this patch:
>
> http://n1.taur.dk/timefix2.patch
>
> With a good* 14.31818MHz, running the clock off of acpi_pm
> is now good. With hpet there's another bug, causing a
> 60e-9 offset.
>
> My patch above is not perfect. When it corrects for, say, a
> 127ppm rounding error, it also inadvertently changes the
> gain of adjustments. Thus, when you (or ntpd) ask for 1ppm
> trim, you get 1.000127 ppm trim. Also, my comment about
> this starting with 2.6.32 is false, it affects much older
> kernels too.
>
> /Kasper Pedersen
>
> *as defined by time-nuts.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 3 Dec 2010 06:36:02 EST
> From: GandalfG8 at aol.com
> Subject: [time-nuts] Z3801A Power Modules -- was time-nuts Digest, Vol
>        77,     Issue 4
> To: time-nuts at febo.com
> Message-ID: <d51d1.880dc83.3a2a3022 at aol.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> In a message dated 03/12/2010 01:11:02 GMT Standard Time, jreed123 at cox.net
> writes:
>
> An  curious thing
> is that there are 2 DC to DC converters the main power  converter is 24
> volts in and +12, -12, and 5 volts out and the input and  output
> voltage is plainly marked on the side of the converter.  The  power
> supply supplied with the unit is 24 volts DC and the that converter  is
> working fine.  The second DC to DC converter is labeled  UMR-5/4000-D48
> which according to the data sheets that I found is a 48 volt  DC in and
> a 5 volt DC at 4 amps out unit.  I dont understand why the 2  DC to DC
> converters would have a different input voltage with only the 1  power
> supply  If anyone has any thoughts about this I would like to  hear
> about them.
> --------------------
> Hi Jerry
>
> I've just checked inside a 48 volt Z3801A, actually marked as 38 to 60
> volts, and that contains a Lucent CW025ACL-M module, marked as 36 to 75 volt
> input, and UWR-5/4000-D48, which I'm guessing is what you intended to write
> rather than UMR......
>
> When I checked the data sheet for the UWR-5/4800-D48 I found  that although
> the nominal voltage is quoted at 48 volts it's specified  to work from 18
> to 72 volts.
>
>
> The DC input for your Z3801A should be indicated on the back, either  19.5
> to 30 volts, nominal 24, or 38 to 60 volts, nominal 48.
>
>
> Since it would seem that the UWR-5/4000-D48 is a suitable module for both
> versions of the Z3801A, and given that your other module is specified at 24
> volts I would say your Z3801A is indeed a 24 volt unit and the supplied
> power supply is correct.
>
> There is additional circuitry for the outer oven PSU so it shouldn't be
> assumed that the UWR-5/4000-D48 itself is faulty without checking its actual
> output.
>
> I have descriptions and schematics for the oven control circuit etc which I
>  can email direct but you'll also find them here on Didier's site.....
>
> _http://www.ko4bb.com/cgi-bin/manuals.pl?dir=05%29_GPS_Timing_
> (http://www.ko4bb.com/cgi-bin/manuals.pl?dir=05)_GPS_Timing)
>
> regards
>
> Nigel
> GM8PZR
>
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
> End of time-nuts Digest, Vol 77, Issue 8
> ****************************************
>




More information about the Time-nuts_lists.febo.com mailing list