Correct. The payload of DNS requests is tiny compared to, say requesting a webpage. So there might not be a huge decrease of bandwidth usage reduction. However, having 66.6% less DNS requests is still a win. The router/gateway doesn’t have to work that hard because of the dropped requests.
It isn’t so much about the payload of the DNS requests, but about the content that would have been loaded if the DNS request hadn’t been blocked.
If you load a page that has 100kB of useful information, but 1MB of banner ads and trackers … you’ve blocked a lot more than 66%. But if you block 1MB of banner ads on a page that hosts a 200MB video, you’ve blocked a lot less.
Also a 66% blocked percentage seems very high. I have installed pihole on 2 networks, and I’m seeing 1.7% on my own network, but I do run uBlock on almost everything which catches most stuff before it reaches the pihole, and 25% on the other network.
From my understanding, uBlock doesn’t have any impact on a pihole. Any browser-based ad blocker will work by detecting the ads after the DNS requests have been made. A properly functioning pihole would intercept the ads before the ad blocker. 1.7% seems suspiciously low; My primary pihole averages anywhere from 25-50%.
on my own network a whopping 66.6% of all traffic is blocked
I stated it’s actually 66.6% DNS requests being blocked, not the raw bandwidth utilization.
Raw bandwidth savings (by not downloading the non-zero ads) would be much lesser.
That’s only for a single case comparison. You can’t draw statistically meaningful conclusions about what percentage of traffic the pihole has blocked over a longer period of time.
SpaceCadet@feddit.nl 4 weeks ago
Misleading statement. It doesn’t block “traffic”, it blocks DNS requests… you don’t know how much traffic this corresponds to.
xavier666@lemm.ee 4 weeks ago
Correct. The payload of DNS requests is tiny compared to, say requesting a webpage. So there might not be a huge decrease of bandwidth usage reduction. However, having 66.6% less DNS requests is still a win. The router/gateway doesn’t have to work that hard because of the dropped requests.
SpaceCadet@feddit.nl 4 weeks ago
It isn’t so much about the payload of the DNS requests, but about the content that would have been loaded if the DNS request hadn’t been blocked.
If you load a page that has 100kB of useful information, but 1MB of banner ads and trackers … you’ve blocked a lot more than 66%. But if you block 1MB of banner ads on a page that hosts a 200MB video, you’ve blocked a lot less.
Also a 66% blocked percentage seems very high. I have installed pihole on 2 networks, and I’m seeing 1.7% on my own network, but I do run uBlock on almost everything which catches most stuff before it reaches the pihole, and 25% on the other network.
mac@lemm.ee 4 weeks ago
I run a handful of instances across different networks, 1.7% is suspiciously low, you should make sure you’ve got the right lists. I like HageZi’s
mic_check_one_two@lemmy.dbzer0.com 4 weeks ago
From my understanding, uBlock doesn’t have any impact on a pihole. Any browser-based ad blocker will work by detecting the ads after the DNS requests have been made. A properly functioning pihole would intercept the ads before the ad blocker. 1.7% seems suspiciously low; My primary pihole averages anywhere from 25-50%.
rusticus@lemm.ee 4 weeks ago
Of course, because ads have zero bandwidth. /s
Are you an idiot?
xavier666@lemm.ee 4 weeks ago
As per the article
I stated it’s actually 66.6% DNS requests being blocked, not the raw bandwidth utilization. Raw bandwidth savings (by not downloading the non-zero ads) would be much lesser.
Can’t we be nicer on the internet?
DScratch@sh.itjust.works 4 weeks ago
You can easily find out. 2 machines (even virtual machines) one set it’s DNS to the PiHole, one not.
Both hit the same sites in the same order. Compare network traffic.
SpaceCadet@feddit.nl 4 weeks ago
That’s only for a single case comparison. You can’t draw statistically meaningful conclusions about what percentage of traffic the pihole has blocked over a longer period of time.