I don't believe so. Both of the devices (my phone, work computer) can download with full speeds from other sources. It's just from my home server that things are choked at some point, unfortunately.
Yeah. Unfortunately, it'll be some time before I can really dive into the troubleshooting as we leave for an extended camping trip soon...
Aside from something in the software or os setup, it definitely sounds like an isp issue. I wish you had another computer to somehow confirm this--then it would be in their hands.
I have a Windows 10 laptop that I may install an FTP server on and hardwire it on the network (maybe direct connection to the P2P radio), just to take the other computer out of the equation for testing. I need approximately three fewer children to have enough time for some of this troubleshooting, though.
From what I've been told, there's no traditional access point on my end, and the wireless link acts effectively as a simple protocol converter for ethernet -> 2.4 GHz RF link over air -> ethernet. There's just an ethernet cable coming from the radio on our roof that runs to a PoE injector and directly to the internet port on the router. Hopefully that makes sense.
mxnerd
Diamond Member
- Jul 6, 2007
- 6,799
- 1,103
- 126
So your ISP is a WISP (wireless internet service provider), and you probably are under double NAT situation. That means whenever you want to setup a server (HTTP, FTP, etc) behind the Netgear router, not only you have to do port forwarding on your router, you also need help from your WISP? In that sense, you probably don't have a real public IP?
if your Netgear WAN IP are in
if your Netgear WAN IP are in
- 192.168.0.0 - 192.168.255.255
- 172.16.0.0 - 172.31.255.255
- 10.0.0.0 - 10.255.255.255
Last edited:
No double NAT. The service originally had one, but I couldn't do hairpinning properly, so I'm currently set up with a static IP and no upstream NAT. I can port forward to my heart's content, and the IP address seen by the router is a proper public IP (102.255.xxx.xxx).
So, the plot thickens, though...
I was at a restaurant tonight and connected to their wifi. I tested the transfer speed over FTP downloading from my server and found that it was running at 100+ kB/s. I switched over to LTE+ and the speed dropped down to 20. I tested it a few more times and the results were consistent, and the LTE+ on a speed test was about 80 Mbps.
So, I'm even more confused now... why would there be such a difference between LTE+ and a public wifi connection with an indeterminate ISP when the bandwidth is available for both connection methods?
So, the plot thickens, though...
I was at a restaurant tonight and connected to their wifi. I tested the transfer speed over FTP downloading from my server and found that it was running at 100+ kB/s. I switched over to LTE+ and the speed dropped down to 20. I tested it a few more times and the results were consistent, and the LTE+ on a speed test was about 80 Mbps.
So, I'm even more confused now... why would there be such a difference between LTE+ and a public wifi connection with an indeterminate ISP when the bandwidth is available for both connection methods?
Last edited:
mxnerd
Diamond Member
- Jul 6, 2007
- 6,799
- 1,103
- 126
100kB = 100k Bytes = 100k x 10 bits = 1Mbps.
And how about trying HFS as file server?
https://www.rejetto.com/hfs/
And how about trying HFS as file server?
https://www.rejetto.com/hfs/
I'm very familiar with the difference between bits and bytes. My b's vs. B's were intentional.
Just curious, what's the line of thinking for changing the file server software? I'm not sure how that could have an impact, especially when http transfer speeds are also affected.
Just curious, what's the line of thinking for changing the file server software? I'm not sure how that could have an impact, especially when http transfer speeds are also affected.
That's fair. I've had to explain the difference between bits and bytes to more people than I can count, so it's good to rule out stuff like that. Thanks for sticking with me this far, I appreciate it.
My ISP finally got around to testing the FTP speeds at their location within their network when downloading from my server, and the speeds were great. What this tells me is that it's not an issue with my configuration, but rather it's upstream of where they tested - either at their connection to their service provider or traffic shaping happening beyond that. Is there anything that could be gleaned from a wireshark log if the issue is at that level? I'm guessing not...
Long delay, and the problem remains. My ISP has gotten back to me with a bit of info as stated below, though:
"We've ran a bunch of packet captures and analysis, and approximately 40-45% of the TCP packets coming from your system are being retransmitted, this means that the higher the latency is between 2 endpoints, the lower the throughput (at a dramatic factor), which is why we can test to the tower/headend with minimal issues. We can't reproduce/see behavior to any other device on that network segment.
At this point, we'd need to look at putting some type of a managed switch/router to run some tests from inside/outside of your network; the issue there is that nobody, including the hardware vendor support, can identify anything at fault on our network that's causing the retransmissions."
From what I've read, normal max TCP retransmissions should be 2% before performance is noticeably impacted, so I could see this causing the issues. However, since speeds to their internal ISP location are fine, it would seem like an issue with equipment beyond that point either not sending back acknowledgements or dropping packets due to buffer overruns caused by network congestion. Either way, I can't see how putting a managed switch in my network would lead to any solution. I asked if it could be an MTU issue, but I highly doubt it.
Anyway, with this new info, can anyone smarter than me offer any insight?
"We've ran a bunch of packet captures and analysis, and approximately 40-45% of the TCP packets coming from your system are being retransmitted, this means that the higher the latency is between 2 endpoints, the lower the throughput (at a dramatic factor), which is why we can test to the tower/headend with minimal issues. We can't reproduce/see behavior to any other device on that network segment.
At this point, we'd need to look at putting some type of a managed switch/router to run some tests from inside/outside of your network; the issue there is that nobody, including the hardware vendor support, can identify anything at fault on our network that's causing the retransmissions."
From what I've read, normal max TCP retransmissions should be 2% before performance is noticeably impacted, so I could see this causing the issues. However, since speeds to their internal ISP location are fine, it would seem like an issue with equipment beyond that point either not sending back acknowledgements or dropping packets due to buffer overruns caused by network congestion. Either way, I can't see how putting a managed switch in my network would lead to any solution. I asked if it could be an MTU issue, but I highly doubt it.
Anyway, with this new info, can anyone smarter than me offer any insight?
Interesting. So here's a couple of things to try.
One, let them install the managed unit and see what they come up with.
Two, use a different ethernet card--I know, sounds crazy--but I've seen more crazy before as a bad nic is really hard to really figure out some times. A usb nic would be fine for this test.
Three, use pathping and see what is going on at each hop--if there's a lot of retransmits/packet loss, you should see them at a particular hop for sure.
Four, run the freeola line test, not the speedtest, but the line test. It's helped me identify pack loss before.
Five, sign up to thinkbroadband's free monitor service. Sure, it's from the UK, but I've found that it's nearly 100% accurate in finding packet loss and other weirdness that you wouldn't ordinarily see. I actually use it to monitor all 4 of my isp accounts:
So I had a similar issue that took over a year to resolve when our entire apartment community's service would have up to 10% packet loss after 6pm. After sharing packet loss data and freeola line test data with the isp, the isp discovered that their backbone provider was cutting their service after hours. They fired their backbone provider and upped speeds across the board, but I never got a credit or refund for the service I paid for that was useless to me after 6pm. Hopefully, your issue will be resolved quicker than mine.
One, let them install the managed unit and see what they come up with.
Two, use a different ethernet card--I know, sounds crazy--but I've seen more crazy before as a bad nic is really hard to really figure out some times. A usb nic would be fine for this test.
Three, use pathping and see what is going on at each hop--if there's a lot of retransmits/packet loss, you should see them at a particular hop for sure.
Four, run the freeola line test, not the speedtest, but the line test. It's helped me identify pack loss before.
Five, sign up to thinkbroadband's free monitor service. Sure, it's from the UK, but I've found that it's nearly 100% accurate in finding packet loss and other weirdness that you wouldn't ordinarily see. I actually use it to monitor all 4 of my isp accounts:
So I had a similar issue that took over a year to resolve when our entire apartment community's service would have up to 10% packet loss after 6pm. After sharing packet loss data and freeola line test data with the isp, the isp discovered that their backbone provider was cutting their service after hours. They fired their backbone provider and upped speeds across the board, but I never got a credit or refund for the service I paid for that was useless to me after 6pm. Hopefully, your issue will be resolved quicker than mine.
Wow, thanks for the wealth of feedback! Here are some follow up notes:
-I have a second NIC on the computer I use as a home server, but it didn't make any difference in perceivable speeds. I'm not sure if I noted previously, but the speed issue is experienced by other devices on the network as well, and the server computer showed the problem even when directly connected to the internet connection with no firewall for a brief testing period, so it doesn't seem to be a router config issue either.
-Since it seems like the packet loss is primarily with TCP transfers, can you offer any suggestions for how to apply pathping accordingly to determine which hop results in retransmissions? I tried a simple 'pathping www.yahoo.com', but it showed no packet loss over four hops.
-The freeola line test showed 0% packet loss, 151ms latency, 26ms jitter. It seems like the packet loss is only with TCP for some reason, though, and I can't say what the freeola test is using.
-I'll sign up for the thinkbroadband monitor service shortly and report back.
Thanks again for the help, it's much appreciated.
-I have a second NIC on the computer I use as a home server, but it didn't make any difference in perceivable speeds. I'm not sure if I noted previously, but the speed issue is experienced by other devices on the network as well, and the server computer showed the problem even when directly connected to the internet connection with no firewall for a brief testing period, so it doesn't seem to be a router config issue either.
-Since it seems like the packet loss is primarily with TCP transfers, can you offer any suggestions for how to apply pathping accordingly to determine which hop results in retransmissions? I tried a simple 'pathping www.yahoo.com', but it showed no packet loss over four hops.
-The freeola line test showed 0% packet loss, 151ms latency, 26ms jitter. It seems like the packet loss is only with TCP for some reason, though, and I can't say what the freeola test is using.
-I'll sign up for the thinkbroadband monitor service shortly and report back.
Thanks again for the help, it's much appreciated.
You're welcome. 
So the nic test eliminates a nic issue.
I would use pathping to a destination that you experience slowness with, or if it's traffic coming in, you'll have to use Internet from outside your network and pathping to your server.
The freeola test seems to indicate that you've got no packet loss, but I'd also try the test at the same time you're doing a transfer as it may trigger something more interesting.
So the nic test eliminates a nic issue.
I would use pathping to a destination that you experience slowness with, or if it's traffic coming in, you'll have to use Internet from outside your network and pathping to your server.
The freeola test seems to indicate that you've got no packet loss, but I'd also try the test at the same time you're doing a transfer as it may trigger something more interesting.
Ok, I tried pingpath to what google shows as my phone's public IP, but it's hard to know how the private subnets are configured below that. Anyway, it never shows it actually reaching that public IP (even though it doesn't run through all 30 hops), and ends up with 100% packet loss after tries to pass through one point that is run by the main provincial ISP here. 100% packet loss, and pinging it separately results in a timeout. It looks like my little ISP connects to Hurricane electric as a backbone provider, which routes back to our main provincial ISP, at which point the routing was laid to rest and all packets dropped.
I ran the freeola test while trying to pull a file from my ftp server to my phone, which is a typical speed-choked scenario, but there was no real change from before.
I've signed up for the thinkbroadband monitor service, but I guess I'll have to wait for a while for it to populate some data.
I'll pass along the packet loss info to my ISP for now.
I ran the freeola test while trying to pull a file from my ftp server to my phone, which is a typical speed-choked scenario, but there was no real change from before.
I've signed up for the thinkbroadband monitor service, but I guess I'll have to wait for a while for it to populate some data.
I'll pass along the packet loss info to my ISP for now.
Last edited:
It sounds like the packet loss that I was seeing with the pingpath was typical for that node as it doesn't respond to trace routes/pings and normally drops packets in such fashion. The thinkbroadband monitor hasn't been showing anything really out of the ordinary so far either.
My ISP is going to replace the radio on my dish and install what they call a 'box' to do some packet captures on the ethernet side to see if they can discern anything else. In the meantime, I'm going to get some additional TCP filtered packet captures with wireshark while doing a speed limited FTP transfer to see if it can lead anywhere. I did a quick one last night and I can see duplicate TCP ACKs and fast retransmissions, so hopefully things are on the the right track to a solution.
My ISP is going to replace the radio on my dish and install what they call a 'box' to do some packet captures on the ethernet side to see if they can discern anything else. In the meantime, I'm going to get some additional TCP filtered packet captures with wireshark while doing a speed limited FTP transfer to see if it can lead anywhere. I did a quick one last night and I can see duplicate TCP ACKs and fast retransmissions, so hopefully things are on the the right track to a solution.
For me also the transfer speed is very low. there is no issue when i am using in other device. Can any one help me with this..
That sounds like a different, device-specific issue since my problem affects all devices on the connection.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
-
-
Facebook
Twitter