Folks,

I'm still trying to resolve NTP on Windows Vista.  I do have a dual-core 
system, so I was wondering how NTP handled dual-core.  Does it discipline 
both cores, and is a special start-up switch required?  Should I define 
the affinity for NTP to a single core?

Looking at the AMD Web site, they do have a utility to sync the two 
cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I tried 
to install this on Vista, but a file appears to be missing!  Has anyone 
got this working, and does it affect NTP?

  http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html

I seem to be full of questions and not answers today!

Thanks,
David 

David J Taylor wrote:
> Folks,
> 
> I'm still trying to resolve NTP on Windows Vista.  I do have a dual-core 
> system, so I was wondering how NTP handled dual-core.  Does it discipline 
> both cores, and is a special start-up switch required?  Should I define 
> the affinity for NTP to a single core?
> 
> Looking at the AMD Web site, they do have a utility to sync the two 
> cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I tried 
> to install this on Vista, but a file appears to be missing!  Has anyone 
> got this working, and does it affect NTP?
> 
>   http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html
> 
> I seem to be full of questions and not answers today!
> 
> Thanks,
> David 
> 
> 

I don't see why NTP should even be aware that it's running on a 
Dual-Core CPU.  Why should it be any different from a box with, say, 
four CPUs?

Richard B. Gilbert wrote:
> David J Taylor wrote:
>> Folks,
>>
>> I'm still trying to resolve NTP on Windows Vista.  I do have a
>> dual-core system, so I was wondering how NTP handled dual-core.  Does 
>> it
>> discipline both cores, and is a special start-up switch required? 
>> Should I
>> define the affinity for NTP to a single core?
>>
>> Looking at the AMD Web site, they do have a utility to sync the two
>> cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I
>> tried to install this on Vista, but a file appears to be missing!  Has
>> anyone got this working, and does it affect NTP?
>>
>> 
>> http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html
>>
>> I seem to be full of questions and not answers today!
>>
>> Thanks,
>> David
>>
>>
>
> I don't see why NTP should even be aware that it's running on a
> Dual-Core CPU.  Why should it be any different from a box with, say,
> four CPUs?

NTP on Windows uses the RDTSC instruction.  Which CPU does it read the 
time stamp counter from?  If NTP is multi-threaded, different threads 
could be run on different CPUs with different TSCs.  Yes, just the same 
issues arise with 4 CPUs, and I don't know how the Windows version of NTP 
handles the multi-processor scenario.

Cheers,
David 

David J Taylor wrote:
[]
> Looking at the AMD Web site, they do have a utility to sync the two
> cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I
> tried to install this on Vista, but a file appears to be missing!

Fixed by using "Run as administrator".

Cheers,
David 

David,

The multiple-CPU nanokernel code that left here and is in the Alpha 
kernel assumes each CPU has an individual cycle counter and the timer 
interupts are vectored to a designated CPU. There is a data structure 
associated with each CPU that holds the measured current cycle counter 
scaling and offset, which is updated once each second by interprocessor 
interrrupt. A call to read the system clock lands on a j-random CPU, 
which reads the global time maintained by timer interrupts and 
interpolates according to the current CPU values.

I don't know if Vista attempts to provide granularity within the tick; 
but if it does, I would expect it to use a similar strategy.

Dave

David J Taylor wrote:
> Folks,
> 
> I'm still trying to resolve NTP on Windows Vista.  I do have a dual-core 
> system, so I was wondering how NTP handled dual-core.  Does it discipline 
> both cores, and is a special start-up switch required?  Should I define 
> the affinity for NTP to a single core?
> 
> Looking at the AMD Web site, they do have a utility to sync the two 
> cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I tried 
> to install this on Vista, but a file appears to be missing!  Has anyone 
> got this working, and does it affect NTP?
> 
>   http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html
> 
> I seem to be full of questions and not answers today!
> 
> Thanks,
> David 
> 
> 

David L. Mills wrote:
> David,
>
> The multiple-CPU nanokernel code that left here and is in the Alpha
> kernel assumes each CPU has an individual cycle counter and the timer
> interupts are vectored to a designated CPU. There is a data structure
> associated with each CPU that holds the measured current cycle counter
> scaling and offset, which is updated once each second by
> interprocessor interrrupt. A call to read the system clock lands on a
> j-random CPU, which reads the global time maintained by timer
> interrupts and interpolates according to the current CPU values.
>
> I don't know if Vista attempts to provide granularity within the tick;
> but if it does, I would expect it to use a similar strategy.
>
> Dave

Thanks for that, Dave.  I haven't needed to touch assembler for a little 
wile now, so I'm not up to speed on whether the various Intel and AMD 
architectures (hyper-threading, dual/quad-core, and physical 
multi-processor etc.) provide access to every cycle counter from a single 
CPU or executing thread.

The Windows implementation does try to provide granularity within the 
tick, but I have no idea how the Meinberg port I'm using handles 
multi-processors.  Checking.  I see the routine: nt_clockstuff.c mentions 
that how to handle multi-processors is not yet decided, but that seems 
very old code (year 2000).  I can't find the RDTSC instruction anywhere in 
version ntp-4.2.4p4.  So I'm a bit stuck right now!

Cheers,
David 

David J Taylor wrote:

> NTP on Windows uses the RDTSC instruction.  Which CPU does it read the 
> time stamp counter from?  If NTP is multi-threaded, different threads 
> could be run on different CPUs with different TSCs.  Yes, just the same 
> issues arise with 4 CPUs, and I don't know how the Windows version of NTP 
> handles the multi-processor scenario.
> 

How do you know that NTP on Windows uses the RDTSC instruction? The CPU
on which the thread is running will be used to read the TSC. In the case
of Windows NTP definitely *is* multithreaded. It needs to be to operate
correctly. I cannot currently tell you how it interoperates with Windows
with multiprocessors. That's a research topic and non-trivial at that.

> Cheers,
> David 

Dave,

While I would agree with you in general, we don't have any real idea
what the Windows code is doing whether or not it is a uniprocessor or
multiprocessor. I very much doubt that they duplicated your work though
I would think that it's very important for the CPU's to keep each other
in close synch in order for threading to work properly. I can say that
at least with threading they have gotten it right and done a better job
than almost every other O/S that I know. I doubt that they could do that
if the CPU's were not properly synchronized.

Danny

David L. Mills wrote:
> David,
> 
> The multiple-CPU nanokernel code that left here and is in the Alpha 
> kernel assumes each CPU has an individual cycle counter and the timer 
> interupts are vectored to a designated CPU. There is a data structure 
> associated with each CPU that holds the measured current cycle counter 
> scaling and offset, which is updated once each second by interprocessor 
> interrrupt. A call to read the system clock lands on a j-random CPU, 
> which reads the global time maintained by timer interrupts and 
> interpolates according to the current CPU values.
> 
> I don't know if Vista attempts to provide granularity within the tick; 
> but if it does, I would expect it to use a similar strategy.
> 
> Dave

Danny Mayer wrote:
> David J Taylor wrote:
>
>> NTP on Windows uses the RDTSC instruction.  Which CPU does it read
>> the time stamp counter from?  If NTP is multi-threaded, different
>> threads could be run on different CPUs with different TSCs.  Yes,
>> just the same issues arise with 4 CPUs, and I don't know how the
>> Windows version of NTP handles the multi-processor scenario.
>>
>
> How do you know that NTP on Windows uses the RDTSC instruction? The
> CPU on which the thread is running will be used to read the TSC. In
> the case of Windows NTP definitely *is* multithreaded. It needs to be
> to operate correctly. I cannot currently tell you how it
> interoperates with Windows with multiprocessors. That's a research
> topic and non-trivial at that.

Danny,

Thanks for your reply.  Perhaps my recollection is at fault here, but I 
recall that NTP on Windows uses some interpolation technique to overcome 
timer granularity, and that the interpolation used a CPU counter.

Now I think further into the topic, I realise that with Windows XP NTP 
works perfectly witha dual-core AMD or Intel system (once the multi-media 
timers are enabled for the duration), but the problem appears to be on 
Windows Vista.  So the question I should be asking is more: "How does 
Windows Vista differ from Windows XP so as to affect NTP, and is that 
anything to do with multi-processors or not?".

The performance I'm seeing is definitely much poorer and, at times, it 
looks almost like NTP is switching between two different times.  For 
example, look at yesterday around 10:00 UTC.

  http://www.david-taylor.myby.co.uk/mrtg/gemini_ntp.html

I may try rebooting that PC with dual-core disabled and see what happens.

Cheers,
David 

David J Taylor wrote:
> Danny Mayer wrote:
> 
>>David J Taylor wrote:
>>
>>
>>>NTP on Windows uses the RDTSC instruction.  Which CPU does it read
>>>the time stamp counter from?  If NTP is multi-threaded, different
>>>threads could be run on different CPUs with different TSCs.  Yes,
>>>just the same issues arise with 4 CPUs, and I don't know how the
>>>Windows version of NTP handles the multi-processor scenario.
>>>
>>
>>How do you know that NTP on Windows uses the RDTSC instruction? The
>>CPU on which the thread is running will be used to read the TSC. In
>>the case of Windows NTP definitely *is* multithreaded. It needs to be
>>to operate correctly. I cannot currently tell you how it
>>interoperates with Windows with multiprocessors. That's a research
>>topic and non-trivial at that.
> 
> 
> Danny,
> 
> Thanks for your reply.  Perhaps my recollection is at fault here, but I 
> recall that NTP on Windows uses some interpolation technique to overcome 
> timer granularity, and that the interpolation used a CPU counter.
> 
> Now I think further into the topic, I realise that with Windows XP NTP 
> works perfectly witha dual-core AMD or Intel system (once the multi-media 
> timers are enabled for the duration), but the problem appears to be on 
> Windows Vista.  So the question I should be asking is more: "How does 
> Windows Vista differ from Windows XP so as to affect NTP, and is that 
> anything to do with multi-processors or not?".
> 
> The performance I'm seeing is definitely much poorer and, at times, it 
> looks almost like NTP is switching between two different times.  For 
> example, look at yesterday around 10:00 UTC.
> 
>   http://www.david-taylor.myby.co.uk/mrtg/gemini_ntp.html
> 
> I may try rebooting that PC with dual-core disabled and see what happens.
> 
> Cheers,
> David 
> 
> 

Have you considered disabling Windows Vista??   ;-)

Linux or Solaris X86 should do a far better job of keeping time than 
Windows.

Richard B. Gilbert wrote:
[]
> Have you considered disabling Windows Vista??   ;-)
>
> Linux or Solaris X86 should do a far better job of keeping time than
> Windows.

Richard,

You may well be right, but there are many people today who need Windows 
for the applications they wish to run, so alternative OSes are not an 
option.  The PCs which they are buying today will, most likely, have 
Windows Vista as the version of Windows which is installed.  My aim, as 
I'm sure you will appreciate, is to help folk get as good a timekeeping 
with Windows Vista as they can already enjoy with Windows XP and earlier, 
in keeping with the philosophy of NTP to be as widely deployed as 
possible.

Cheers,
David 

On Dec 1, 8:58 am, "David J Taylor" <david-tay...@blueyonder.not-this-
bit.nor-this-bit.co.uk> wrote:
> Richard B. Gilbert wrote:
> > David J Taylor wrote:
> >> Folks,
>
> >> I'm still trying to resolve NTP on Windows Vista.  I do have a
> >> dual-core system, so I was wondering how NTP handled dual-core.  Does
> >> it
> >> discipline both cores, and is a special start-up switch required?
> >> Should I
> >> define the affinity for NTP to a single core?
>
> >> Looking at the AMD Web site, they do have a utility to sync the two
> >> cores - "AMD Dual-Core Optimizer" - under certain circumstances.  I
> >> tried to install this on Vista, but a file appears to be missing!  Has
> >> anyone got this working, and does it affect NTP?
>
> >>http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_...
>
> >> I seem to be full of questions and not answers today!
>
> >> Thanks,
> >> David
>
> > I don't see why NTP should even be aware that it's running on a
> > Dual-Core CPU.  Why should it be any different from a box with, say,
> > four CPUs?
>
> NTP on Windows uses the RDTSC instruction.  Which CPU does it read the
> time stamp counter from?  If NTP is multi-threaded, different threads
> could be run on different CPUs with different TSCs.  Yes, just the same
> issues arise with 4 CPUs, and I don't know how the Windows version of NTP
> handles the multi-processor scenario.
>
> Cheers,
> David- Hide quoted text -
>
> - Show quoted text -

You can use the START command to bind ntpd to specific processors
(this is called processor affinity on Windows). I would try running:

c:\>start /affinity 01 ntpd.exe <ntp options>

If you get different or better behavior, then it is a multi-processor
issue.

On Dec 1, 10:42 am, "David L. Mills" <mi...@udel.edu> wrote:

> The multiple-CPU nanokernel code that left here and is in the Alpha
> kernel assumes each CPU has an individual cycle counter and the timer
> interupts are vectored to a designated CPU. There is a data structure
> associated with each CPU that holds the measured current cycle counter
> scaling and offset, which is updated once each second by interprocessor
> interrrupt. A call to read the system clock lands on a j-random CPU,
> which reads the global time maintained by timer interrupts and
> interpolates according to the current CPU values.

Just curious, but is it aware that the CPU clock frequency may change
on the fly and differently for each processor for power-management
purposes?  As a result, the rate of the count by RDTSC may vary.  For
example, all multi-core AMD Opteron processors, both Barcelona
generation and the previous one.

Thanks.

David J Taylor wrote:
> Danny Mayer wrote:
>> David J Taylor wrote:
>>
>>> NTP on Windows uses the RDTSC instruction.  Which CPU does it read
>>> the time stamp counter from?  If NTP is multi-threaded, different
>>> threads could be run on different CPUs with different TSCs.  Yes,
>>> just the same issues arise with 4 CPUs, and I don't know how the
>>> Windows version of NTP handles the multi-processor scenario.
>>>
>> How do you know that NTP on Windows uses the RDTSC instruction? The
>> CPU on which the thread is running will be used to read the TSC. In
>> the case of Windows NTP definitely *is* multithreaded. It needs to be
>> to operate correctly. I cannot currently tell you how it
>> interoperates with Windows with multiprocessors. That's a research
>> topic and non-trivial at that.
> 
> Danny,
> 
> Thanks for your reply.  Perhaps my recollection is at fault here, but I 
> recall that NTP on Windows uses some interpolation technique to overcome 
> timer granularity, and that the interpolation used a CPU counter.

We are intending to implement that but we haven't done so yet.

> Now I think further into the topic, I realise that with Windows XP NTP 
> works perfectly witha dual-core AMD or Intel system (once the multi-media 
> timers are enabled for the duration), but the problem appears to be on 
> Windows Vista.  So the question I should be asking is more: "How does 
> Windows Vista differ from Windows XP so as to affect NTP, and is that 
> anything to do with multi-processors or not?".
> 
> The performance I'm seeing is definitely much poorer and, at times, it 
> looks almost like NTP is switching between two different times.  For 
> example, look at yesterday around 10:00 UTC.
> 
>   http://www.david-taylor.myby.co.uk/mrtg/gemini_ntp.html
> 
> I may try rebooting that PC with dual-core disabled and see what happens.
> 
There are a couple of boot switches you can try and see if that makes a
difference. I'm not really familiar with Vista and the switch might not
help on Vista. You should also consider that it may be doing things in a
different way which could cause additional interrupts so that the clock
tick doesn't update in a regular fashion. The possibilities are endless.
 Time for a support call to Microsoft? I know you don't have 8 hours to
remain on hold.

There is one other thing that needs to be considered. This is a 64-bit
system> In that case it's possible that the code may need to be changed
to deal with it properly. For example using the VS 2005 compiler I have
found that it uses a 64-bit integer instead of 32-bit integer for
time_t. This could affect the quality of the results, it's hard to say.

> Cheers,
> David 
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 

Danny Mayer wrote:
> David J Taylor wrote:
[]
>> Thanks for your reply.  Perhaps my recollection is at fault here,
>> but I recall that NTP on Windows uses some interpolation technique
>> to overcome timer granularity, and that the interpolation used a CPU
>> counter.
>
> We are intending to implement that but we haven't done so yet.

Thanks for your reply, Danny.  Ah, my mistake - I was sure it was already 
included!

[]
> There are a couple of boot switches you can try and see if that makes
> a difference. I'm not really familiar with Vista and the switch might
> not help on Vista. You should also consider that it may be doing
> things in a different way which could cause additional interrupts so
> that the clock tick doesn't update in a regular fashion. The
> possibilities are endless. Time for a support call to Microsoft? I
> know you don't have 8 hours to remain on hold.

I was trying to switch off one core in the BIOS but I don't seem to have 
that choice.  The boot is rather different now, and no longer is there a 
boot.ini to edit.  What documentation I can find mentions "number of 
processors" and not "number of cores".  I'm unsure if this is significant 
or not.

> There is one other thing that needs to be considered. This is a 64-bit
> system> In that case it's possible that the code may need to be
> changed to deal with it properly. For example using the VS 2005
> compiler I have found that it uses a 64-bit integer instead of 32-bit
> integer for time_t. This could affect the quality of the results,
> it's hard to say.

The version I'm testing is the 32-bit version of Vista, albeit on a 64-bit 
capable CPU.  64-bit can be a pain though for subtle errors, I appreciate.

I didn't think that a 64-bit version of NTP was included in the Meinberg 
distribution.  When I looked briefly at the Windows port in: 
ntp-4.2.4p4\ports\winnt\ntp.dsw  I found that VS2005 needed to convert the 
format of some of the files - so it looked as if it might be for an older 
version of Visual Studio.  I can't build NTP because the openssl 
definitions appear to be missing from the download, and I got this error 
as well:

BSCMAKE: error BK1506 : cannot open file '.\debug\nt_clockstuff.sbr': No 
such file or directory



Comments?



Cheers,
David

Guys,

David J Taylor wrote:
> The Windows implementation does try to provide granularity within the
> tick, but I have no idea how the Meinberg port I'm using handles
> multi-processors.  Checking.  I see the routine: nt_clockstuff.c mentions
> that how to handle multi-processors is not yet decided, but that seems
> very old code (year 2000).  I can't find the RDTSC instruction anywhere in
> version ntp-4.2.4p4.  So I'm a bit stuck right now!

I think a few notes are required here.

The ntpd port for Windows does interpolate (or extrapolate?) between the
timer ticks. This has been in the NTP code base for a long time and has
_not_ been invented by Meinberg. And, just to recall, there is no "Meinberg
port", there is just "precompiled by Meinberg" version which is based on
the standard code.

Timer tick interpolation is not based directly on RDTSC. It uses the Windows
Performance Counter API (QueryPerformanceCounter/QueryPerformanceFrequency)
to do so. Those API calls are implemented in the Hardware Abstraction Layer
(HAL), so the exact way how it works depends on which of the different HALs
shipped with the OS is actually installed.

AFAIK recent versions of Windows come with a couple of HAL implementations,
which can use different counters (HPET or whatever) to implement the
Performance Counter. Earlier versions (e.g. WNT/W2K) came with only 2 HALs.
One was installed on single processor systems and used the standard timer
chip (1.9 MHz clock rate) to implement the performance counter. The other
one was installed by default on SMP machines or machines with dual core CPU
(which in fact is similar to SMP) and used the CPU TSC to implement the
performance counter.

While on legacy multiprocessor systems the CPU clocks (and thus the TSC) may
differ for each CPU, I'm _assuming_ that multicore CPUs are clocked by the
same source, so the TSCs should runs synchrounously.

Finally, the Windows port of ntpd also calls a Windows API to set the thread
affinty for the clock interpolation thread to the first CPU, so it should
not be required to specify a certain CPU to run on, as proposed by Ryan.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> I think a few notes are required here.
>
> The ntpd port for Windows does interpolate (or extrapolate?) between
> the timer ticks. This has been in the NTP code base for a long time
> and has _not_ been invented by Meinberg. And, just to recall, there
> is no "Meinberg port", there is just "precompiled by Meinberg"
> version which is based on the standard code.

I should have said "Meinberg package", and I did not say that you had 
invented the interpolation, but thanks for clarifying that point.

> Timer tick interpolation is not based directly on RDTSC. It uses the
> Windows Performance Counter API
> (QueryPerformanceCounter/QueryPerformanceFrequency) to do so. Those
> API calls are implemented in the Hardware Abstraction Layer (HAL), so
> the exact way how it works depends on which of the different HALs
> shipped with the OS is actually installed.

I've found the calls in the source code.  I alos use QueryPerformance in 
my own software and it's usually quite relaible.

> AFAIK recent versions of Windows come with a couple of HAL
> implementations, which can use different counters (HPET or whatever)
> to implement the Performance Counter. Earlier versions (e.g. WNT/W2K)
> came with only 2 HALs. One was installed on single processor systems
> and used the standard timer chip (1.9 MHz clock rate) to implement
> the performance counter. The other one was installed by default on
> SMP machines or machines with dual core CPU (which in fact is similar
> to SMP) and used the CPU TSC to implement the performance counter.
>
> While on legacy multiprocessor systems the CPU clocks (and thus the
> TSC) may differ for each CPU, I'm _assuming_ that multicore CPUs are
> clocked by the same source, so the TSCs should runs synchrounously.

This assumption is probably wrong, as AMD (at least) have needed to issue 
a fix to synchronise the counters on the two cores (if I understand this 
correctly):

  http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html
    => AMD Dual-Core Optimizer

There's an implication that the OS may do this providing you don't call 
RDTSC.

> Finally, the Windows port of ntpd also calls a Windows API to set the
> thread affinty for the clock interpolation thread to the first CPU,
> so it should not be required to specify a certain CPU to run on, as
> proposed by Ryan.
>
> Martin

Thanks for that clarification, Martin.  Host helpful.  Looking at the 
ntpd.exe process with Windows Task Manager under Vista, right-click Set 
Affinity, shows both CPU0 and CPU1 as being checked.  I can't see how to 
confirm this using SysInternals Process Explorer.

I'd welcome any performance comparison with my own data, or insight as to 
why the same system performs so much more poorly under Vista than under 
XP.

Cheers,
David 

Danny Mayer wrote:
> David J Taylor wrote:
>> Thanks for your reply.  Perhaps my recollection is at fault here, but I
>> recall that NTP on Windows uses some interpolation technique to overcome
>> timer granularity, and that the interpolation used a CPU counter.
> 
> We are intending to implement that but we haven't done so yet.

Huh? Danny you should know the code is already there for many years ...

>> Now I think further into the topic, I realise that with Windows XP NTP
>> works perfectly witha dual-core AMD or Intel system (once the multi-media
>> timers are enabled for the duration), but the problem appears to be on
>> Windows Vista.  So the question I should be asking is more: "How does
>> Windows Vista differ from Windows XP so as to affect NTP, and is that
>> anything to do with multi-processors or not?".
>> 
>> The performance I'm seeing is definitely much poorer and, at times, it
>> looks almost like NTP is switching between two different times.  For
>> example, look at yesterday around 10:00 UTC.

As mentioned in my other post, this may depend on which HAL is currently
used, i.e. which type of timer is being used to implement the performance
counter, and whether the timer clock frequency is constant, or not. I did
not yet have more time to play around with this.

>>   http://www.david-taylor.myby.co.uk/mrtg/gemini_ntp.html
>> 
>> I may try rebooting that PC with dual-core disabled and see what happens.
>> 
> There are a couple of boot switches you can try and see if that makes a
> difference. I'm not really familiar with Vista and the switch might not
> help on Vista. You should also consider that it may be doing things in a
> different way which could cause additional interrupts so that the clock
> tick doesn't update in a regular fashion. The possibilities are endless.
>  Time for a support call to Microsoft? I know you don't have 8 hours to
> remain on hold.
> 
> There is one other thing that needs to be considered. This is a 64-bit
> system> In that case it's possible that the code may need to be changed
> to deal with it properly. For example using the VS 2005 compiler I have
> found that it uses a 64-bit integer instead of 32-bit integer for
> time_t. This could affect the quality of the results, it's hard to say.

Shouldn't this only matter when the 32 bit time_t overflows?

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David J Taylor wrote:
>> There is one other thing that needs to be considered. This is a 64-bit
>> system> In that case it's possible that the code may need to be
>> changed to deal with it properly. For example using the VS 2005
>> compiler I have found that it uses a 64-bit integer instead of 32-bit
>> integer for time_t. This could affect the quality of the results,
>> it's hard to say.
> 
> The version I'm testing is the 32-bit version of Vista, albeit on a 64-bit 
> capable CPU.  64-bit can be a pain though for subtle errors, I appreciate.
> 

That's a problem. There are even more subtle issues when you run a
32-bit O/S on a 64-bit system. I don't think we can even try to support
that since there are likely to be too many unknowns. It's a very nasty mix.

> I didn't think that a 64-bit version of NTP was included in the Meinberg 
> distribution.  When I looked briefly at the Windows port in: 
> ntp-4.2.4p4\ports\winnt\ntp.dsw  I found that VS2005 needed to convert the 
> format of some of the files - so it looked as if it might be for an older 
> version of Visual Studio.  I can't build NTP because the openssl 
> definitions appear to be missing from the download, and I got this error 
> as well:
> 

With VS 2005, just open the dsw file and tell it to convert all the
project files. I recently add the necessary macros to the dsp files so
that I don't have to add a bunch of macros every time I pull in a new
tarball. I'm only building on VS 2005 these days. Building on VS 6 I
reserve for releasing builds.

We don't ship the OpenSSL sources due to possible export regulations.
You can download that yourself from the openssl.org site. Just follow
the build instructions for Windows. I use the nt suboption.

> BSCMAKE: error BK1506 : cannot open file '.\debug\nt_clockstuff.sbr': No 
> such file or directory
> 
hard to say why but it obviously was not compiled.

Danny

> 
> 
> Comments?

Martin Burnicki wrote:
> Guys,
> 
> David J Taylor wrote:
>> The Windows implementation does try to provide granularity within the
>> tick, but I have no idea how the Meinberg port I'm using handles
>> multi-processors.  Checking.  I see the routine: nt_clockstuff.c mentions
>> that how to handle multi-processors is not yet decided, but that seems
>> very old code (year 2000).  I can't find the RDTSC instruction anywhere in
>> version ntp-4.2.4p4.  So I'm a bit stuck right now!
> 
> I think a few notes are required here.
> 
> The ntpd port for Windows does interpolate (or extrapolate?) between the
> timer ticks. This has been in the NTP code base for a long time and has
> _not_ been invented by Meinberg.

Right. However Pete Rosin (Eckberg) and Terje Mathisen back in May had
come up with a scheme to provide additional code to improve the
interpolation. That is what is not yet in the code.

> While on legacy multiprocessor systems the CPU clocks (and thus the TSC) may
> differ for each CPU, I'm _assuming_ that multicore CPUs are clocked by the
> same source, so the TSCs should runs synchrounously.

Perhaps we need definition of the difference between multi-CPU and
multi-core how that effects the clock, TSC, etc. because that's not
entirely clear to me.

Danny

Martin Burnicki wrote:
> Danny Mayer wrote:
>> David J Taylor wrote:
>>> Thanks for your reply.  Perhaps my recollection is at fault here, but I
>>> recall that NTP on Windows uses some interpolation technique to overcome
>>> timer granularity, and that the interpolation used a CPU counter.
>> We are intending to implement that but we haven't done so yet.
> 
> Huh? Danny you should know the code is already there for many years ...

No, I was talking about Peter and Terje's additional interpolation code.

>> There is one other thing that needs to be considered. This is a 64-bit
>> system> In that case it's possible that the code may need to be changed
>> to deal with it properly. For example using the VS 2005 compiler I have
>> found that it uses a 64-bit integer instead of 32-bit integer for
>> time_t. This could affect the quality of the results, it's hard to say.
> 
> Shouldn't this only matter when the 32 bit time_t overflows?

It's hard to know. I first ran into the issue when I compiled BIND with
VS 2005 and it fell over almost immediately and it wasn't an overflow
issue. However on a 32-bit O/S on 64-bit hardware the results are really
uncertain.

Danny

Danny,

Danny Mayer wrote:
> David J Taylor wrote:
>> The version I'm testing is the 32-bit version of Vista, albeit on a
>> 64-bit
>> capable CPU.  64-bit can be a pain though for subtle errors, I
>> appreciate.
>> 
> 
> That's a problem. There are even more subtle issues when you run a
> 32-bit O/S on a 64-bit system. I don't think we can even try to support
> that since there are likely to be too many unknowns. It's a very nasty
> mix.

I don't think there's a basic problem if you run a 32 bit OS on a 64 bit
hardware. AFAIK the AMD64 platform is backward compatible with 32 bit OSs.
W2k is running fine on a AMD64 machine here, and there are absolutely no
problems.

In one of his earlier posts David mentioned that there were no problems when
he was running WXP on that machine.

I would rather expect some possible problems if you run a 64 bit OS (WXP x64
or Vista x64) on a 64 bit hardware, and then run a 32 bit application under
that 64 bit OS, if the 32 bit compatibility layer of the OS has not been
implemented properly.
 
>> I didn't think that a 64-bit version of NTP was included in the Meinberg
>> distribution.  

I don't think it would make much sense (or would be even possible) to run a
program compiled for a 64 bit target OS on a 32 bit OS, just because the
hardware is 64 bit.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Danny Mayer wrote:
[]
> With VS 2005, just open the dsw file and tell it to convert all the
> project files. I recently add the necessary macros to the dsp files so
> that I don't have to add a bunch of macros every time I pull in a new
> tarball. I'm only building on VS 2005 these days. Building on VS 6 I
> reserve for releasing builds.
>
> We don't ship the OpenSSL sources due to possible export regulations.
> You can download that yourself from the openssl.org site. Just follow
> the build instructions for Windows. I use the nt suboption.

Thanks, Danny.

I have now downloaded the OpenSSL sources, however, the file
openssl/evp.h which ntp needs is not in a directory called "openssl", but 
in a directory called "crypto".  Confusingly, in the project options you 
have a directory setting of: "$(OPENSSL)\inc32", and I see no inc32 
directory in the OpenSSL tree.  I also seem to have trouble finding the 
build instructions you mentioned.

Cheers,
David 

Martin Burnicki wrote:
> Danny,
>
> Danny Mayer wrote:
>> David J Taylor wrote:
>>> The version I'm testing is the 32-bit version of Vista, albeit on a
>>> 64-bit
>>> capable CPU.  64-bit can be a pain though for subtle errors, I
>>> appreciate.
>>>
>>
>> That's a problem. There are even more subtle issues when you run a
>> 32-bit O/S on a 64-bit system. I don't think we can even try to
>> support that since there are likely to be too many unknowns. It's a
>> very nasty mix.
>
> I don't think there's a basic problem if you run a 32 bit OS on a 64
> bit hardware. AFAIK the AMD64 platform is backward compatible with 32
> bit OSs. W2k is running fine on a AMD64 machine here, and there are
> absolutely no problems.

Agreed.

> In one of his earlier posts David mentioned that there were no
> problems when he was running WXP on that machine.

Correct.

> I would rather expect some possible problems if you run a 64 bit OS
> (WXP x64 or Vista x64) on a 64 bit hardware, and then run a 32 bit
> application under that 64 bit OS, if the 32 bit compatibility layer
> of the OS has not been implemented properly.
>
>>> I didn't think that a 64-bit version of NTP was included in the
>>> Meinberg distribution.
>
> I don't think it would make much sense (or would be even possible) to
> run a program compiled for a 64 bit target OS on a 32 bit OS, just
> because the hardware is 64 bit.
>
>
> Martin

No, I was meaning a native 64-bit version of ntp to run under 64-bit Vista 
(or XP).  I would suspect that the extra OS layer implementing the 32-bit 
calls on the 64-bit native OS would lose some accuracy.  But that's not 
the order of magnitude of the error I'm seeing.

Thanks,
David 

David,

David J Taylor wrote:
> Martin Burnicki wrote:
>> While on legacy multiprocessor systems the CPU clocks (and thus the
>> TSC) may differ for each CPU, I'm _assuming_ that multicore CPUs are
>> clocked by the same source, so the TSCs should runs synchrounously.
> 
> This assumption is probably wrong, as AMD (at least) have needed to issue
> a fix to synchronise the counters on the two cores (if I understand this
> correctly):
> 
>  
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.html
>     => AMD Dual-Core Optimizer

Seems you're right ;-)

> There's an implication that the OS may do this providing you don't call
> RDTSC.
> 
>> Finally, the Windows port of ntpd also calls a Windows API to set the
>> thread affinty for the clock interpolation thread to the first CPU,
>> so it should not be required to specify a certain CPU to run on, as
>> proposed by Ryan.
>>
>> Martin
> 
> Thanks for that clarification, Martin.  Host helpful.  Looking at the
> ntpd.exe process with Windows Task Manager under Vista, right-click Set
> Affinity, shows both CPU0 and CPU1 as being checked.  I can't see how to
> confirm this using SysInternals Process Explorer.


Hm, the process CPU affinity is not restricted to a single CPU. Ntpd has 4
active threads, and only the CPU affinity of the clock interpolation thread
is restricted to the first CPU since this is the only thread which calls
QueryPerformanceCounter() and thus potentially reads the TSC of the CPU it
is running on. The other threads may still run on either CPU.

I'm not aware of a tool which displays the CPU affinity of a single thread,
so I don't know right now how you can verify this, except by looking at the
source code.

> I'd welcome any performance comparison with my own data, or insight as to
> why the same system performs so much more poorly under Vista than under
> XP.

I've just set up a new test under Vista, so let's see.

What I can say right now is that the default tick adjustment value is 156001
instead of 156250 which it used to be on earlier Windows versions. Also the
granularity of the system clock has changed from 15.625 ms to 1 ms.

Maybe the timer tick interpolation code is not quite appropriate for these
settings.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> I've just set up a new test under Vista, so let's see.
>
> What I can say right now is that the default tick adjustment value is
> 156001 instead of 156250 which it used to be on earlier Windows
> versions. Also the granularity of the system clock has changed from
> 15.625 ms to 1 ms.
>
> Maybe the timer tick interpolation code is not quite appropriate for
> these settings.
>
>
> Martin

Martin, thanks for that interesting information.  I'd love to know if you 
see similar offsets to me, or if it's just a quirk of the system here. 
It's a test system and not a production one, so if you need anything 
tested just shout.  As you may have seen, I have been trying to get ntpd 
to compile here, but with little joy so far.

Cheers,
David 

Evandro,

Yes, the nanocode is aware that individual CPU clock rates can differ 
and vary over time. Since the only purpose is to interpolate between 
timer interrupts (Alpha) or second overflows (FreeBSD), all the code 
does is count the number of PCC cycles since the last interrupt to 
construct a divisor to scale the PCC accordinly. It does this once each 
second for every CPU.

The important thing to realize in this process is that all basic time 
functions rely on timer interrupts, where the kernel time variable is 
disciplined in phase and frequency by system calls such as adjtime() or 
ntp_adjtime(). The PCC frequency can vary due to core temperature rather 
more than the timer frequency, which (used to be and hopefully now is) 
on a different chip with constant temperature. This is why the PCC is 
used only for interpolation, not as the reference oscillator as in some 
designs.

Dave

Evandro Menezes wrote:

> On Dec 1, 10:42 am, "David L. Mills" <mi...@udel.edu> wrote:
> 
> 
>>The multiple-CPU nanokernel code that left here and is in the Alpha
>>kernel assumes each CPU has an individual cycle counter and the timer
>>interupts are vectored to a designated CPU. There is a data structure
>>associated with each CPU that holds the measured current cycle counter
>>scaling and offset, which is updated once each second by interprocessor
>>interrrupt. A call to read the system clock lands on a j-random CPU,
>>which reads the global time maintained by timer interrupts and
>>interpolates according to the current CPU values.
> 
> 
> Just curious, but is it aware that the CPU clock frequency may change
> on the fly and differently for each processor for power-management
> purposes?  As a result, the rate of the count by RDTSC may vary.  For
> example, all multi-core AMD Opteron processors, both Barcelona
> generation and the previous one.
> 
> Thanks.

David,

David J Taylor wrote:
> Martin Burnicki wrote:
> []
>> I've just set up a new test under Vista, so let's see.
>>
>> What I can say right now is that the default tick adjustment value is
>> 156001 instead of 156250 which it used to be on earlier Windows
>> versions. Also the granularity of the system clock has changed from
>> 15.625 ms to 1 ms.
>>
>> Maybe the timer tick interpolation code is not quite appropriate for
>> these settings.
>>
>>
>> Martin
> 
> Martin, thanks for that interesting information.  I'd love to know if you
> see similar offsets to me, or if it's just a quirk of the system here.
> It's a test system and not a production one, so if you need anything
> tested just shout.  As you may have seen, I have been trying to get ntpd
> to compile here, but with little joy so far.

I had made a fresh installation of Vista and forgot to disable automatic
sleep mode, so my overnight test failed and I had to run it once more over
the last hours.

The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista
x64. Data of the time synchronization performance was collected by the time
adjustment service which comes with the Meinberg driver package for
Windows. That service computes the difference between the Windows system
time and a built-in GPS170PCI card and normally disiplines the system time.
However, in order to test the accuracy of NTP the Meinberg time service was
configured just to collect data and not to apply any correnctions to the
system time.

I have run both the current NTP stable version ntp-4.2.4p4, and the current
ntp-dev version ntp-dev-4.2.5p104, configured to get the time from a GPS
controlled NTP server on the local network, which provides magnitues more
accuracy than we can see here.

Both versions of NTP showed similar dissatisfying results. The offset varies
from about 20 to more than 50 milliseconds, so there's a bias of about 30
to 40 milliseconds. See the following graph:
http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64.pdf

In order to show that it's possible to yield better results even on a 64 bit
platform I have disabled the NTP service and enabled our time adjustment
service start to discipline the system time. The results can be seen at the
end of the graph. 

In order to make the results better visible I've also generated another
graph with different scaling of the time offset:
http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64-details.pdf

Please note both NTP and our time adjustment service are simple 32 bit apps
compiled with VC6, so as a conclusion we can say that there is neither a
general problem with the 64 bit OS nor with the 64 bit hardware
architecture.

As already mentioned earlier I _assume_ there is a glitch in the NTP code
which doesn't convert or interpolate the Windows time stamps properly under
Vista.

I'll try to find out more.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> David,
[]
> I had made a fresh installation of Vista and forgot to disable
> automatic sleep mode, so my overnight test failed and I had to run it
> once more over the last hours.

Been there, done that!

> The test machine is a Intel Pentium D 3 GHz (dual core) with Windows
> Vista x64. Data of the time synchronization performance was collected
> by the time adjustment service which comes with the Meinberg driver
> package for Windows. That service computes the difference between the
> Windows system time and a built-in GPS170PCI card and normally
> disiplines the system time. However, in order to test the accuracy of
> NTP the Meinberg time service was configured just to collect data and
> not to apply any correnctions to the system time.

Understood.

> I have run both the current NTP stable version ntp-4.2.4p4, and the
> current ntp-dev version ntp-dev-4.2.5p104, configured to get the time
> from a GPS controlled NTP server on the local network, which provides
> magnitues more accuracy than we can see here.
>
> Both versions of NTP showed similar dissatisfying results. The offset
> varies from about 20 to more than 50 milliseconds, so there's a bias
> of about 30 to 40 milliseconds. See the following graph:
> http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64.pdf
>
> In order to show that it's possible to yield better results even on a
> 64 bit platform I have disabled the NTP service and enabled our time
> adjustment service start to discipline the system time. The results
> can be seen at the end of the graph.

OK, I see both versions.

> In order to make the results better visible I've also generated
> another graph with different scaling of the time offset:
> http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-x64-details.pdf
>
> Please note both NTP and our time adjustment service are simple 32
> bit apps compiled with VC6, so as a conclusion we can say that there
> is neither a general problem with the 64 bit OS nor with the 64 bit
> hardware architecture.
>
> As already mentioned earlier I _assume_ there is a glitch in the NTP
> code which doesn't convert or interpolate the Windows time stamps
> properly under Vista.
>
> I'll try to find out more.
>
> Martin

I find it difficult to judge the results in comparison with mine as the 
timescales cover a rather different range, but the message is clear - 
under Vista (your 64-bit or my 32-bit) timekeeping with NTP is orders of 
magnitude worse than it should be.  It might be interesting to try 
disabling the interpolation, and see if that improves things.  I'd try 
that here is only I could get NTP to compile with Visual Studio 2005!  If 
you have a version you want me to test on Vista 32-bits here, just let me 
know.

I do appreciate your efforts with this.

Cheers,
David 

David J Taylor wrote:
> Danny Mayer wrote:
> []
>> With VS 2005, just open the dsw file and tell it to convert all the
>> project files. I recently add the necessary macros to the dsp files so
>> that I don't have to add a bunch of macros every time I pull in a new
>> tarball. I'm only building on VS 2005 these days. Building on VS 6 I
>> reserve for releasing builds.
>>
>> We don't ship the OpenSSL sources due to possible export regulations.
>> You can download that yourself from the openssl.org site. Just follow
>> the build instructions for Windows. I use the nt suboption.
> 
> Thanks, Danny.
> 
> I have now downloaded the OpenSSL sources, however, the file
> openssl/evp.h which ntp needs is not in a directory called "openssl", but 
> in a directory called "crypto".  Confusingly, in the project options you 
> have a directory setting of: "$(OPENSSL)\inc32", and I see no inc32 
> directory in the OpenSSL tree.  I also seem to have trouble finding the 
> build instructions you mentioned.
> 

You need to run the OpenSSL build first to create that directory. Just
follow the instructions.

Danny
> Cheers,
> David 

Martin Burnicki wrote:
> 
> Hm, the process CPU affinity is not restricted to a single CPU. Ntpd has 4
> active threads, and only the CPU affinity of the clock interpolation thread
> is restricted to the first CPU since this is the only thread which calls
> QueryPerformanceCounter() and thus potentially reads the TSC of the CPU it
> is running on. The other threads may still run on either CPU.
> 
> I'm not aware of a tool which displays the CPU affinity of a single thread,
> so I don't know right now how you can verify this, except by looking at the
> source code.
> 

I have a vague recollection of seeing one, but I don't remember where.
I'll try and see what I can dig up.

Danny

Danny Mayer wrote:
[]
> You need to run the OpenSSL build first to create that directory. Just
> follow the instructions.
>
> Danny

Danny,

I'm afraid the build didn't work for me, so I tried creating a directory 
"openssl" in the ntp tree, and copied 33 header files from the OpenSSL 
tree.  Having done that, I got hundreds of compiler warnings about a 
variety of topics (but not missing files), however, a .LIB file was 
missing presumably because of the failed buld.

I find this in so many C/C++ projects - warnings which the author says to 
"ignore those".  But the missing Lib file is a fatal error.  I really 
would prefer not to write this off, so can you please:

- tell me how the environment should be defined so that there is no need 
to create the  "openssl" directory and copy the headers there (I had 
expected an entry in the ntp project definition).  What is $(OPENSSL) on 
your system?  Perhaps I can match it on mine?

- send the missing LIB file?  It's \out32dll\libeay32.lib

I'd love to help on this, but I am struggling!

Cheers,
David 

Martin Burnicki <martin.burnicki@meinberg.de> writes:

[...]
> The test machine is a Intel Pentium D 3 GHz (dual core) with Windows Vista
> x64. Data of the time synchronization performance was collected by the time
> adjustment service which comes with the Meinberg driver package for
> Windows. That service computes the difference between the Windows system
> time and a built-in GPS170PCI card and normally disiplines the system time.
> However, in order to test the accuracy of NTP the Meinberg time service was
> configured just to collect data and not to apply any correnctions to the
> system time.
[...]
What you probably need in addition is a random burst of CPU load (These new
cores change voltage and clock rate depending on the load). I don't know
a script for that, but manipulating a larger image in some image processor
usually does the job...

Regards,
Ulrich

David,

David J Taylor wrote:
> I find it difficult to judge the results in comparison with mine as the
> timescales cover a rather different range, but the message is clear -
> under Vista (your 64-bit or my 32-bit) timekeeping with NTP is orders of
> magnitude worse than it should be.  It might be interesting to try
> disabling the interpolation, and see if that improves things.  I'd try
> that here is only I could get NTP to compile with Visual Studio 2005!  If
> you have a version you want me to test on Vista 32-bits here, just let me
> know.

There's now a new graph recorded under 32 bit Vista:
http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-32.pdf

The first section is with maxpoll 6, and in the second part maxpoll has been
reduced to 4, which does not seem to eliminate the reason for the jitter,
but the magnitude.
 
> I do appreciate your efforts with this.

Thanks. We all want NTP to discipline even the Windows system time as good
as possible.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hi Ulrich,

Ulrich Windl wrote:
> Martin Burnicki <martin.burnicki@meinberg.de> writes:
> 
> [...]
>> The test machine is a Intel Pentium D 3 GHz (dual core) with Windows
>> Vista x64. Data of the time synchronization performance was collected by
>> the time adjustment service which comes with the Meinberg driver package
>> for Windows. That service computes the difference between the Windows
>> system time and a built-in GPS170PCI card and normally disiplines the
>> system time. However, in order to test the accuracy of NTP the Meinberg
>> time service was configured just to collect data and not to apply any
>> correnctions to the system time.
> [...]
> What you probably need in addition is a random burst of CPU load (These
> new cores change voltage and clock rate depending on the load). I don't
> know a script for that, but manipulating a larger image in some image
> processor usually does the job...

You're right. That's an additional constraint which has to be taken into
account. The bad thing is that those tests are pretty time-consuming ...

Regards,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> There's now a new graph recorded under 32 bit Vista:
> http://www.meinberg.de/download/ntp/graphs/ntp-dev-4.2.5p104-windows-vista-32.pdf
>
> The first section is with maxpoll 6, and in the second part maxpoll
> has been reduced to 4, which does not seem to eliminate the reason
> for the jitter, but the magnitude.
>
>> I do appreciate your efforts with this.
>
> Thanks. We all want NTP to discipline even the Windows system time as
> good as possible.
>
> Martin

Thanks, Martin.  The graph looks a little more like mine now - almost like 
two frequencies beating together with periods of large swing followed by 
periods of stability.  It surprises me that in the maxpoll = 6 part, the 
"tick" value doesn't swing more.  I would have thought that once an offset 
near zero was reached, the tick value would start to swing between the two 
best values.

Can you try with the interpolation removed, in case it shows anything?

Cheers,
David 

David,

Don't look in the NTP distribution for interpolation code; that's in the 
kernel, for the Alpha the nanokernel code. All the code there, by the 
way, is in C for portability. By the way, I see that code is no longer 
available via http, only anonymous ftp.

Dave

David J Taylor wrote:
> David L. Mills wrote:
> 
>>David,
>>
>>The multiple-CPU nanokernel code that left here and is in the Alpha
>>kernel assumes each CPU has an individual cycle counter and the timer
>>interupts are vectored to a designated CPU. There is a data structure
>>associated with each CPU that holds the measured current cycle counter
>>scaling and offset, which is updated once each second by
>>interprocessor interrrupt. A call to read the system clock lands on a
>>j-random CPU, which reads the global time maintained by timer
>>interrupts and interpolates according to the current CPU values.
>>
>>I don't know if Vista attempts to provide granularity within the tick;
>>but if it does, I would expect it to use a similar strategy.
>>
>>Dave
> 
> 
> Thanks for that, Dave.  I haven't needed to touch assembler for a little 
> wile now, so I'm not up to speed on whether the various Intel and AMD 
> architectures (hyper-threading, dual/quad-core, and physical 
> multi-processor etc.) provide access to every cycle counter from a single 
> CPU or executing thread.
> 
> The Windows implementation does try to provide granularity within the 
> tick, but I have no idea how the Meinberg port I'm using handles 
> multi-processors.  Checking.  I see the routine: nt_clockstuff.c mentions 
> that how to handle multi-processors is not yet decided, but that seems 
> very old code (year 2000).  I can't find the RDTSC instruction anywhere in 
> version ntp-4.2.4p4.  So I'm a bit stuck right now!
> 
> Cheers,
> David 
> 
> 

David L. Mills wrote:
> David,
>
> Don't look in the NTP distribution for interpolation code; that's in
> the kernel, for the Alpha the nanokernel code. All the code there, by
> the way, is in C for portability. By the way, I see that code is no
> longer available via http, only anonymous ftp.
>
> Dave

Dave,

There is /an/ interpolation in the Windows code as well - in 
nt_clockstuff.c.  Obviously not what you have in the Alpha kernel.

I got the source from Udel via http:

  http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/
    => ntp-4.2.4p4.tar.gz

Cheers,
David 

David J Taylor wrote:
> David L. Mills wrote:
>> David,
>>
>> Don't look in the NTP distribution for interpolation code; that's in
>> the kernel, for the Alpha the nanokernel code. All the code there, by
>> the way, is in C for portability. By the way, I see that code is no
>> longer available via http, only anonymous ftp.
>>
>> Dave
> 
> Dave,
> 
> There is /an/ interpolation in the Windows code as well - in
> nt_clockstuff.c.  Obviously not what you have in the Alpha kernel.

David (J. Taylor),

Please take care. You and Dave (L. Mills) are talking about completely
different things here.

In most cases the OS system clock is counting timer ticks to keep the time.
When an application reads the system time then a good OS returns the
current time with a higher resolution than the timer tick interval, i.e. it
returns a time based on the current timer tick count plus the current value
of the time counter register which gives an idea whether time is at the
beginning or the end of a timer tick interval, and thus is responsible for
the resolution of the system clock, depending on the clock rate of that
counter.

The details depend on which time counter register is used for this purpose.
If there's just a single register, e.g. in the chipset, then it's pretty
easy to deal with it.

If a CPU register is used to determine the time between 2 timer ticks and
you have a SMP or multicore system then you must take care that either the
time stamp is always taken from the same CPU/core, or the timers in all
CPUs/cores are synchronized to each other so that it doesn't matter which
CPU is being read.

The nanokernel code mentioned by Dave takes care about registers in multiple
CPUs, but as its name implies it is some code which needs to run in the
kernel to be able to access the registers and provide a proper API to the
application.

If the M$ developers would pick up Dave's code and integrate it into the
Windows kernel then Windows would probably be a good time keeper as well.

However, Windows does not evaluate the current counter value at all, so the
system time is just derived from the number of timer ticks, increases only
when a timer tick occurs, and thus the resolution of the clock is limited
to the timer tick interval (Vista seems to be slightly different, though). 

Since the Windows kernel source is not available, we can not apply Dave's
code to increase the resolution of the Windows system clock since we are
unable to modify the timekeeping code in the Windows kernel.

That's why NTP uses a hack to try to increase the resolution from user
space. Of course this is not as reliable and exact as a proper
implementation in the kernel could be. However, it's better than just use
the resolution provided by Windows. Also, as-is, the interpolated system
time is not available to other applications.

The clock interpolation code for Windows can only use standard API calls,
e.g. the PerformanceCounter API. How this API behaves in detail depends on
how it is implemented in the HAL. It can either use the CPUs' TSC
registers, or use any other register which may be available with certain
chipsets. This code does not try to synchronize the TSCs on different CPUs,
it just tries to run always on the same CPU in order to avoid glitches due
to different TSC values on different CPUs.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> David (J. Taylor),
>
> Please take care. You and Dave (L. Mills) are talking about completely
> different things here.
[]
> Martin

Thanks, Martin.  Yes, I'm aware of the difference, but as both topics 
currently have the same name the source of the confusion remains.  Perhaps 
we need a new name for what's done in Windows - "user-mode tick 
interpolation" perhaps as opposed to "kernel-mode interpolation"?

Cheers,
David 

On Dec 3, 2:28 pm, "David L. Mills" <mi...@udel.edu> wrote:

> Yes, the nanocode is aware that individual CPU clock rates can differ
> and vary over time. Since the only purpose is to interpolate between
> timer interrupts (Alpha) or second overflows (FreeBSD), all the code
> does is count the number of PCC cycles since the last interrupt to
> construct a divisor to scale the PCC accordinly. It does this once each
> second for every CPU.

Forgive me for my persistence, but on some OS'es, such as Windows and
Linux, the CPU frequency of a certain core can vary by more than 2x,
depending on system load and the power savings profile.  for example,
I had one such server with 2 dual-core processors and its frequency
could vary between 1GHz when the system was idling to 2.2GHz under
heavy load.  The CPU clock governor could go between both extremes
within the same second.  Can the code handle such situation?

Thanks for your reply.

David J Taylor wrote:
> Danny Mayer wrote:
> []
>> You need to run the OpenSSL build first to create that directory. Just
>> follow the instructions.
>>
>> Danny
> 
> Danny,
> 
> I'm afraid the build didn't work for me, so I tried creating a directory 
> "openssl" in the ntp tree, and copied 33 header files from the OpenSSL 
> tree.  Having done that, I got hundreds of compiler warnings about a 
> variety of topics (but not missing files), however, a .LIB file was 
> missing presumably because of the failed buld.
> 

No, you extract the openssl files to a directory at the same level as
ntp. Then you read the INSTALL.W32 file for instructions on how to build
openssl. I don't build with the assembler code.

> I find this in so many C/C++ projects - warnings which the author says to 
> "ignore those".  But the missing Lib file is a fatal error.  I really 
> would prefer not to write this off, so can you please:
> 

Had you actually built the openssl code first you would not have gotten
that error.

> - tell me how the environment should be defined so that there is no need 
> to create the  "openssl" directory and copy the headers there (I had 
> expected an entry in the ntp project definition).  What is $(OPENSSL) on 
> your system?  Perhaps I can match it on mine?
> 
> - send the missing LIB file?  It's \out32dll\libeay32.lib
> 
> I'd love to help on this, but I am struggling!
> 

You were supposed to read the instructions included with openssl. See above.

Danny
> Cheers,
> David 

Danny Mayer wrote:
[]
> No, you extract the openssl files to a directory at the same level as
> ntp. Then you read the INSTALL.W32 file for instructions on how to
> build openssl. I don't build with the assembler code.

Danny, thanks for your "encouragement" - I did do all this, of course, but 
I will pursue this further.

>> I find this in so many C/C++ projects - warnings which the author
>> says to "ignore those".  But the missing Lib file is a fatal error.
>> I really would prefer not to write this off, so can you please:
>>
>
> Had you actually built the openssl code first you would not have
> gotten that error.
[]
> Danny


That error, perhaps, but there are dozens of warnings when  you compile, 
making it impossible to judge what success you have had.  I come from a 
background where we expect software to compile with a "zero errors, zero 
warnings" result.

Cheers,
David 

Danny,

I have tried to follow the build instructions, but they fail at the 
command:

  call ms\do_ms

at the line:

___________________________________
D:\Temp\NTP\openssl-0.9.8g.tar\openssl-0.9.8g>perl util\mk1mf.pl no-asm 
VC-CE  1
>ms\ce.mak
%OSVERSION% is not defined at util/pl/VC-32.pl line 41.
Compilation failed in require at util\mk1mf.pl line 138.

___________________________________

and then when running:

  nmake -f ms\ntdll.mak

I get:

___________________________________
        cl /Fotmp32dll\cversion.obj  -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 
/W3 /WX
 /Gs0 /GF /Gy 
/nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -
DDSO_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_USE_
APPLINK -I. 
/Fdout32dll -DOPENSSL_NO_CAMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5
 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_TLSEXT -DOPENSSL_NO_KRB5 -DOPENSSL_NO_DYNAMIC_EN
GINE -D_WINDLL  -DOPENSSL_BUILD_SHLIBCRYPTO -DMK1MF_BUILD -DMK1MF_PLATFORM_VC_WI
N32 -c .\crypto\cversion.c
cversion.c
..\crypto\cversion.c(105) : error C2220: warning treated as error - no 
'object' f
ile generated
..\crypto\cversion.c(105) : warning C4129: 'T' : unrecognized character 
escape se
quence
..\crypto\cversion.c(105) : warning C4129: 'N' : unrecognized character 
escape se
quence
..\crypto\cversion.c(105) : warning C4129: 'o' : unrecognized character 
escape se
quence
..\crypto\cversion.c(105) : warning C4129: '/' : unrecognized character 
escape se
quence
NMAKE : fatal error U1077: '"E:\Program Files\Microsoft Visual Studio 
8\VC\BIN\c
l.EXE"' : return code '0x2'
Stop.
___________________________________

Errors like this in (I believe) released software just leave me stuck, I'm 
afraid.  Yes, I appreciate you didn't write this code or the command 
procedure.

Cheers,
David 

>>> In article <blM6j.60093$c_1.27841@text.news.blueyonder.co.uk>, "David J Taylor" <david-taylor@blueyonder.not-this-bit.nor-this-bit.co.uk> writes:

David> That error, perhaps, but there are dozens of warnings when you
David> compile, making it impossible to judge what success you have had.  I
David> come from a background where we expect software to compile with a
David> "zero errors, zero warnings" result.

I'd like that too.  And we are slowly working on it.  And the biggest source
of warnings in the beast come from the OpenSSL headers.

And there are places where we quiet warnings for one compiler/platform and
they spring up on another compiler/platform.

It is tricky...
-- 
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org  - be a member!

David J Taylor wrote:
> Danny Mayer wrote:
> []
> 
>>No, you extract the openssl files to a directory at the same level as
>>ntp. Then you read the INSTALL.W32 file for instructions on how to
>>build openssl. I don't build with the assembler code.
> 
> 
> Danny, thanks for your "encouragement" - I did do all this, of course, but 
> I will pursue this further.
<snip>
> 
> That error, perhaps, but there are dozens of warnings when  you compile, 
> making it impossible to judge what success you have had.  I come from a 
> background where we expect software to compile with a "zero errors, zero 
> warnings" result.

That can be extremely difficult to achieve over multiple platforms and 
compilers.
It is made more difficult because various compiler accept different 
deviations from the standard.  I believe that gcc is notorious for that 
and there may well be others.

In the days when I was porting Unixish C code to OpenVMS, I used the 
compiler options that demanded "maximum rectitude" for compliance with 
the then ANSI standard. (I believe the standard changed several times 
since I last did this.)  This found a couple of actual bugs and quite a 
bit of what I considered "sleazy coding" which I did my best to clean 
up.  I added zillions of missing function declarations, corrected 
function declarations that falsely claimed that a function returned 
something that it did not or vice versa. . . .

Richard B. Gilbert wrote:
[]
> That can be extremely difficult to achieve over multiple platforms and
> compilers.

Multi-platform must make zero warnings many times more difficult - I can 
appreciate that.

> It is made more difficult because various compiler accept different
> deviations from the standard.  I believe that gcc is notorious for
> that and there may well be others.

Standards - don't you love it when there are so many to choose from!

> In the days when I was porting Unixish C code to OpenVMS, I used the
> compiler options that demanded "maximum rectitude" for compliance with
> the then ANSI standard. (I believe the standard changed several times
> since I last did this.)  This found a couple of actual bugs and quite
> a bit of what I considered "sleazy coding" which I did my best to
> clean up.  I added zillions of missing function declarations,
> corrected function declarations that falsely claimed that a function
> returned something that it did not or vice versa. . . .

I know I much prefer the far fewer variants of Windows compared to the 
multiplicity of versions of Linux - people were demanding exactly this 
version of that release with those options.  Oh, and they had different 
package mechanisms as well!  Not good for a very small software team.

Actually having two different teams working to the same document can lead 
to good results, though.  I recall how the folks in VMS writing the 
equivalent of "chkdsk" would check disks produced by the OS writers, and 
find how different folk had interpreted different fields.  I try for 
clarity rather than cleverness when coding.  I may even have to maintain 
the code myself!

Cheers,
David 

David J Taylor wrote:
> Richard B. Gilbert wrote:
> []
> 
>>That can be extremely difficult to achieve over multiple platforms and
>>compilers.
> 
> 
> Multi-platform must make zero warnings many times more difficult - I can 
> appreciate that.
> 
> 
>>It is made more difficult because various compiler accept different
>>deviations from the standard.  I believe that gcc is notorious for
>>that and there may well be others.
> 
> 
> Standards - don't you love it when there are so many to choose from!
> 
> 
>>In the days when I was porting Unixish C code to OpenVMS, I used the
>>compiler options that demanded "maximum rectitude" for compliance with
>>the then ANSI standard. (I believe the standard changed several times
>>since I last did this.)  This found a couple of actual bugs and quite
>>a bit of what I considered "sleazy coding" which I did my best to
>>clean up.  I added zillions of missing function declarations,
>>corrected function declarations that falsely claimed that a function
>>returned something that it did not or vice versa. . . .
> 
> 
> I know I much prefer the far fewer variants of Windows compared to the 
> multiplicity of versions of Linux - people were demanding exactly this 
> version of that release with those options.  Oh, and they had different 
> package mechanisms as well!  Not good for a very small software team.
> 
> Actually having two different teams working to the same document can lead 
> to good results, though.  I recall how the folks in VMS writing the 
> equivalent of "chkdsk" would check disks produced by the OS writers, and 
> find how different folk had interpreted different fields.  I try for 
> clarity rather than cleverness when coding.  

An excellent goal.

>I may even have to maintain 
> the code myself!
> 

Few of us are lucky enough to find someone else willing/able to maintain 
our code!!  I always felt that if something needed maintenance, nobody 
else was going to do it.  I tried to write code that I would be 
willing/able to maintain.  I  would expect to be able to maintain 
FORTRAN code I wrote thirty years ago.  I used meaningful variable names 
and commented liberally.  I preferred the simple and direct to the 
clever and obscure.

David J Taylor wrote:
> That error, perhaps, but there are dozens of warnings when  you compile, 
> making it impossible to judge what success you have had.  I come from a 
> background where we expect software to compile with a "zero errors, zero 
> warnings" result.
> 

I don't work on OpenSSL or you wouldn't get any though you might well do
so with VS 2005.

You get no errors or warnings if you if you build software that I have
been paid to get to work, which is why you will get warnings for NTP.

Danny

> Cheers,
> David 
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
> 

Harlan Stenn wrote:
>>>> In article <blM6j.60093$c_1.27841@text.news.blueyonder.co.uk>, "David J Taylor" <david-taylor@blueyonder.not-this-bit.nor-this-bit.co.uk> writes:
> 
> David> That error, perhaps, but there are dozens of warnings when you
> David> compile, making it impossible to judge what success you have had.  I
> David> come from a background where we expect software to compile with a
> David> "zero errors, zero warnings" result.
> 
> I'd like that too.  And we are slowly working on it.  And the biggest source
> of warnings in the beast come from the OpenSSL headers.
> 

And I get absolutely none when I build BIND9.

Danny

> And there are places where we quiet warnings for one compiler/platform and
> they spring up on another compiler/platform.
> 
> It is tricky...

David J Taylor wrote:
> Danny,
> 
> I have tried to follow the build instructions, but they fail at the 
> command:
> 
>   call ms\do_ms
> 

Start from the beginning. Delete everything and then reexport the
compressed tar file. The top-level directory (openssl-0.9.8g) should be
at the same level as the version of NTP that you are going to use.

Run the following lines at the command-line prompt when you have cd to
openssl-0.9.8g:
>perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
>ms\do_nt
>nmake -f ms\ntdll.mak

and you are done.

Danny

Richard B. Gilbert wrote:
> David J Taylor wrote:
>> Danny Mayer wrote:
>> []
>>
>>> No, you extract the openssl files to a directory at the same level as
>>> ntp. Then you read the INSTALL.W32 file for instructions on how to
>>> build openssl. I don't build with the assembler code.
>>
>> Danny, thanks for your "encouragement" - I did do all this, of course, but 
>> I will pursue this further.
> <snip>
>> That error, perhaps, but there are dozens of warnings when  you compile, 
>> making it impossible to judge what success you have had.  I come from a 
>> background where we expect software to compile with a "zero errors, zero 
>> warnings" result.
> 
> That can be extremely difficult to achieve over multiple platforms and 
> compilers.
> It is made more difficult because various compiler accept different 
> deviations from the standard.  I believe that gcc is notorious for that 
> and there may well be others.
> 
> In the days when I was porting Unixish C code to OpenVMS, I used the 
> compiler options that demanded "maximum rectitude" for compliance with 
> the then ANSI standard. (I believe the standard changed several times 
> since I last did this.)  This found a couple of actual bugs and quite a 
> bit of what I considered "sleazy coding" which I did my best to clean 
> up.  I added zillions of missing function declarations, corrected 
> function declarations that falsely claimed that a function returned 
> something that it did not or vice versa. . . .

It depended whether you used VAXC or DECC. VAXC was quite sleazy.

Danny

Danny Mayer wrote:
[]
> Start from the beginning. Delete everything and then reexport the
> compressed tar file. The top-level directory (openssl-0.9.8g) should
> be at the same level as the version of NTP that you are going to use.
>
> Run the following lines at the command-line prompt when you have cd to
> openssl-0.9.8g:
>> perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
>> ms\do_nt
>> nmake -f ms\ntdll.mak
>
> and you are done.
>
> Danny

Thanks for your patience with this, Danny.  I still can't get this to 
work, but maybe I'm doing things incorrectly.  Two questions:

1 - by the same level, I take you to mean something like this, where the 
first two files in each directory are:

D:\Temp\NTP\ntp-4.2.4p4.tar\ntp-4.2.4p4\aclocal.m4

D:\Temp\NTP\openssl-0.9.8g.tar\openssl-0.9.8g\ChangeLog.0_9_7-stable_not-in-head

2 - With this structure, what directory should I specify for "prefix" 
instead of: c:/some/openssl/dir ?

Having done this, the NMAKE step fails, and the last few lines are:

________________________________________________
..
..
Copying: ./ssl/kssl.h to inc32/openssl/kssl.h
        perl util/copy.pl ms\applink.c inc32\openssl\applink.c
Copying: ms/applink.c to inc32/openssl/applink.c
        cl /Fotmp32dll\uplink.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 
/WX /G
s0 /GF /Gy 
/nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDS
O_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_SYSNAME
_WINNT -DUNICODE -D_UNICODE -DOPENSSL_USE_APPLINK -I. 
/Fdout32dll -DOPENSSL_NO_C
AMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_TLSEXT
 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_DYNAMIC_ENGINE -D_WINDLL  -c ms\uplink.c
uplink.c
ms\uplink.c(43) : error C2220: warning treated as error - no 'object' file 
generated
ms\uplink.c(43) : warning C4996: '_swprintf': swprintf has been changed to 
conform with the ISO C standard, adding an extra character count 
parameter. To use traditional Microsoft swprintf, set 
_CRT_NON_CONFORMING_SWPRINTFS.
        E:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\wchar.h(773) 
: see
 declaration of '_swprintf'
NMAKE : fatal error U1077: '"E:\Program Files\Microsoft Visual Studio 
8\VC\BIN\c
l.EXE"' : return code '0x2'
Stop.

D:\Temp\NTP\openssl-0.9.8g.tar\openssl-0.9.8g>
________________________________________________


Trying to build NTP, using the include files I copied before, then fails 
with:

________________________________________________
1>------ Build started: Project: ntpd, Configuration: Debug Win32 ------
1>Linking...
1>LINK : fatal error LNK1104: cannot open file '\out32dll\libeay32.lib'
1>Project : warning PRJ0018 : The following environment variables were not 
found:
1>$(OPENSSL)
1>Build log was saved at 
"file://d:\Temp\NTP\ntp-4.2.4p4.tar\ntp-4.2.4p4\ports\winnt\ntpd\Debug\BuildLog.htm"
1>ntpd - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped 
==========
________________________________________________


amd if I delete the copied include files, and try to rebuild NTP, it fails 
with:

________________________________________________
1>authkeys.c
1>d:\temp\ntp\ntp-4.2.4p4.tar\ntp-4.2.4p4\include\ntp_crypto.h(5) : fatal 
error C1083: Cannot open include file: 'openssl/evp.h': No such file or 
directory
________________________________________________


I hope that I am making some trivial mistake!

Thanks,
David 

Danny Mayer wrote:
> Richard B. Gilbert wrote:
> 
>>David J Taylor wrote:
>>
>>>Danny Mayer wrote:
>>>[]
>>>
>>>
>>>>No, you extract the openssl files to a directory at the same level as
>>>>ntp. Then you read the INSTALL.W32 file for instructions on how to
>>>>build openssl. I don't build with the assembler code.
>>>
>>>Danny, thanks for your "encouragement" - I did do all this, of course, but 
>>>I will pursue this further.
>>
>><snip>
>>
>>>That error, perhaps, but there are dozens of warnings when  you compile, 
>>>making it impossible to judge what success you have had.  I come from a 
>>>background where we expect software to compile with a "zero errors, zero 
>>>warnings" result.
>>
>>That can be extremely difficult to achieve over multiple platforms and 
>>compilers.
>>It is made more difficult because various compiler accept different 
>>deviations from the standard.  I believe that gcc is notorious for that 
>>and there may well be others.
>>
>>In the days when I was porting Unixish C code to OpenVMS, I used the 
>>compiler options that demanded "maximum rectitude" for compliance with 
>>the then ANSI standard. (I believe the standard changed several times 
>>since I last did this.)  This found a couple of actual bugs and quite a 
>>bit of what I considered "sleazy coding" which I did my best to clean 
>>up.  I added zillions of missing function declarations, corrected 
>>function declarations that falsely claimed that a function returned 
>>something that it did not or vice versa. . . .
> 
> 
> It depended whether you used VAXC or DECC. VAXC was quite sleazy.
> 

This was in the days when ANSI C was fairly new and VAXC was current.
VAX C was basically K&R C.  K&R allowed things that I believed no wise 
programmer should do!  Most of them "worked" but offended my sense of 
"programming aesthetics".  I used DECC and made a lot of trivial fixes 
to make it stop complaining.  The original code might have worked 
"forever" without changes but I didn't feel comfortable with it so I 
"fixed" it "my way"!  I still have a copy of the "make" that Tony Ivanov 
posted to comp.os.vms/info-vax ca. 1990.  I think I improved it a little 
and I know I found and fixed one buffer overrun.  Mine compiles without 
errors or warnings while the original had hundreds of warnings.  Mine 
works too.

David J Taylor wrote:
> Danny Mayer wrote:
> []
>> Start from the beginning. Delete everything and then reexport the
>> compressed tar file. The top-level directory (openssl-0.9.8g) should
>> be at the same level as the version of NTP that you are going to use.
>>
>> Run the following lines at the command-line prompt when you have cd to
>> openssl-0.9.8g:
>>> perl Configure VC-WIN32 --prefix=c:/some/openssl/dir
>>> ms\do_nt
>>> nmake -f ms\ntdll.mak
>> and you are done.
>>
>> Danny
> 
> Thanks for your patience with this, Danny.  I still can't get this to 
> work, but maybe I'm doing things incorrectly.  Two questions:
> 
> 1 - by the same level, I take you to mean something like this, where the 
> first two files in each directory are:
> 
> D:\Temp\NTP\ntp-4.2.4p4.tar\ntp-4.2.4p4\aclocal.m4
> 
> D:\Temp\NTP\openssl-0.9.8g.tar\openssl-0.9.8g\ChangeLog.0_9_7-stable_not-in-head
> 
No. I don't know why there's a tar directory involved here. I don't use
temp at all. My structure would look like (well you don't really want to
look at my structures since they are bizarre at best):

D:\ntp-4.2.4p4\
D:\openssl-0.9.8g\

You did extract the files didn't you?

> 2 - With this structure, what directory should I specify for "prefix" 
> instead of: c:/some/openssl/dir ?
> 
> Having done this, the NMAKE step fails, and the last few lines are:

These lines are missing.

Danny

Danny Mayer wrote:
[]
> No. I don't know why there's a tar directory involved here. I don't
> use temp at all. My structure would look like (well you don't really
> want to look at my structures since they are bizarre at best):
>
> D:\ntp-4.2.4p4\
> D:\openssl-0.9.8g\

OK, I tried with those directories

> You did extract the files didn't you?

Yes

[]
> These lines are missing.
>
> Danny

Danny,

I don't know why the lines were missing - I'll try again:


The steps you suggested before were:

(a)  perl Configure VC-WIN32 --prefix=D:/openssl/

(b)  call  ms\do_nt

(c)  nmake -f ms\ntdll.mak


The result from (a) is:
__________________________________
D:\openssl-0.9.8g>perl Configure VC-WIN32 --prefix=D:/openssl/
Configuring for VC-WIN32
    no-camellia     [default]  OPENSSL_NO_CAMELLIA (skip dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-mdc2         [default]  OPENSSL_NO_MDC2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-seed         [default]  OPENSSL_NO_SEED (skip dir)
    no-shared       [default]
    no-tlsext       [default]  OPENSSL_NO_TLSEXT (skip dir)
    no-zlib         [default]
    no-zlib-dynamic [default]
IsMK1MF=1
CC            =cl
CFLAG         =-DOPENSSL_THREADS  -DDSO_WIN32
EX_LIBS       =
CPUID_OBJ     =
BN_ASM        =bn_asm.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ASM_OBJ   =aes_core.o aes_cbc.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4_enc.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =
RMD160_OBJ_ASM=
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =perl
THIRTY_TWO_BIT mode
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined

Configured for VC-WIN32.
__________________________________


The result from (b) is:

__________________________________
D:\openssl-0.9.8g>call ms\do_nt

D:\openssl-0.9.8g>perl util\mkfiles.pl  1>MINFO

D:\openssl-0.9.8g>perl util\mk1mf.pl no-asm VC-NT  1>ms\nt.mak

D:\openssl-0.9.8g>perl util\mk1mf.pl dll no-asm VC-NT  1>ms\ntdll.mak

D:\openssl-0.9.8g>perl util\mkdef.pl libeay NT  1>ms\libeay32.def

D:\openssl-0.9.8g>perl util\mkdef.pl ssleay NT  1>ms\ssleay32.def

__________________________________


and the result from (c) is, with most of the "copying" messages removed:

__________________________________
D:\openssl-0.9.8g>nmake -f ms\ntdll.mak

Microsoft (R) Program Maintenance Utility Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.

Building OpenSSL
        perl util/mkdir-p.pl tmp32dll
created directory `tmp32dll'
        perl util/mkdir-p.pl out32dll
created directory `out32dll'
        perl util/mkdir-p.pl inc32
created directory `inc32'
        perl util/mkdir-p.pl inc32\openssl
created directory `inc32/openssl'
        perl util/copy.pl .\.\e_os.h tmp32dll\e_os.h
Copying: ././e_os.h to tmp32dll/e_os.h
        perl util/copy.pl .\crypto\cryptlib.h tmp32dll\cryptlib.h
[]
Copying: ms/applink.c to inc32/openssl/applink.c
        cl /Fotmp32dll\uplink.obj -Iinc32 -Itmp32dll /MD /Ox /O2 /Ob2 /W3 
/WX /G
s0 /GF /Gy 
/nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDS
O_WIN32 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DOPENSSL_SYSNAME
_WINNT -DUNICODE -D_UNICODE -DOPENSSL_USE_APPLINK -I. 
/Fdout32dll -DOPENSSL_NO_C
AMELLIA -DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_TLSEXT
 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_DYNAMIC_ENGINE -D_WINDLL  -c ms\uplink.c
uplink.c
ms\uplink.c(43) : error C2220: warning treated as error - no 'object' file 
gener
ated
ms\uplink.c(43) : warning C4996: '_swprintf': swprintf has been changed to 
confo
rm with the ISO C standard, adding an extra character count parameter. To 
use tr
aditional Microsoft swprintf, set _CRT_NON_CONFORMING_SWPRINTFS.
        E:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\wchar.h(773) 
: see
 declaration of '_swprintf'
NMAKE : fatal error U1077: '"E:\Program Files\Microsoft Visual Studio 
8\VC\BIN\c
l.EXE"' : return code '0x2'
Stop.

D:\openssl-0.9.8g>
__________________________________


So I'm afraid that OpenSSL does not compile "as supplied" on this system.

Cheers,
David