Raspberry Pi 3 is faster than Rock 4C+ for DNS lookups

General
1

Hi guys,

I have two instances of PiHole with Unbound setup. However, I'm finding the old RPi3 (192.168.1.2) is consistently faster than the new Rock 4C+ (192.168.1.3) . I would have expected the performance to be at the minimum the same. Does anyone have any ideas?

Final benchmark results, sorted by nameserver performance:
 (average cached name retrieval speed, fastest to slowest)

  192.168.  1.  2 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  + Cached Name   | 0.000 | 0.003 | 0.008 | 0.002 | 100.0 |
  + Uncached Name | 0.016 | 0.111 | 0.485 | 0.095 | 100.0 |
  + DotCom Lookup | 0.011 | 0.027 | 0.215 | 0.042 | 100.0 |
  ---<O-OO---->---+-------+-------+-------+-------+-------+
                         pi.hole
                Local Network Nameserver


    1.  1.  1.  1 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0.002 | 0.004 | 0.012 | 0.002 | 100.0 |
  - Uncached Name | 0.002 | 0.063 | 0.279 | 0.072 | 100.0 |
  - DotCom Lookup | 0.005 | 0.060 | 0.231 | 0.041 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                     one.one.one.one
                    CLOUDFLARENET, US


    9.  9.  9.  9 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0.002 | 0.004 | 0.012 | 0.002 | 100.0 |
  - Uncached Name | 0.010 | 0.135 | 0.399 | 0.095 | 100.0 |
  - DotCom Lookup | 0.006 | 0.060 | 0.104 | 0.044 |  98.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                     dns9.quad9.net
                     QUAD9-AS-1, US


  192.168.  1.  3 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0.001 | 0.004 | 0.013 | 0.002 | 100.0 |
  - Uncached Name | 0.009 | 0.136 | 0.341 | 0.092 | 100.0 |
  - DotCom Lookup | 0.062 | 0.154 | 0.182 | 0.031 | 100.0 |
  ---<O-OO---->---+-------+-------+-------+-------+-------+
                       rockpi.hole
                Local Network Nameserver


    1.  0.  0.  1 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0.003 | 0.005 | 0.011 | 0.002 | 100.0 |
  - Uncached Name | 0.003 | 0.055 | 0.279 | 0.074 | 100.0 |
  - DotCom Lookup | 0.006 | 0.053 | 0.086 | 0.011 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
                     one.one.one.one
                    CLOUDFLARENET, US


    1.  1.  1.  2 |  Min  |  Avg  |  Max  |Std.Dev|Reliab%|
  ----------------+-------+-------+-------+-------+-------+
  - Cached Name   | 0.003 | 0.006 | 0.013 | 0.002 | 100.0 |
  - Uncached Name | 0.003 | 0.038 | 0.205 | 0.055 | 100.0 |
  - DotCom Lookup | 0.007 | 0.049 | 0.064 | 0.016 | 100.0 |
  ---<-------->---+-------+-------+-------+-------+-------+
               security.cloudflare-dns.com
                    CLOUDFLARENET, US
2

I have noticed the cache lookup time gets longer the longer the pihole runs.
I find a reboot fixes it.

3

So I have been able to get similar performance by changing the governor on the Rock to performance (from the default schedutil). The Pi is using ondemand. Any other setting on the Rock produces slower performance.

Even on performance mode, the DotCom lookups on the Rock seem marginally slower. Does anyone have any ideas on how to improve DotCom lookup speed?

4

I wouldn't worry much about those artificial benchmark results.
Your test results would only be comparable if you would be able to recreate the exact same conditions for a test run through either of your devices.

You should note that you are not testing Pi-hole's or a specific device's performance, but rather that of the whole DNS resolution chain, in particular when involving requests forwarded to public DNS servers.

Reported timings comprise your respective Pi-hole's own latency plus those of all upstream DNS servers involved in the resolution of a domain, as well as any latency introduced by your networking equipment (like switches or routers), which may fluctuate widely under different loads.

Furthermore, it would be difficult enough to control load on that resolution chain in your home network, and it would be impossible to exercise control once public upstreams are involved.

1 Like
5

Agree and understood. Though I have run the test like over 50 times at different times of the day and it's pretty much consistent.

The RPi system has been running for many years. The Rock is a new one I'm setting up.

I'm just wondering if there was a setting I have missed that is causing the Rock to produce slower DotCom lookups.

Was hoping someone had seen something similar and could point me in the right direction.

6

Ah, I have found the cause! In the old system, I had DoT activated with Unbound. I forgot to activate in the new system. Now, both configurations are running as expected.

Hope this helps someone in the future.