On Fri, 2016-12-16 at 18:52 +0100, Matthias Fischer wrote:
Hi,
it made absolutely NO difference. Binarys were identical, too.
'configure' contains:
... # Check whether --with-pthreads was given. if test "${with_pthreads+set}" = set; then : withval=$with_pthreads; else withval="yes" fi ...
Can it be that its enabled automatically, if no option is given!? *sigh*
Yeah, it must be the default then :)
-Michael
Best, Matthias
On 16.12.2016 17:42, Michael Tremer wrote:
On Fri, 2016-12-16 at 17:39 +0100, Matthias Fischer wrote:
Hi,
As far as I can see, it uses one thread per processor as set through the init-file.
Here, the generated 'tuning.conf' contains "num-threads: 2", which is ok, the machine has two cores.
We always set that to the number of active processors, yes.
The question is, what differences would compiling with '--with-pthreads' make? This option came to my view, but I don't know if this would make anything better.
Try it out them. The number of threads will be the same but it should definitely use pthreads then which is the fastest implmentation of threads in Linux. There is a few things outside glibc, but I cannot imagine that unbound is using anything else but pthreads already.
-Michael
Best, Matthias
On 16.12.2016 17:13, Michael Tremer wrote:
What else is it using for threading right now?
On Fri, 2016-12-16 at 16:44 +0100, Matthias Fischer wrote:
Hi,
unbound 1.6.0 - with reverted commit - is running here since a few hours without seen problems so far - we'll see.
One question, being curious:
Could it make sense to compile 'unbound' using '--with-pthreads' for threading support?
I got the following in '_build.ipfire.log' right now:
... checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for PTHREAD_PRIO_INHERIT... yes checking for pthread_spinlock_t... yes checking for pthread_rwlock_t... yes checking if -pthread unused during linking... no ...
In this regard, I read https://www.unbound.net/documentation/howto_optimise.html, but I'm not so skilled in programming to judge whether this would lead to any advantages...
Best, Matthias
On 16.12.2016 12:59, Michael Tremer wrote:
Hi,
that server is not available from the internet. But that you get that IP address is enough for me. That didn't happen before.
I will revert that commit and we will see in the testing if this raises any problems again...
Best, -Michael
On Fri, 2016-12-16 at 12:47 +0100, Matthias Fischer wrote: > > > > Hi, > > On 16.12.2016 11:28, Michael Tremer wrote: > > > > > > > > > > Did you try reverting this one and test if things like > > "pakfirehub01.i.ipfire.org" resolve again? > > I just tested after adding "qname-minimisation: yes" and > "harden-below-nxdomain: yes" to '/etc/unbound/unbound.conf', but > neither > "pakfirehub01.i.ipfire.org" nor its ip-address "172.28.1.165" > answered. > > No connection through browser, ping loss on both = 100%. > > With or without, I get the following answer with 'dig': > > ... > root@ipfire: /etc/unbound # dig pakfirehub01.i.ipfire.org > > ; <<>> DiG 9.10.3-P4 <<>> pakfirehub01.i.ipfire.org > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45016 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, > ADDITIONAL: > 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;pakfirehub01.i.ipfire.org. IN A > > ;; ANSWER SECTION: > pakfirehub01.i.ipfire.org. 293 IN A 172.28.1.165 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Dec 16 12:33:28 CET 2016 > ;; MSG SIZE rcvd: 70 > ... > > Best, > Matthias >