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 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.
>
>
>Corinna

Not very likely, I admit. 
I only discoverd this connection between sshd and the local time by chance after trying for several days
to get a sync'ed clock on that DC. It worked before with no problem and I never suspected sshd in the first place.
Only after remembering what I did before the clock started to act weird (installing sshd) I stopped sshd, and the clock
worked again.
As for using the same tcp port, that seems unlikely IMHO, too, since ntp uses udp 123 and sshd tcp 22. And the problem occurs
even if there is no syncing software (w32time or ntp) running and even if sshd is only listening (no open connection).

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.

Andreas


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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