Network Congestion Affecting Sky Fibre Connection in Dublin

Published November 02, 2026 • Updated November 02, 2026

A comparison of Sunday evening and Monday morning network performance — November 2026.

I’ve been investigating intermittent slow webpage loading, inconsistent download speeds and occasional connection delays on my Sky 500 Mbps full-fibre broadband connection in South Dublin. Initially, I suspected DNS resolution might be responsible. Pi-hole was showing numerous DNS requests taking between 75 and 200 ms, which seemed unusually slow for a fibre connection. Rather than immediately changing DNS providers or blaming my own equipment, I started testing different parts of the network, including the local router, external DNS providers, internet routing and download performance.

Sunday evening performance was substantially worse than Monday morning. DNS queries that had been taking approximately 70–100 ms were responding in 4–8 ms the following morning. TCP-based network measurements also showed a dramatic reduction in latency variation. Download speeds increased from approximately 30-325 Mbps (unstable) on Sunday evening to 482 Mbps (stable) on Monday morning. These observations are consistent with a time-dependent network performance problem, potentially peak-time congestion somewhere within the ISP’s access or upstream infrastructure. They do not, by themselves, establish exactly where the congestion occurs.

1. Network configuration

The broadband installation consists of:

• ISP: Sky Ireland.
• Package: 500 Mbps full fibre.
• Location: South Dublin.
• Original fibre outlet: Installed as part of the original Virgin Media installation.
• Optical termination: Sky-installed ONT, connected to the VM fibre outlet.
• Router: GL.iNet Beryl 7.
• WAN configuration: PPPoE.
• VLAN: 10.
• MTU: 1492.
• Local DNS: Pi-hole.
• DNS upstream providers: Google and OpenDNS, with Cloudflare and Quad9 used for testing.
• DNSSEC is enabled and confirmed with https://dnssec.vs.uni-due.de/.

The physical connection is:

Building fibre distribution → fibre outlet → Sky ONT → Ethernet → GL.iNet Beryl 7 → Local network

The Sky connection is configured directly on the GL.iNet router, rather than through a Sky Wi-Fi router. This is useful because it eliminates the Sky router’s wireless performance and routing configuration as potential variables.

2. Initial observations: Sunday evening

On Sunday, 1 November 2026, I noticed that webpage loading was taking noticeably longer than expected. Pi-hole DNS query logs showed some responses taking between 75 and 215 ms.

Examples included:

By comparison, some locally cached or otherwise very fast DNS responses were taking only a few microseconds. This suggested that the delay was occurring when external DNS resolution was required, rather than being caused by Pi-hole’s local processing.

Testing external DNS providers

I tested four DNS providers directly from the Pi-hole machine:

The results were unexpectedly slow.

For example:

• Cloudflare: approximately 72–84 ms.
• Quad9: approximately 79–131 ms.
• Google: approximately 71–235 ms.
• OpenDNS: approximately 79–175 ms.

Some queries also failed to return within the configured two-second timeout. This was unusual enough to investigate whether the problem extended beyond DNS.

3. Establishing whether the local network was responsible

The first test was to measure latency between the Pi-hole machine and its default gateway.

GW=$(ip route | awk '/default/ {print $3; exit}')
echo "Default gateway: $GW"
ping -c 10 "$GW"

Results:

This was an excellent result. It showed that the connection between the Pi-hole machine and the GL.iNet router was stable, with microsecond latency (572 μs).

I also monitored the gateway during a Fast.com download test. The gateway latency remained stable. This suggested that local network congestion, at least on the measured path, was not responsible for the external latency problems.

4. Testing external network latency

I then tested connectivity directly to Cloudflare:

ping -c 20 1.1.1.1

Sunday evening results:

This was significantly worse than the local gateway measurements. However, ICMP packet loss alone is not sufficient to establish genuine packet loss affecting normal internet traffic. Routers can deprioritise or rate-limit ICMP responses. I therefore moved on to MTR testing.

5. Mapping the network route using MTR

MTR combines traceroute and ping functionality, allowing repeated measurements of latency and response loss across the route to a destination. I initially tested Cloudflare and Google using ICMP:

mtr -rwzc 30 1.1.1.1
mtr -rwzc 30 8.8.8.8

The Cloudflare route showed:

The Google route showed similar external latency, with the final Google DNS destination averaging approximately 63.7 ms. The important observation was that both external destinations exhibited elevated latency. This made an isolated Cloudflare DNS issue less likely.

Some intermediate routers did not respond to diagnostic probes. This is not necessarily packet loss: routers frequently suppress or deprioritise traceroute responses. The final destination measurements are more useful when assessing end-to-end connectivity.

TCP-based MTR

To avoid relying exclusively on ICMP, I repeated the tests using TCP.

Sunday evening:

mtr -T -P 443 -rwzc 100 1.1.1.1

The final Cloudflare destination reported:

Although no final-destination packet loss was recorded, the latency variation was substantial. Some responses were relatively quick, while others took more than a second. This suggested inconsistent network performance rather than simply a consistently slow DNS server.

6. Monday morning: repeating the tests

On Monday, 2 November 2026, at 07:50, I repeated the DNS tests.

The results were dramatically different.

DNS response time comparison

The following table shows the median of the successful responses recorded during each test.

These measurements show a substantial improvement for most of the tested resolvers. There is an interesting exception: one OpenDNS resolver remained inconsistent, while its secondary resolver performed very well. This demonstrates why testing individual resolver addresses is more useful than assuming every server operated by a particular provider will perform identically.

The DNS tests used the same domain for each corresponding resolver across both measurement periods:

• Cloudflare and Quad9: example.com.
• Google and OpenDNS: wikimedia.org.

One limitation is that repeated queries can be served from the DNS provider’s cache. These measurements therefore represent observed resolver response times, not a controlled test of cold recursive resolution.

Repeating the TCP MTR tests

At 07:53 on Monday, I repeated the TCP MTR test against Cloudflare.

mtr -T -P 443 -rwzc 100 1.1.1.1

Results at the final destination:

The Monday measurement was substantially more stable.

I also tested TCP port 80:

mtr -T -P 80 -rwzc 100 1.1.1.1

Results:

Both TCP tests indicated much more consistent connectivity.

7. Speedtest.net results

I retained three Speedtest.net measurements.

I also experienced repeatedly slow and inconsistent Fast.com results on Sunday evening, with throughput reaching approximately 250 Mbps at best. Fast.com and Speedtest.net use different testing infrastructure, so their results are not directly interchangeable.

8. What could explain the improvement?

The most plausible explanation is time-dependent congestion somewhere along the shared broadband network or its upstream connections.

My broadband connection involves several network components:

1. The building’s fibre distribution infrastructure.
2. The optical access network and associated aggregation equipment.
3. The network carrying wholesale broadband traffic.
4. Sky’s network, including its routing and external interconnections.
5. The destination network.

Potential congestion points include:

• Optical access capacity, including PON infrastructure.
• Local aggregation equipment.
• Backhaul capacity.
• Wholesale network handover.
• ISP aggregation and upstream routing.

The important qualification is that the current measurements do not identify which component is responsible. The fact that Cloudflare, Google and Quad9 all showed significant improvement the following morning suggests a common network condition rather than an isolated DNS-provider problem. However, changes in routing, temporary network faults, resolver behaviour and testing conditions could also contribute. A single evening/morning comparison is not sufficient to establish recurring peak-time congestion.

9. Diagnostic commands

For anyone wishing to reproduce the investigation, these were the main commands used.

Identify and test the default gateway

GW=$(ip route | awk '/default/ {print $3; exit}')

echo "Default gateway: $GW"

ping -c 10 "$GW"

Test external connectivity

ping -c 20 1.1.1.1

Compare DNS resolver response times

Cloudflare and Quad9:

for ns in 1.1.1.1 1.0.0.1 9.9.9.9 149.112.112.112; do
    echo "Testing $ns"

    for i in 1 2 3 4 5; do
        dig @$ns example.com A +time=2 +tries=1 +noall +stats
    done
done

Google and OpenDNS:

for ns in 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220; do
    echo "Testing $ns"

    for i in 1 2 3 4 5; do
        dig @$ns wikimedia.org A +time=2 +tries=1 +noall +stats
    done
done

The @ parameter instructs dig to query the specified DNS server directly, bypassing Pi-hole’s normal upstream selection.

ICMP route analysis

mtr -rwzc 30 1.1.1.1

mtr -rwzc 30 8.8.8.8

TCP route analysis

HTTPS:

mtr -T -P 443 -rwzc 100 1.1.1.1

HTTP:

mtr -T -P 80 -rwzc 100 1.1.1.1

MTR options:

-T  Use TCP rather than ICMP
-P  Specify destination port
-r  Generate report output
-w  Wide report format
-z  Display AS numbers
-c 100  Send 100 probes

TCP port 443 is particularly useful because it tests connectivity using a transport commonly used by websites.

DNS resolver identification

Cloudflare’s diagnostic endpoint can also identify the resolver handling a query:

dig +short CHAOS TXT id.server @1.1.1.1

dig +short CHAOS TXT id.server @1.0.0.1

In this investigation, the responses identified Dublin resolver locations (dub03 and dub01).

10. Conclusion

The comparison between Sunday evening and Monday morning revealed a substantial difference in network performance.

The key observations were:

• Local gateway latency remained excellent at approximately 0.57 ms.
• Sunday evening DNS responses were frequently between 70 and 130 ms, sometimes higher.
• Monday morning DNS responses from several providers were predominantly between 4 and 25 ms.
• Sunday evening TCP measurements showed significant latency variation, including responses exceeding one second.
• Monday morning TCP measurements were much more consistent, with final-destination latency averaging approximately 7–8 ms.
• Speedtest.net download throughput increased from approximately 325 Mbps on Sunday evening to almost 482 Mbps on Monday morning.
• Upload throughput remained consistent at approximately 54 Mbps.

Taken together, these findings are consistent with a time-dependent performance problem affecting the connection beyond my local router. Peak-time congestion is a plausible explanation, potentially involving shared fibre access capacity, aggregation, wholesale backhaul or ISP network infrastructure. However, it is not yet possible to identify the exact point of congestion or establish whether it is within the building’s infrastructure, the underlying access network or Sky’s network.

The most useful next step is for Sky to investigate the connection’s performance during peak hours, including optical access statistics, aggregation capacity, wholesale handover and upstream routing. The central question is whether this is simply an isolated period of network instability or a recurring peak-time capacity problem affecting customers sharing the same infrastructure. Further measurements over several evenings and mornings would help establish whether the pattern is repeatable.

The purpose of reporting these findings is not to suggest that broadband should always operate at its advertised maximum speed. Network capacity is shared, and some variation during busy periods is inevitable. However, customers should be able to understand what level of performance their provider considers normal, what level it guarantees, and what measures are being taken when recurring congestion affects the service.

A 500 Mbps full-fibre package should provide a clear expectation of performance, including during the periods when customers are most likely to use it. The question is not simply whether speeds decrease during peak hours. It is whether that decrease is reasonable, consistent with the service sold, and being actively addressed by the provider.