Mail Archives: cygwin/2015/02/25/13:57:14
John Hein wrote at 11:15 -0700 on Feb 25, 2015:
> Corinna Vinschen wrote at 09:56 +0100 on Feb 25, 2015:
> > On Feb 24 16:03, John Hein wrote:
> > > Corinna Vinschen wrote at 22:13 +0100 on Feb 24, 2015:
> > > > Hi Roger,
> > > >
> > > > On Feb 24 19:55, Roger Orr wrote:
> > > > > Hello Corinna,
> > > > > It seems slightly faster than the previous patch and I've not noticed a
> > > > > downside yet.
> > > > >
> > > > >
> > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150220 15:47:55 i686
> > > > > Cygwin:
> > > > >
> > > > > ~37ms to run echo.exe from Windows command prompt
> > > > > ~60ms to run .\id.exe -a from Windows command prompt
> > > > >
> > > > > CYGWIN_NT-6.1-WOW LCLDN-DEV24 1.7.35s(0.286/5/3) 20150223 21:02:38 i686
> > > > > Cygwin:
> > > > >
> > > > > ~35ms to run echo.exe from Windows command prompt
> > > > > ~53ms to run .\id.exe -a from Windows command prompt
> > > >
> > > > That's a nice result.
> > > >
> > > > However, I don't quite understand this result for the older DLL.
> > > > Weren't you reporting >4 secs as startup time from 1.7.35?!?
> > > >
> > > > On another note:
> > > >
> > > > I just uploaded a new developer snapshot (2015-02-24). This snapshot
> > > > should improve mkpasswd/mkgroup or, generally speaking, enumerating AD
> > > > accounts, a lot. Can you give it a try?
> > > >
> > > > While you're at it, does the new snapshot still stop after 3.5K accounts
> > > > even though you think there are 8K accounts? If so, I'd be interested
> > > > to investigate this further. The reason is, while testing my today's
> > > > performance improvements, I stumbled over a bug in my code which also
> > > > resulted in enumerating less accounts as desired. So I'm not entirely
> > > > sure your problem isn't related to a bug either.
> > >
> > > That mkpasswd symptom was reported by me
> >
> > Really? This is the first time I see your email address on this ML, and
> > there's no name connected to it, so I don't even know if you're usually
> > writing under another email address. At least a forename would be nice...
>
>
> Bah... sorry, you should get the name in this response.
>
>
> > > (well, maybe others, too).
> > > I'm running it again, but it's still very slow, AFAICS.
> >
> > It shouldn't. It performs only one LDAP call now per 100 accounts,
> > If that's still slow in your environment, I don't see any way to
> > speed this up any further.
> >
> > > I'll report
> > > how long it took when / if it finishes.
> > >
> > > New issue with recent snaps:
> > >
> > > Running the 20150224 (and *23) snapshot produces the following on Win
> > > XP (yes, I know) if cygserver is running:
> >
> > Sidenote: I'm contemplating to stop supporting XP end of this year.
>
> I'm thinking it's either related to XP or _something_ with the
> particular XP box I'm using (when logged in on the domain, I can't
> disable many group policy things or temporarily inhibit AV, so it's
> harder to find/eliminate something to pin blame on - certainly may not
> be something the latest cygwin is doing when running on XP in a
> "large" AD domain).
>
> I went to a win 7 box and the 2/24 snap makes mkpasswd -d run in 33
> seconds and enumerates all 8016 entries. 37 seconds with the 2/25
> snap.
>
> And win 7 doesn't get the 'wrong arg.type' error with the same 2/24
> cygwin1.dll for whatever reason.
>
>
> > > $ /usr/sbin/syslog-ng -F
> > > 1 [main] syslog-ng 5776 C:\cygwin\usr\sbin\syslog-ng.exe: *** fatal error - Fetching account info from cygserver with wrong arg.type 2
> >
> > Try the snapshot I just uploaded (2015-02-25). I forgot a tiny, but
> > crucial statement in the code when I changed that code two days ago.
> > That should be fixed now.
> >
> > > tcsh still taking a long time here (also XP - 3+ minutes with
> > > cygserver running). bash & dash much quicker.
> >
> > Works very quickly for me. Problem is, I don't know anything about
> > your environment. Are you working remote or in an office? How many
> > groups are in your user token? What is the result of this funny
> > little statement Dennis created:
> >
> > cmd /v:on /c "echo !TIME! & C:\cygwin64\bin\mintty.exe /bin/echo "test" & echo !TIME!"
>
> On win7: that command takes .17, .44, .48, .53 sec between 1st & 2nd time stamp
>
> That had 'db' only for passwd/group in nsswitch.conf, no cygwin procs
> running including cygserver.
>
>
> On problematic winxp box:
> [passwd, group, db_shell: 'files db', 'files db' & /bin/dash]
> 16.83, 17.03, 24.80, 28.79, 27.99, 27.39 sec
>
> [passwd, group, db_shell: db, db & /bin/dash]
> 23.51, 27.91, 28.78 sec
>
> Any trials using /bin/tcsh without disabling complete.tcsh take "a
> really long time" (TM)... from minutes with 2/25 snap to 10s of
> minutes with 1.7.34. I mentioned this in another thread (and
> strace sometimes showed 5 minute gaps around forks).
One further test with the 'cmd ... mintty.exe' command.
I started cygserver on the 'problematic winxp' box.
Then immediately ran the mintty.exe test after starting
the cygserver service - it took .08 sec - then .15 and .14.
Would be interesting if there are other people who could report on
experiences using 1.7.34 and later on XP boxes in an AD environment.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -