openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: commit: openldap-guide/admin overlays.sdf
by Quanah Gibson-Mount 20 Feb '08

20 Feb '08

I think it's wrong. "each overlay's function" seems correct to me. The function of a given overlay, so possessive is correct. The function belongs to the particular overlay in question. "each overlays function" seems quite incorrect to me, as now you've made overlays plural and lost the ownership of function. "Each dog's fur" for example. Not "Each dogs fur". Try googling that and look at the suggestion. ;) --Quanah --On February 16, 2008 4:55:57 AM -0800 ghenry(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > overlays.sdf 1.26 -> 1.27 > > Log Message: > One change, picky ;-) > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/admin/?cvsroot=OpenLDAP-guide > > http://www.openldap.org/devel/cvsweb.cgi/admin/overlays.sdf?cvsroot=OpenL > DAP-guide > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

appendix-changes.sdf
by Gavin Henry 20 Feb '08

20 Feb '08

Hi All, Can I remove the monitor section in this now? Also, is it worth noting in that doc that you need to wipe indexes due in integer changes etc. from 2.4.6 to 2.4 current? Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

icu -- is it the "recommended" OpenLDAP unicode implementation?
by Xin LI 18 Feb '08

18 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'd like to get an inquiry about the state of OpenLDAP's unicode implementation. Recently there is some reports that the FreeBSD port of OpenLDAP 2.4.x will pick up icu automatically if it is installed, according to the configure script, it seems that there is no way to disable this behavior (i.e. by --disable-icu or something similar), so it seems that a patch will be necessary if the user does not want to use icu. So my question is that, is it recommended to use icu? I am thinking about making icu an mandatory dependency of the port, but I guess it would be good to ask the developers before making such changes :) Cheers, - -- Xin LI <delphij(a)delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHuP63i+vbBBjt66ARAiqcAKCuxW9xJW3qVataZpBeKVjBhbXHcQCffYy/ JhU4ZOghLdrGzYHTzQt7Ey8= =xTGY -----END PGP SIGNATURE-----

2 2

Anyone use ccache?
by Gavin Henry 18 Feb '08

18 Feb '08

Just curious, does anyone use ccache when compile/developing etc.? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 1

RE23 testing
by Quanah Gibson-Mount 17 Feb '08

17 Feb '08

Please test RE23 in preparation for OpenLDAP 2.3.41. Thanks, Quanah+ -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

12 25

Thread pool efficiency
by Howard Chu 16 Feb '08

16 Feb '08

Testing on an 8-socket AMD server with Opteron 885 dual-core processors (16 cores total) and a Sun T5120 (T2 Niagara 8 cores, 64 hardware threads) has shown that our current frontend code is performing very poorly with more than 16 server threads. E.g. on the AMD system with 16 cores allocated, performance was still slower than on the 4-socket AMD server with Opteron 875 dual-core processors (despite 2x the cores and a significant clock-speed advantage). Testing also showed that in this configuration, at least one of the 16 cores was always 100% idle. Basically, the frontend cannot hand out work fast enough to the worker threads. Rather than using a single mutex to control all accesses into the thread pool, I think we need to have separate queues per worker thread. The frontend can operate in single-producer mode where only the single listener thread is allowed to submit jobs into the pool. The workers can just access their own individual work queues, thus significantly reducing mutex contention. Ideally we would arrange things such that any data structure is only ever written by a single thread, and all other threads only perform reads against it. (And in the best case, only one other thread needs to perform that read.) By eliminating memory ownership changes and unnecessary cache line sharing, we can dramatically reduce the cache coherency traffic. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 14

RE23 final call for testing
by Quanah Gibson-Mount 15 Feb '08

15 Feb '08

A few issues were identified in the last round of testing. If people could test again with current RE23 CVS that would be much appreciated. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

8 12

RE24 final call for testing
by Quanah Gibson-Mount 14 Feb '08

14 Feb '08

A few issues were identified in the last round of testing. If people could test again with current RE24 CVS that would be much appreciated. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

6 5

Re: thread pools, performance
by Howard Chu 14 Feb '08

14 Feb '08

Rick Jones wrote: > There are definitely interrupt coalescing settings available with tg3-driven > cards, as well as bnx2 driven ones: > > ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt Yep, that helped. Raising rx-usecs from default 20 to 1000, and rx-frames from default 5 to 100, I'm getting 43k auths/sec with back-null (in 4 separate thread pools) and the core fielding the interrupts is only about 80% busy now instead of 100%. I'm afraid my load generators may be maxed out now, because I can't seem to drive up the load on the server any higher even though there's more idle CPU. The current code in HEAD (with only 1 thread pool) is reaching 36k auths/sec with back-null, so it's actually not far off from my experimental peak rate. Considering that HEAD was at 25k/sec last week (and now in 2.4.6) that's pretty decent. With back-bdb and 1 million users I'm getting 26.1k/sec with plaintext passwords (up from 19.3k/sec last week). With {SSHA} passwords that drops to 25.7k/sec (~1.5% difference). I have to put this tinkering on hold for a bit, to run some authrate tests against ActiveDirectory on this machine (using W2K3sp2 X64). Later on we'll do a W2K3 OpenLDAP build for comparison as well. Should be entertaining... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

7 22

Re: RE24 testing
by Luca Scamoni 13 Feb '08

13 Feb '08

Passes on CentOS 4.6 and CentoOS 5.1 (i686 and virtual machines) I had only one run in which test050 seemed to have been gone in a sort of loop on a CentOS 4 VM, but I've not been able to reproduce it in more than 20 runs of the test. Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel