This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: running cygwin sshd results in unreliable timer on w2003 DC

On Wed, 11 Aug 2004 11:36:46, Andreas Baetz wrote:
>On Wed, 11 Aug 2004 10:57:50, Corinna Vinschen wrote:
>>On Aug 11 10:34, Andreas Baetz wrote:
>>> Hi,
>>> it seems there is a problem with the local clock when running cygwin sshd on a w2003 DC.
>>> [...]
>>> Problem description:
>>> We have a time server (time1) setup which gets its time from a radio clock. Above DC1 should synchronize with this server.
>>> With "w32tm /stripchart /computer:time1" the deviation to time1 is constantly shown.
>>> Without sshd started, eveything is fine. No clock difference between DC1 and time1.
>>> After starting sshd, however, the local clock rapidly deviates from time1. It seems it does slow down, about 0.5 s per sec.
>>> After stopping sshd, the clock deviation vanishes again.
>>> This occurs regardless of the existance of a local time synchronisation mechanism. I tried the built-in w32time service,
>>> as well as a windows port of ntpd. Neither is capable of syncing the local clock to time1, if sshd is started.
>>How likely is it that an sshd should actively affect the clock?  I'm
>>wondering if that's a problem with using the same tcp port or something
>>like that.
>Not very likely, I admit. 
> ...
>What I could imagine is that with the use of VMware as virtual OS Platform some interrupts might be delayed in a certain way, 
>or shared or that that the clock ticks are slowed down or "routed" through sshd or something.
>What can be reproduced, however, is that the problem only shows when sshd is running, and it shows immediately after starting sshd.
>That's why I'm asking here, because I think someone with insight into the source of sshd could have some idea.

some updates:

I have tested on 3 other DCs, 2 of them VMs and one of them real Hardware.
None of them does have this problem. So VMware could be ruled out, I think.
It must be a problem with that certain DC. It is the only one that has the PDC role, no other differences to the other machines
at the first glance (besides all of them running on different ESX servers).

I tried cygwin 1.5.6-1 and 1.5.10-3, btw. Same results.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]