F5F Stay Refreshed Power Users Networks Issue with DNS during peak network activity

Issue with DNS during peak network activity

Issue with DNS during peak network activity

Pages (3): Previous 1 2 3 Next
M
MapacheLGND
Junior Member
3
09-30-2023, 08:11 PM
#11
I’ve stopped using the internet via BitTorrent before. It completely blocked everything except uploads, so I adjusted the upload speed in my client and regained access. I’m curious if the person asking is also consuming all available upstream resources.
M
MapacheLGND
09-30-2023, 08:11 PM #11

I’ve stopped using the internet via BitTorrent before. It completely blocked everything except uploads, so I adjusted the upload speed in my client and regained access. I’m curious if the person asking is also consuming all available upstream resources.

E
Eva52044
Junior Member
17
10-01-2023, 05:03 AM
#12
I used DSL until recently and struggled to fix DNS issues. Early problems with BitTorrent were mainly due to too many connections overwhelming my router. Switching to OpenWRT helped, but I eventually moved back to a PC, which was the first router I owned before consumer models appeared. I don’t remember ever being able to resolve DNS by just reconnecting, even on dial-up. It would have become extremely slow. Back then, dnsmasq seemed to be available. If restarting the router feels like a bad sign, it probably points to an unreliable device.
E
Eva52044
10-01-2023, 05:03 AM #12

I used DSL until recently and struggled to fix DNS issues. Early problems with BitTorrent were mainly due to too many connections overwhelming my router. Switching to OpenWRT helped, but I eventually moved back to a PC, which was the first router I owned before consumer models appeared. I don’t remember ever being able to resolve DNS by just reconnecting, even on dial-up. It would have become extremely slow. Back then, dnsmasq seemed to be available. If restarting the router feels like a bad sign, it probably points to an unreliable device.

E
evilskull11
Junior Member
44
10-01-2023, 05:29 AM
#13
I tried using Cloudflare and Google with a static IP, then switched back to DHCP to check if it would resolve the issue—but it didn’t. My ISP is PenTeleData, and their plan claims 500Mbps support, but I haven’t been able to reach that speed. I also changed DNS settings and tried again, but the problem persisted.
E
evilskull11
10-01-2023, 05:29 AM #13

I tried using Cloudflare and Google with a static IP, then switched back to DHCP to check if it would resolve the issue—but it didn’t. My ISP is PenTeleData, and their plan claims 500Mbps support, but I haven’t been able to reach that speed. I also changed DNS settings and tried again, but the problem persisted.

J
jynini
Member
62
10-08-2023, 10:35 AM
#14
It’s still quite complex. The speed your connection maintains isn’t the same as how much the ISP limits your downstream performance. You’ll see improved results by throttling your own upstream traffic, but this shouldn’t be required just to get things working. The fact you mentioned needing to disconnect and reconnect points toward a different issue rather than a simple sync problem. If the connection fully loads without issues once you stop uploading, the problem likely lies elsewhere. Comparing line speed to speed test results is misleading—speed tests measure actual data transfer, while sync rates reflect raw data transmission. Protocol overheads explain the gap, just like on local networks, and they naturally limit speeds compared to gigabit connections. This is completely normal and not a sign of trouble. In fact, you’re experiencing more overhead than I have on DSL, which is typical.
J
jynini
10-08-2023, 10:35 AM #14

It’s still quite complex. The speed your connection maintains isn’t the same as how much the ISP limits your downstream performance. You’ll see improved results by throttling your own upstream traffic, but this shouldn’t be required just to get things working. The fact you mentioned needing to disconnect and reconnect points toward a different issue rather than a simple sync problem. If the connection fully loads without issues once you stop uploading, the problem likely lies elsewhere. Comparing line speed to speed test results is misleading—speed tests measure actual data transfer, while sync rates reflect raw data transmission. Protocol overheads explain the gap, just like on local networks, and they naturally limit speeds compared to gigabit connections. This is completely normal and not a sign of trouble. In fact, you’re experiencing more overhead than I have on DSL, which is typical.

T
68
10-09-2023, 11:51 AM
#15
The issue seems to be with your router or another device on your network that you probably don’t own. Data travels through the network and then crashes. Monitoring devices (such as *******) can take control of the default gateway when connected, and they lack the power to handle heavy bandwidth. These units are standard and not very robust. If a static IP resolves the problem, the fault likely lies elsewhere on your network—specifically, DHCP traffic that shouldn’t be happening, which resets connections. Check each device on your network (for example, run "arp -a" on your desktop) to confirm their identities. A possible double-router scenario could be the cause if bandwidth limits aren’t effective. Changing the DNS server usually won’t help unless your router uses a caching proxy that isn’t functioning. In very old hardware (pre-10Mbit era), insufficient memory can cause crashes during activities like torrents, as the device runs out of space to manage connections. It’s unlikely this is the case, but if your ISP provided an underpowered router, it wouldn’t be surprising. The recovery time of 2–10 minutes hints at a crash or restart. Removing the router and connecting only your PC simplifies troubleshooting—then test with another machine to pinpoint the source.
T
thedarkjuggler
10-09-2023, 11:51 AM #15

The issue seems to be with your router or another device on your network that you probably don’t own. Data travels through the network and then crashes. Monitoring devices (such as *******) can take control of the default gateway when connected, and they lack the power to handle heavy bandwidth. These units are standard and not very robust. If a static IP resolves the problem, the fault likely lies elsewhere on your network—specifically, DHCP traffic that shouldn’t be happening, which resets connections. Check each device on your network (for example, run "arp -a" on your desktop) to confirm their identities. A possible double-router scenario could be the cause if bandwidth limits aren’t effective. Changing the DNS server usually won’t help unless your router uses a caching proxy that isn’t functioning. In very old hardware (pre-10Mbit era), insufficient memory can cause crashes during activities like torrents, as the device runs out of space to manage connections. It’s unlikely this is the case, but if your ISP provided an underpowered router, it wouldn’t be surprising. The recovery time of 2–10 minutes hints at a crash or restart. Removing the router and connecting only your PC simplifies troubleshooting—then test with another machine to pinpoint the source.

H
Harambe_Lives
Member
184
10-09-2023, 08:45 PM
#16
It's an issue with how the ISP set up the device to handle more traffic than the DSL line can manage. For Fiber, there aren't any connection profiles that the ISP can directly configure based on the line. Fiber is fiber, and offering speeds beyond 100mbit or 1gbit usually means the router itself must limit the transfer capacity.
H
Harambe_Lives
10-09-2023, 08:45 PM #16

It's an issue with how the ISP set up the device to handle more traffic than the DSL line can manage. For Fiber, there aren't any connection profiles that the ISP can directly configure based on the line. Fiber is fiber, and offering speeds beyond 100mbit or 1gbit usually means the router itself must limit the transfer capacity.

A
ArdVeneno
Junior Member
41
10-14-2023, 04:44 PM
#17
I checked it on your brother's machine too—it's showing the same issue. It seems the problem might be with the router itself. Try resetting it or checking for firmware updates. If it still doesn't work, there could be a hardware fault.
A
ArdVeneno
10-14-2023, 04:44 PM #17

I checked it on your brother's machine too—it's showing the same issue. It seems the problem might be with the router itself. Try resetting it or checking for firmware updates. If it still doesn't work, there could be a hardware fault.

C
Crazy_Heaven
Posting Freak
811
10-15-2023, 08:16 AM
#18
Check if restarting your ISP connection fixes the problem.
C
Crazy_Heaven
10-15-2023, 08:16 AM #18

Check if restarting your ISP connection fixes the problem.

A
Annaxabep
Junior Member
18
10-15-2023, 08:31 AM
#19
The issue seems to center around the router. You have a few options: the ISP can remotely troubleshoot, you can replace it with another model from the same provider, or you might not be able to swap it out. Checking for log files would help. If you gain access and review them, it could provide more insight. Regarding the setup, if it's a double-router scenario, it depends on how the network is configured—whether the devices are connected in a specific way that affects performance. Switching to another device might resolve the problem, but it’s unlikely to fix it if the core issue lies elsewhere.
A
Annaxabep
10-15-2023, 08:31 AM #19

The issue seems to center around the router. You have a few options: the ISP can remotely troubleshoot, you can replace it with another model from the same provider, or you might not be able to swap it out. Checking for log files would help. If you gain access and review them, it could provide more insight. Regarding the setup, if it's a double-router scenario, it depends on how the network is configured—whether the devices are connected in a specific way that affects performance. Switching to another device might resolve the problem, but it’s unlikely to fix it if the core issue lies elsewhere.

T
tmt108
Junior Member
45
10-15-2023, 01:13 PM
#20
I grasp the argument you're presenting but the reasoning doesn't align. You're focusing on congestion issues rather than DSL signal behavior. Regardless of whether it's DSL, COAX, or fiber, the underlying principle remains consistent. If any part of the path limits performance below the required rate or if several devices are operating at or above that rate, traffic will get queued and eventually lost. This happens across all types of connections. The cause can stem from physical constraints (such as signal degradation in DSL or COAX) or intentional measures like policing or shaping. Regardless, the outcome is similar. The service provider isn't involved in this process. In DSL systems, the modem checks for maximum capacity; exceeding it leads to queuing and potential loss. This rate reflects the line's raw capacity without protocol overhead. For instance, a 88/22 Mbps measurement excludes certain overheads, but the actual speed is lower due to protocol demands. The ISP doesn't control how much data flows over the connection. You can see these limits in action by comparing sync rates—hosts will switch to higher speeds if possible, but if congestion arises, packets get dropped. This behavior applies whether you're using DSL, fiber, or Wi-Fi, as long as the network can't sustain the load. The key factor is that devices don’t know the full bandwidth ahead of time and must adapt themselves. This issue often appears on Wi-Fi, especially with older adapters like USB 4 or 802.11n, which cap speeds even under heavy use. If you try to connect directly to the router without Wi-Fi, performance should improve significantly.
T
tmt108
10-15-2023, 01:13 PM #20

I grasp the argument you're presenting but the reasoning doesn't align. You're focusing on congestion issues rather than DSL signal behavior. Regardless of whether it's DSL, COAX, or fiber, the underlying principle remains consistent. If any part of the path limits performance below the required rate or if several devices are operating at or above that rate, traffic will get queued and eventually lost. This happens across all types of connections. The cause can stem from physical constraints (such as signal degradation in DSL or COAX) or intentional measures like policing or shaping. Regardless, the outcome is similar. The service provider isn't involved in this process. In DSL systems, the modem checks for maximum capacity; exceeding it leads to queuing and potential loss. This rate reflects the line's raw capacity without protocol overhead. For instance, a 88/22 Mbps measurement excludes certain overheads, but the actual speed is lower due to protocol demands. The ISP doesn't control how much data flows over the connection. You can see these limits in action by comparing sync rates—hosts will switch to higher speeds if possible, but if congestion arises, packets get dropped. This behavior applies whether you're using DSL, fiber, or Wi-Fi, as long as the network can't sustain the load. The key factor is that devices don’t know the full bandwidth ahead of time and must adapt themselves. This issue often appears on Wi-Fi, especially with older adapters like USB 4 or 802.11n, which cap speeds even under heavy use. If you try to connect directly to the router without Wi-Fi, performance should improve significantly.

Pages (3): Previous 1 2 3 Next