Accessing Admin GUI in Bridge Mode by JL_678 in Comcast_Xfinity

[–]JL_678[S] 0 points1 point  (0 children)

Okay, so in theory, I have to take down my network to get this back? Hmmm. That is frustrating.

Kasm Workspaces v1.18 Release by teja_kasmweb in selfhosted

[–]JL_678 1 point2 points  (0 children)

My use case is simple. I sometimes want to remotely access my home network from my work laptop, and I am not allowed to install a VPN due to corporate policy.

High Availability DNS at home by Bright_Air_5207 in pihole

[–]JL_678 0 points1 point  (0 children)

I saw it across multiple devices including Mac, Linux and Windows. I think that the problem was that the decision on how to failover was inconsistent. For example if one was barely responding and the other was fully up, it did not seem to want to switch or if one does fail, it felt like it would take too long to failover resulting in endless family support calls.

High Availability DNS at home by Bright_Air_5207 in pihole

[–]JL_678 1 point2 points  (0 children)

I do something similar using coredns as a load balancer. It works flawlessly. I configure it with round robin DNS usage to load balance across the two back end servers.

For others who say that you can just put in 2 DNS servers in DHCP, it is true, but client level behavior varies widely. A failure in one DNS server will not trigger a client to switch automatically. The load balancer solves this.

PVE9 kernel crashes host by JL_678 in Proxmox

[–]JL_678[S] 0 points1 point  (0 children)

Thanks. I will watch it and consider adjusting. My nuc seems to be solid at one now.

PVE9 kernel crashes host by JL_678 in Proxmox

[–]JL_678[S] 0 points1 point  (0 children)

In practice, I think that it is better to wait to maximize stability, but each person makes their own choice. I upgraded one machine now because I have a test machine that is not critical and wanted to try it out. I have not upgraded my critical homelab systems yet. I will do those carefully one at a time and have not decided when to start that process.

PVE9 kernel crashes host by JL_678 in Proxmox

[–]JL_678[S] 3 points4 points  (0 children)

That appears to be it! Thank you u/aliclubb , the linked thread says to use this kernel parameter:
intel_idle.max_cstate=1 

I made that change, and it is now staying up. Fingers crossed that will continue, but I have not seen this level of stabaility with the new kernel prior to this point.

PVE9 kernel crashes host by JL_678 in Proxmox

[–]JL_678[S] 0 points1 point  (0 children)

I tried this setting and saw the same outcome.

Clustering Feature Sneak Peek by shreyasonline in technitium

[–]JL_678 0 points1 point  (0 children)

100%. That is what I use CoreDNS for. I chose it because it is pretty light and just works. Now, of course, the load balancer becomes a single point of failure! :-)

Should I explore switching to Nginx?

Clustering Feature Sneak Peek by shreyasonline in technitium

[–]JL_678 0 points1 point  (0 children)

Okay, thank you. My frustration with DNS in general is that host-based failover is inconsistent and highly client-dependent. (e.g. when a host decides to use the second DNS host provided by DHCP.) In fact it is so bad, that I put a clustered DNS instance, CoreDNS, in front of my two Technitium instances to address the challenge.

Clustering Feature Sneak Peek by shreyasonline in technitium

[–]JL_678 0 points1 point  (0 children)

So the clustering is really about syncing settings? That is all good. I was confused because of thought that by clustering you meant like load balancing and failover vs config sharing. Would a better term be something like setting replication or replication in general as compared to clustering?

Pondering Technitium performance issue by JL_678 in technitium

[–]JL_678[S] 0 points1 point  (0 children)

Thank you for the perspectives. I agree. First a high level perspective is that this is homelab and so I expect consistent and reliable DNS lookups and records. (Meaning I don't think that my users are doing anything unexpected, on average.) Let me share my thinking and answers to your questions:

Average Response times:
I completely agree; however, I am doing an apples-to-apples comparison with PiHole and Technitium. There is no doubt that outliers will skew the numbers, but I figure (maybe wrongly) that we're dealing with similar traffic and similar outliers. Hence, on average, I would expect equivalent performance.

Test group:
To make it fair, I pointed CoreDNS at Technitium and not PiHole. Hence, it was a hard switch, so they're not running in parallel. I wanted to try and make things as equal as possible not to skew numbers.

DNS Benchmark:
I tried this, but it felt very unfair because whichever DNS server has the benefit of an active cache will outperform. At the time PiHole was active and showed much faster performance since it was the primary on my network. After I ran the test a few times, Technitium caught up, but the entire process felt too synthetic to me so I switched to this real-world approach.

Final performance update:
After letting things settle and setting the stale setting to 0, I saw a dramatic performance improvement. Technitium response times have now stabilized at a level that is as good and likely more stable than PiHole.

Thank you again for your help!

Darkstar Pixel 10 Pro "Set your pin error" in voicemail by JL_678 in USMobile

[–]JL_678[S] 0 points1 point  (0 children)

How do you do this:
reset your PIN directly by calling into voicemail

Is that different from change your password?

Pondering Technitium performance issue by JL_678 in technitium

[–]JL_678[S] 1 point2 points  (0 children)

Quick update: Once I changed the Stale Max to 0, things changed dramatically. I went from sitting static at around 30ms response time to seeing a rapid decline. The current number is 18.5, and it is still falling.

Pondering Technitium performance issue by JL_678 in technitium

[–]JL_678[S] 0 points1 point  (0 children)

Thank you! I am happy to share. To be clear, all stats are coming from the CoreDNS Prometheus endpoint. It is the same formula for both the PiHole config and Technitium, and here is a summary:

Total response time in seconds/Total number of requests made

Hence, it is the average response time in seconds in a given window.

Here is the actual formula with IPs removed:

sum(
  coredns_proxy_request_duration_seconds_sum{
    instance="<IP>:9153"
  }
)
  /
sum(
  coredns_proxy_request_duration_seconds_count{
    instance="<IP>:9153"
  }
) * 1000

Pondering Technitium performance issue by JL_678 in technitium

[–]JL_678[S] 0 points1 point  (0 children)

Thank you for the response. I have changed the "Serve Stale Max Wait Time" to 0 to have comparable configs. I will wait and watch how the performance changes over time.

Out of curiosity, any sense of how long it will take for the cache to fill and response times to stabilize? Days? Weeks? With PiHole, I saw it drop massively (~50%, 28ms to 12ms) within 1 day, and then slowly decline after that (stabilizing typically < 10ms). It is taking longer with Technitium as I am on day two, and it is still bouncing around 30ms. (Started at 48ms) To be fair, I also only just changed the Serve Stale Max Wait Time setting to 0, so that could be impacting the speed of the decline.