getting packet loss
-
Hey guys, is it normal to show 3-10% packet loss on the WAN? this is a brand new install of 2.4.4, didn't notice it on previous release and it is bugging me.. Reinstalled a couple times, same thing.
-
this is what it looks like..
-
I also edited both and changed payload to 1, still no difference.
-
What address are you monitoring? What does your ISP have to say?
There's really nothing to do in the firewall if you are sending pings and there is no reply. Has to be dealt with upstream.
-
Derelict,
i didn't put any address to monitor, so not too sure, just the default one. Just got off the phone with ISP, they said everything looks normal and strong. Is there anything i can do to test or a monitor site that might be upstream that will give me more reliable reports? don't want to go any further setting it up until I can figure it out. thanks for responding.. :)
-
You need to set a monitor address on the gateway in System > Routing that reliably responds to pings. Maybe people use google DNS (8.8.8.8 or 8.8.4.4) some quad9 (9.9.9.9) others just use the gateway like you are.
If you have gateway monitoring on WAN (the default setting), the system is automatically keeping track of two pings per second in Status > Monitoring.
From there select settings, change the left axis to Quality / WANGW (or the local equivalent).
A good place to start with Options: 8 hours, Resolution: 1 minute.
Another place to check is in Status > System Logs, Gateways. Any events there with "Alarm" in them are times when the ping monitor had excessive loss or latency.
A failure will look something like this: Jan 7 15:05:31 dpinger WANGW 8.8.8.8: Alarm latency 0us stddev 0us loss 100%
Lines like this are just the dpinger process starting or reloading and are normal:
dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 8.8.4.4 bind_addr 198.51.0.16 identifier "DSLGW "Sometimes it is beneficial to change your monitoring address to something further out. In that example you can see that I am monitoring a google DNS server there. In general, monitoring the ISP gateway is fine if it reliably responds to pings. Changes to the monitor IP address can be made in System > Routing and editing the appropriate gateway.
-
thanks Derelict, i will have a look.. Also wanted to mention that i changed the network cable. Could it be a port going bad on my 4 port Intel nic? When i talked to my ISP, they said 3% was within their tolerance.
-
@xman111 said in getting packet loss:
thanks Derelict, i will have a look.. Also wanted to mention that i changed the network cable. Could it be a port going bad on my 4 port Intel nic? When i talked to my ISP, they said 3% was within their tolerance.
Sounds like it's time to get another ISP.
I doubt it's the NIC.
It's possible that choosing another ping target might help. The ISP device might forward traffic fine and only respond to about 97% of the pings directed at it but it might still be processing everything directed through it. This is not all that uncommon.
If they can't/won't fix it and changing monitoring targets doesn't help I guess you'll just have to ignore it or disable gateway monitoring entirely.
-
would any of this result in data loss uploading to the internet? we upload all our photos to onedrive. I would hope there is error correction or something. it is just a redundant backup but want it good none the less.
thanks for your time, appreciate it.
-
No. TCP streams are checksummed and acknowledged as the transfer takes place. It is a reliable protocol. If a packet is lost it is re-sent. Backup software might go above and beyond that checking hashes of transmitted and received files, etc.
-
been pinging for hours at a time now. Most come back 100%, sometimes when sending like 15,000 packets, it will drop 4 or 5, is that normal? maybe it was just an issue on my ISP's side that is now fixed.
-
"Normal" is based on the circuit and the ISP. I would not consider that to be excessive.
The 8-hour x 1-minute quality graph I referenced above is the first place I go.
Here's mine (the flat blue line at the bottom is 0% packet loss):
-
thanks Derelict, i will try that when I go home. really appreciate you helping me out.
-
this is after a couple hours while i was at work.
-
That looks fine. Those latency spikes are a little concerning but there is no loss.
Guess: They told you nothing is wrong but looked internally and found something. Or something else was going on at the time (like they were fighting a DDoS, etc.)
-
i will let it continue to run and see if it was just a blip or something. Thanks for having a look..
