spdMerlin packet loss is up

[JT Strickland]

My packet loss seems to be up abnormally. Skynet doesn't indicate anything heavier than usual, but I read that it could be from external attacks.

Do you think it is something failing, or maybe bad ethernet cable, or??

tia,
jts

 

[heysoundude]

The scaling seems odd to me...truth be told -> latency and jitter on one graph are fine, but I'd really prefer only to correlate packet loss with those when they go wonky.
Can we have an on-off switch that's persistent for that please, @Jack Yaz ?

 

[Jack Yaz]

The scaling seems odd to me...truth be told -> latency and jitter on one graph are fine, but I'd really prefer only to correlate packet loss with those when they go wonky.
Can we have an on-off switch that's persistent for that please, @Jack Yaz ?

If you click the dataset it'll disappear.

There's a dual scale - read packet loss on the right and the others on the left

 

[John Fitzgerald]

My packet loss seems to be up abnormally. Skynet doesn't indicate anything heavier than usual, but I read that it could be from external attacks.

Do you think it is something failing, or maybe bad ethernet cable, or??

tia,
jts

View attachment 28416

Have you tried adjusting your MTU size. I lowered mine and have less packet loss.
Many guides via Google but here's one:

MTU Size: What Is It and What Should It Be Set To? – Home Network Geek

homenetworkgeek.com

 

[JT Strickland]

Have you tried adjusting your MTU size. I lowered mine and have less packet loss.
Many guides via Google but here's one:

MTU Size: What Is It and What Should It Be Set To? – Home Network Geek

homenetworkgeek.com

I am looking at it. It is odd though that it just started, or at least I've never noticed it before. It seems it would be something recent.
thanks for the answer and the link.
edit: Mine quit fragmenting at 1370. Seems low.

 

[John Fitzgerald]

I am looking at it. It is odd though that it just started, or at least I've never noticed it before. It seems it would be something recent.
thanks for the answer and the link.
edit: Mine quit fragmenting at 1370. Seems low.

Mine is at 1470.

 

[JT Strickland]

Mine is at 1470.

I set mine to the 1398 suggested by the author in the RT-AC86U GUI interface WAN tab instead of his method, after I restarted httpd since it was locked up. I assume this is the preferred method for ASUS routers. I still think something else is triggering it. To big of a jump too soon, but that needed fixing anyway.
thanks again.
But I could be wrong, I am still green as a gourd at this.

 

[John Fitzgerald]

I set mine to the 1398 suggested by the author in the RT-AC86U GUI interface WAN tab instead of his method, after I restarted httpd since it was locked up. I assume this is the preferred method for ASUS routers. I still think something else is triggering it. To big of a jump too soon, but that needed fixing anyway.
thanks again.
But I could be wrong, I am still green as a gourd at this.

Mine has gone up since the switch from 384.19 to the 386 (Beta1a (ax58u only)... 1a was a patch release just for this model).
Not sure if it has anything to do with the Beta making logs to phone home or it just being immature due to not being a Finale Release.
I'll keep an eye on it each Beta Release.
Also new Firefox release 83 is now set to HTTPS only.
My unit gets a nightly reboot.

Try rebooting the Modem after the router has settled from any changes.

 

[JT Strickland]

Thanks, I will try that. I'm still on 384.19 and waiting for the 386.1 release to upgrade. I've got to implement a new micro SD for the USB, and redo the jffs, factory reset, reinstall and reconfigure everything. I'm not looking forward to it. Except to maybe eleminate some problems.

I looked and mine is Firefox 83. I've got it checked in the privacy settings to not use HTTPS mode. I suppose I should turn it on.
I think I got DOH confused with HTTPS only. Please excuse my ignorance.

 

[Kingp1n]

I tried doing the MTU test and notice when I try values between 1420 - 1472 bytes, I get time out. Why is that?

values 1473 - 1500 = fragmentation is needed

So it seems 1419 is the value that doesn't require fragmentation and doesn't time out:

Pinging www.google.com [172.217.5.228] with 1419 bytes of data:
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=53ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=43ms TTL=117

Ping statistics for 172.217.5.228:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 43ms, Maximum = 53ms, Average = 46ms

Do I add 28 and call it a day? Thanks for any input!

 

[JT Strickland]

I tried doing the MTU test and notice when I try values between 1420 - 1472 bytes, I get time out. Why is that?

values 1473 - 1500 = fragmentation is needed

So it seems 1419 is the value that doesn't require fragmentation and doesn't time out:

Pinging www.google.com [172.217.5.228] with 1419 bytes of data:
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=53ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=43ms TTL=117

Ping statistics for 172.217.5.228:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 43ms, Maximum = 53ms, Average = 46ms

Do I add 28 and call it a day? Thanks for any input!

That's the way I understand it, but you better get confirmation from someone who knows this better than I.

Yesterday I got HTTPS confused with DoH/DoT briefly, although I have had a HTTPS Everywhere add on for Firefox for a few years. There are just too many alphabetized acronyms in this business, and I should have looked closer instead of jumping to a conclusion.

It makes it difficult for a greenhorn to get ripe.

 

[John Fitzgerald]

I tried doing the MTU test and notice when I try values between 1420 - 1472 bytes, I get time out. Why is that?

values 1473 - 1500 = fragmentation is needed

So it seems 1419 is the value that doesn't require fragmentation and doesn't time out:

Pinging www.google.com [172.217.5.228] with 1419 bytes of data:
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=45ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=53ms TTL=117
Reply from 172.217.5.228: bytes=68 (sent 1419) time=43ms TTL=117

Ping statistics for 172.217.5.228:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 43ms, Maximum = 53ms, Average = 46ms

Do I add 28 and call it a day? Thanks for any input!

Yes, add 28 to the number and you are done.

For me, on cable, my end number was 1470. I tried 1472 and I was back to errors.
When I first set it lower, web page loading was slower, so I rebooted the Modem.
It seemed to take a little while for the ISP to adjust and then the speed was back.

Now with the 386 Beta and other recent changes, (Windows, Firefox), I'm getting some errors.
So I will have to revisit this with each Beta and see where it settles with the Final Release.

To your question:
"I tried doing the MTU test and notice when I try values between 1420 - 1472 bytes, I get time out. Why is that?"

You are pinging a specific IP so it could be caused by how many hops it takes to its destination, then the handshake. (there is a threshold, time limit and hops) If you spend most of your time using a certain site then use that IP for pinging. If your specific use test case end site is half way around the globe then expect the MTU to be a lower number. (city v rural, cable v fiber, lots of other variables, including Load. How far you're out on your ISP providers run, holiday shopping, work from home M-F, etc.)

You just have to see what works for you.

 

[John Fitzgerald]

@Kingp1n , @JT Strickland :

Some additional help: https://www.clouddirect.net/knowledge-base/KB0011455/using-traceroute-ping-mtr-and-pathping

 

[JT Strickland]

@Kingp1n , @JT Strickland :

Some additional help: https://www.clouddirect.net/knowledge-base/KB0011455/using-traceroute-ping-mtr-and-pathping

It seems to have helped my packet loss.

It is more noticeable after 2200 hours in the 24 hour graph when I changed MTU from 1500 to 1398 (1370+28).
What is weird is that is where it was prior to Dec 11-12. Except now it looks like I am not experiencing hardly any packet loss.
Maybe my ISP changed something, or I have an ethernet cable going bad, or they do. It sure looks better now.

 

[heysoundude]

If you click the dataset it'll disappear.

There's a dual scale - read packet loss on the right and the others on the left

should it be persistent? I'd like that choice to be

 

[Jack Yaz]

should it be persistent? I'd like that choice to be

I have no current plans to make it persistent

 

[John Fitzgerald]

It seems to have helped my packet loss.

View attachment 28440

It is more noticeable after 2200 hours in the 24 hour graph when I changed MTU from 1500 to 1398 (1370+28).
What is weird is that is where it was prior to Dec 11-12. Except now it looks like I am not experiencing hardly any packet loss.
Maybe my ISP changed something, or I have an ethernet cable going bad, or they do. It sure looks better now.


View attachment 28442

I'm glad it helped.
My ARRIS Modem gives it to me a different way:

 

[heysoundude]

I set mine to the 1398 suggested by the author in the RT-AC86U GUI interface WAN tab instead of his method, after I restarted httpd since it was locked up. I assume this is the preferred method for ASUS routers. I still think something else is triggering it. To big of a jump too soon, but that needed fixing anyway.
thanks again.
But I could be wrong, I am still green as a gourd at this.

One way to think of MTU is like a bucket brigade - to pass as much water as quickly as possible to put out a fire. MTU setting is how much water in each bucket that holds 1500bytes (it may be bits...) of before it starts spilling and getting slopped all over the place rather than on the fire. packet loss is water sloshing out of the buckets. Yeah, it's counterintuitive, but that's how the most data passes as quickly as possible in a system.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[raion969]

From where do younget the paket loss graphics?

 

[L&LD]

Look at the connmon (or almost any other) script by @Jack Yaz for all your graphing requirements.