Slow Response Time

[Jonathan Ryshpan]

I have a weather station that's visible on the web as http://oaklandweather.ddns.net/weewx/index.html .  Response from a web browser is very slow, about 25 seconds to refresh.

It's also visible on my local network as http://oaklandweather/weewx/index.html .  Response from a web browser is very fast, less than 250 ms to refresh.

The ping times for the two ways of accessing oaklandweather are not grossly different.  Why are the response times from a browser so different?  Or possibly the slow response is just on my own system.  Could someone try ....ddns.net/weewx/... ?

ping oaklandweather.ddns.net

$ PING oaklandweather.ddns.net (45.30.89.101) 56(84) bytes of data.

64 bytes from 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101): icmp_seq=1 ttl=64 time=0.318 ms

64 bytes from 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101): icmp_seq=2 ttl=64 time=0.596 ms

64 bytes from 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101): icmp_seq=3 ttl=64 time=0.637 ms

...

$ ping oaklandweather

PING oaklandweather(fe80::2adf:cb67:d4a:65ee%enp3s0 (fe80::2adf:cb67:d4a:65ee%enp3s0)) 56 data bytes

64 bytes from fe80::2adf:cb67:d4a:65ee%enp3s0 (fe80::2adf:cb67:d4a:65ee%enp3s0): icmp_seq=1 ttl=64 time=0.224 ms

64 bytes from fe80::2adf:cb67:d4a:65ee%enp3s0 (fe80::2adf:cb67:d4a:65ee%enp3s0): icmp_seq=2 ttl=64 time=0.258 ms

64 bytes from fe80::2adf:cb67:d4a:65ee%enp3s0 (fe80::2adf:cb67:d4a:65ee%enp3s0): icmp_seq=3 ttl=64 time=0.189 ms

...

-- 

Sincerely Jonathan Ryshpan <jon...@pacbell.net>

	For I am a Bear of Very Little Brain, and 
	long words bother me. -- Winnie the Pooh

[Andy]

300-400 ms for me. Loads fine. NAT loopback from inside your network related to slowness?

Andy 

[Jonathan Ryshpan]

Thanks.  Extremely interesting info.  I'm glad that others can access weewx easily, even though I can't.

But I don't understand your advice.  The page loads slowly on my desktop, which has a wired connection to the the server running weewx and also to the internet.  Are you telling me that if I turn off wifi on all the phones that using my router/hotspot that the page will load faster on my desktop?  In fact, putting my cell phone into airplane mode makes no difference.

Sincerely Jonathan Ryshpan <jon...@pacbell.net>

	All the world's a stage and most of us are 
	desperately unrehearsed.  -- Sean O'Casey

On Tue, 2021-12-14 at 06:30 -0800, Andy wrote:

Your page loads fast for me, around 400-500 ms. The slowness from inside your home network may be related to NAT loopback. Turn off wifi on your phone and see how your page loads. 

On Monday, December 13, 2021 at 11:02:07 PM UTC-8 jonatha...@gmail.com wrote:

[p q]

The idea is the roundtrip from your router out to the internet and back to your router has an affect on the speed. If you turn off wifi on your phone and use the cell network for connectivity you're only using your router for the inbound connection.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/04d86b32f44dcca21858dd070d0a927dbd522773.camel%40pacbell.net.

[Karen K]

NAT = network address translation

Nothing to do with WiFi.

[vince]

On Monday, December 13, 2021 at 11:02:07 PM UTC-8 jonatha...@gmail.com wrote:

I have a weather station that's visible on the web as http://oaklandweather.ddns.net/weewx/index.html .  Response from a web browser is very slow, about 25 seconds to refresh.

It's also visible on my local network as http://oaklandweather/weewx/index.html .  Response from a web browser is very fast, less than 250 ms to refresh.

obligatory link - https://www.cyberciti.biz/media/new/cms/2017/04/dns.jpg

From inside your LAN:

• Try it by ip address: http://45.30.89.101/weewx/index.html and see if it's still slow
• Alternately try http://45-30-89-101.lightspeed.sntcca.sbcglobal.net/weewx/index.html

Here's what I checked - you might see if you get the same answer from 'inside' your LAN...

$ host oaklandweather.ddns.net
oaklandweather.ddns.net has address 45.30.89.101

$ host 45.30.89.101
101.89.30.45.in-addr.arpa domain name pointer 45-30-89-101.lightspeed.sntcca.sbcglobal.net.

$ host 45-30-89-101.lightspeed.sntcca.sbcglobal.net
45-30-89-101.lightspeed.sntcca.sbcglobal.net has address 45.30.89.101

If it's still bad in all the ways above, you'd have to explain how you punched Internet through back to your webserver on your LAN.

[Jonathan Ryshpan]

On Tue, 2021-12-14 at 12:13 -0800, vince wrote:

On Monday, December 13, 2021 at 11:02:07 PM UTC-8 jonatha...@gmail.com wrote:

I have a weather station that's visible on the web as http://oaklandweather.ddns.net/weewx/index.html .  Response from a web browser is very slow, about 25 seconds to refresh.

It's also visible on my local network as http://oaklandweather/weewx/index.html .  Response from a web browser is very fast, less than 250 ms to refresh.

From inside your LAN:

• Try it by ip address: http://45.30.89.101/weewx/index.html and see if it's still slow
• Alternately try http://45-30-89-101.lightspeed.sntcca.sbcglobal.net/weewx/index.html

Here's what I checked - you might see if you get the same answer from 'inside' your LAN...

$ host oaklandweather.ddns.net
oaklandweather.ddns.net has address 45.30.89.101

$ host 45.30.89.101
101.89.30.45.in-addr.arpa domain name pointer 45-30-89-101.lightspeed.sntcca.sbcglobal.net.

$ host 45-30-89-101.lightspeed.sntcca.sbcglobal.net
45-30-89-101.lightspeed.sntcca.sbcglobal.net has address 45.30.89.101

If it's still bad in all the ways above, you'd have to explain how you punched Internet through back to your webserver on your LAN.

Here's what I get when I repeat your host commands.  It looks the same as what you get:

$ host oaklandweather.ddns.net
oaklandweather.ddns.net has address 45.30.89.101

$ host 45.30.89.101
101.89.30.45.in-addr.arpa domain name pointer 45-30-89-101.lightspeed.sntcca.sbcglobal.net.

$ host 45-30-89-101.lightspeed.sntcca.sbcglobal.net
45-30-89-101.lightspeed.sntcca.sbcglobal.net has address 45.30.89.101

I checked the gateway firewall and found a major error. No-ip (see next paragraph) was open to amito (my main desktop) but not to OaklandWeather (the weewx/httpd server); it's not clear how no-ip could have worked at all, maybe some stuff left in no-ip's server.  After correcting, the system behaves even more strangely than before. Using any of the views you propose available through the web (http://oaklandweather.ddns.net/weewx/index.html), the main web site (.../weewx/index.html) is slow to start but refreshes nicely.  It's slow to change from the main site to monthly summary (.../report=NOAA/NOAA-2021-12.txt) or to change back 

I'm using a service called no-ip to give a permanent name to the OaklandWeather IP address, i.e. to my home network gateway.  No-ip has provided a client running on OaklandWeather that periodically informs the no-ip server of my gateway's IP address.  This seems to be working correctly, otherwise no-one outside my local network would be able to access the http server on OaklendWeather.  OaklandWeather's own firewall seems to be configured correctly, using the same reasoning.  My network's gateway to the internet has a firewall configured as follows.

-- 

Sincerely Jonathan Ryshpan <jon...@pacbell.net>

	And God fulfills himself in many ways
	Lest one good custom should corrupt the world.
	-- Tennyson

[Karen K]

May be you want to try tcptraceroute to track the way of the packets through your network.

tcptraceroute -p 80 oaklandweather.ddns.net

tcptraceroute -p 80 45-30-89-101.lightspeed.sntcca.sbcglobal.net

(tcptraceroute is not installed by default, so may be, you have to install it before.)

And may be, there is an internal IP address of your weather server that plays a role in that. It may start with 192.168....

[Andy]

I don't think  tcp/8245 inbound should be open. The no-ip updates are outbound so you do not need to open a port in. Change your port 80 forward to tcp only, udp 80 is not needed.

Andy

[Jonathan Ryshpan]

Here is the info you requested.

# tcptraceroute -p 80 oaklandweather.ddns.net
Running:
       traceroute -T -O info --sport=80 oaklandweather.ddns.net  
traceroute to oaklandweather.ddns.net (45.30.89.101), 30 hops max, 60 byte packets
1  45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101)  0.674 ms  0.511 ms  0.340 ms
2  45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101) <syn,ack>  0.896 ms  0.842 ms  0.940 ms

# tcptraceroute -p 80 45-30-89-101.lightspeed.sntcca.sbcglobal.net
Running:
       traceroute -T -O info --sport=80 45-30-89-101.lightspeed.sntcca.sbcglobal.net  
traceroute to 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101), 30 hops max, 60 byte packets
1  45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101)  0.563 ms  0.280 ms  0.422 ms
2  * 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101) <ack>  1.079 ms 45-30-89-101.lightspeed.sntcca.sbcglobal.net (45.30.89.101) <syn,ack>  1.200 ms

# host oaklandweather
oaklandweather.attlocal.net has address 192.168.1.75
oaklandweather.attlocal.net has IPv6 address fe80::2adf:cb67:d4a:65ee
oaklandweather.attlocal.net has IPv6 address 2600:1700:5f20:4d80::49
oaklandweather.attlocal.net has IPv6 address 2600:1700:5f20:4d80:a122:3027:e0dc:c399

On Wed, 2021-12-15 at 03:47 -0800, Karen K wrote:

May be you want to try tcptraceroute to track the way of the packets through your network.

tcptraceroute -p 80 oaklandweather.ddns.net

tcptraceroute -p 80 45-30-89-101.lightspeed.sntcca.sbcglobal.net

(tcptraceroute is not installed by default, so may be, you have to install it before.)

And may be, there is an internal IP address of your weather server that plays a role in that. It may start with 192.168....

-- 

Sincerely Jonathan Ryshpan <jon...@pacbell.net>

	As our case is new, so we must think anew and 
	act anew.  -- Lincoln

[Jonathan Ryshpan]

You are correct; but the gateway in question, a BGW320-500 XGS-PON Broadband Gateway, doesn't seem to provide any way at all to edit built in wervices like httpd; I have enabled what's provided. Or a way to distinguish between inbound or outbound ports in the setup for custom services like no-ip. Perhaps a discussion with ATT support would provide more info. Do you think this is desirable?

On Wed, 2021-12-15 at 05:47 -0800, Andy wrote:

I don't think  tcp/8245 inbound should be open. The no-ip updates are outbound so you do not need to open a port in. Change your port 80 forward to tcp only, udp 80 is not needed.

Andy

On Wednesday, December 15, 2021 at 3:47:32 AM UTC-8 kk44...@gmail.com wrote:

May be you want to try tcptraceroute to track the way of the packets through your network.

tcptraceroute -p 80 oaklandweather.ddns.net

tcptraceroute -p 80 45-30-89-101.lightspeed.sntcca.sbcglobal.net

(tcptraceroute is not installed by default, so may be, you have to install it before.)

And may be, there is an internal IP address of your weather server that plays a role in that. It may start with 192.168....

-- 

Sincerely Jonathan Ryshpan <jon...@pacbell.net>

	Dance, as if nobody's watching,
	Love, as if you've never been hurt,
	Sing, as if no one can hear you,
	Work, as if you don't need the money,
	Live, as if heaven is on earth.
	-- Rumi

[vince]

You're killing yourself here on something that seems like a nice-to-have and not a need-to-have. At some point the time-value of your labor and blood pressure exceeds the nice-to-have for stuff like this.

Is there a reason you can't just save a bookmark with the ip address of weewx on your LAN and use 'that' when you are on your LAN ?

Internet=>LAN works, which is the hard part.  Take the 95% win perhaps ?

[Andy]

From the screenshot of your router config you have tcp/80, udp/80 open and tcp/8245 open from the outside. Get rid of udp/80 and tcp/8245, not needed.  

The no-ip docs.

For update requests on HTTP, our interface listens on Ports 80 and 8245. Port 8245 is used to bypass HTTP proxies. If updating over HTTPS, our system listens on Port 443 It is not necessary to open any incoming ports for updating.