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, <[email protected]> wrote: > Send time-nuts mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 > ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 02 Dec 2010 22:17:52 -0500 > From: [email protected] (Mike S) > Subject: [time-nuts] Linux timekeeping / jiffy source > To: Discussion of precise time and frequency measurement > <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [time-nuts] Linux timekeeping / jiffy source > To: Discussion of precise time and frequency measurement > <[email protected]> > Cc: Discussion of precise time and frequency measurement > <[email protected]> > Message-ID: <[email protected]> > 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, [email protected] (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 -- [email protected] >> 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 <[email protected]> > Subject: Re: [time-nuts] Linux timekeeping / jiffy source > To: Discussion of precise time and frequency measurement > <[email protected]> > Message-ID: > <[email protected]> > 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" <[email protected]> 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 -- [email protected] > 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 <[email protected]> > Subject: Re: [time-nuts] Linux timekeeping / jiffy source > To: Discussion of precise time and frequency measurement > <[email protected]> > Message-ID: <[email protected]> > 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 <[email protected]> > Subject: Re: [time-nuts] Linux timekeeping / jiffy source > To: Discussion of precise time and frequency measurement > <[email protected]> > Message-ID: > <[email protected]> > 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 <[email protected]> > Subject: Re: [time-nuts] Linux timekeeping / jiffy source > To: [email protected] > Message-ID: <[email protected]> > 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: [email protected] > Subject: [time-nuts] Z3801A Power Modules -- was time-nuts Digest, Vol > 77, Issue 4 > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="US-ASCII" > > In a message dated 03/12/2010 01:11:02 GMT Standard Time, [email protected] > 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 > [email protected] > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 77, Issue 8 > **************************************** > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
