Whats Up with the ping

I ping the SM and I get high pings. it range from 10ms to 275ms but up and down. Is this normal

Indication of interference or a flooded network.

how can u tell

Try ping from Linux machine. We have problem with incorrect packet order. Restart od Canopy SM is usually solution:

64 bytes from 172.16.16.192: icmp_seq=1 ttl=62 time=11.4 ms

64 bytes from 172.16.16.192: icmp_seq=2 ttl=62 time=14.8 ms

64 bytes from 172.16.16.192: icmp_seq=3 ttl=62 time=13.6 ms

64 bytes from 172.16.16.192: icmp_seq=4 ttl=62 time=12.3 ms

64 bytes from 172.16.16.192: icmp_seq=5 ttl=62 time=11.8 ms

64 bytes from 172.16.16.192: icmp_seq=6 ttl=62 time=12.2 ms

64 bytes from 172.16.16.192: icmp_seq=7 ttl=62 time=10.9 ms

64 bytes from 172.16.16.192: icmp_seq=0 ttl=62 time=1419 ms

64 bytes from 172.16.16.192: icmp_seq=9 ttl=62 time=17.5 ms

64 bytes from 172.16.16.192: icmp_seq=10 ttl=62 time=9.10 ms

64 bytes from 172.16.16.192: icmp_seq=11 ttl=62 time=11.3 ms

64 bytes from 172.16.16.192: icmp_seq=12 ttl=62 time=15.6 ms

64 bytes from 172.16.16.192: icmp_seq=13 ttl=62 time=12.5 ms

64 bytes from 172.16.16.192: icmp_seq=14 ttl=62 time=14.1 ms

64 bytes from 172.16.16.192: icmp_seq=15 ttl=62 time=11.6 ms

64 bytes from 172.16.16.192: icmp_seq=8 ttl=62 time=1417 ms

64 bytes from 172.16.16.192: icmp_seq=17 ttl=62 time=9.73 ms

p_a_l_o wrote:
Try ping from Linux machine. We have problem with incorrect packet order. Restart od Canopy SM is usually solution:

64 bytes from 172.16.16.192: icmp_seq=1 ttl=62 time=11.4 ms

64 bytes from 172.16.16.192: icmp_seq=2 ttl=62 time=14.8 ms

64 bytes from 172.16.16.192: icmp_seq=3 ttl=62 time=13.6 ms

64 bytes from 172.16.16.192: icmp_seq=4 ttl=62 time=12.3 ms

64 bytes from 172.16.16.192: icmp_seq=5 ttl=62 time=11.8 ms

64 bytes from 172.16.16.192: icmp_seq=6 ttl=62 time=12.2 ms

64 bytes from 172.16.16.192: icmp_seq=7 ttl=62 time=10.9 ms

64 bytes from 172.16.16.192: icmp_seq=0 ttl=62 time=1419 ms

64 bytes from 172.16.16.192: icmp_seq=9 ttl=62 time=17.5 ms

64 bytes from 172.16.16.192: icmp_seq=10 ttl=62 time=9.10 ms

64 bytes from 172.16.16.192: icmp_seq=11 ttl=62 time=11.3 ms

64 bytes from 172.16.16.192: icmp_seq=12 ttl=62 time=15.6 ms

64 bytes from 172.16.16.192: icmp_seq=13 ttl=62 time=12.5 ms

64 bytes from 172.16.16.192: icmp_seq=14 ttl=62 time=14.1 ms

64 bytes from 172.16.16.192: icmp_seq=15 ttl=62 time=11.6 ms

64 bytes from 172.16.16.192: icmp_seq=8 ttl=62 time=1417 ms

64 bytes from 172.16.16.192: icmp_seq=17 ttl=62 time=9.73 ms


That's odd, for more than 1 reason. If you notice, sequence 1-7 does not equal 1400ms. Usually when I've seen this it was still on timing in terms of seq and was caused by filtering/throttling of sorts. How often does that happen for you? What radio software do you have, and are they NAT enabled?

Could it be that its connectorized

PING 10.0.1.8 (10.0.1.8) 56(84) bytes of data.
64 bytes from 10.0.1.8: icmp_seq=1 ttl=30 time=341 ms
64 bytes from 10.0.1.8: icmp_seq=2 ttl=30 time=13.1 ms
64 bytes from 10.0.1.8: icmp_seq=3 ttl=30 time=230 ms
64 bytes from 10.0.1.8: icmp_seq=4 ttl=30 time=53.4 ms
64 bytes from 10.0.1.8: icmp_seq=5 ttl=30 time=15.1 ms
64 bytes from 10.0.1.8: icmp_seq=6 ttl=30 time=68.9 ms
64 bytes from 10.0.1.8: icmp_seq=7 ttl=30 time=16.2 ms
64 bytes from 10.0.1.8: icmp_seq=8 ttl=30 time=160 ms
64 bytes from 10.0.1.8: icmp_seq=9 ttl=30 time=15.6 ms
64 bytes from 10.0.1.8: icmp_seq=10 ttl=30 time=173 ms
64 bytes from 10.0.1.8: icmp_seq=11 ttl=30 time=49.6 ms
64 bytes from 10.0.1.8: icmp_seq=12 ttl=30 time=15.5 ms
64 bytes from 10.0.1.8: icmp_seq=13 ttl=30 time=213 ms
64 bytes from 10.0.1.8: icmp_seq=14 ttl=30 time=17.5 ms
64 bytes from 10.0.1.8: icmp_seq=15 ttl=30 time=173 ms
64 bytes from 10.0.1.8: icmp_seq=16 ttl=30 time=64.8 ms
64 bytes from 10.0.1.8: icmp_seq=17 ttl=30 time=15.5 ms
64 bytes from 10.0.1.8: icmp_seq=18 ttl=30 time=49.0 ms
64 bytes from 10.0.1.8: icmp_seq=19 ttl=30 time=13.4 ms

— 10.0.1.8 ping statistics —
19 packets transmitted, 19 received, 0% packet loss, time 18179ms
rtt min/avg/max/mdev = 13.153/89.550/341.517/93.916 ms

PWH wrote:
Could it be that its connectorized

PING 10.0.1.8 (10.0.1.8) 56(84) bytes of data.
64 bytes from 10.0.1.8: icmp_seq=1 ttl=30 time=341 ms
64 bytes from 10.0.1.8: icmp_seq=2 ttl=30 time=13.1 ms
64 bytes from 10.0.1.8: icmp_seq=3 ttl=30 time=230 ms
64 bytes from 10.0.1.8: icmp_seq=4 ttl=30 time=53.4 ms
64 bytes from 10.0.1.8: icmp_seq=5 ttl=30 time=15.1 ms
64 bytes from 10.0.1.8: icmp_seq=6 ttl=30 time=68.9 ms
64 bytes from 10.0.1.8: icmp_seq=7 ttl=30 time=16.2 ms
64 bytes from 10.0.1.8: icmp_seq=8 ttl=30 time=160 ms
64 bytes from 10.0.1.8: icmp_seq=9 ttl=30 time=15.6 ms
64 bytes from 10.0.1.8: icmp_seq=10 ttl=30 time=173 ms
64 bytes from 10.0.1.8: icmp_seq=11 ttl=30 time=49.6 ms
64 bytes from 10.0.1.8: icmp_seq=12 ttl=30 time=15.5 ms
64 bytes from 10.0.1.8: icmp_seq=13 ttl=30 time=213 ms
64 bytes from 10.0.1.8: icmp_seq=14 ttl=30 time=17.5 ms
64 bytes from 10.0.1.8: icmp_seq=15 ttl=30 time=173 ms
64 bytes from 10.0.1.8: icmp_seq=16 ttl=30 time=64.8 ms
64 bytes from 10.0.1.8: icmp_seq=17 ttl=30 time=15.5 ms
64 bytes from 10.0.1.8: icmp_seq=18 ttl=30 time=49.0 ms
64 bytes from 10.0.1.8: icmp_seq=19 ttl=30 time=13.4 ms

--- 10.0.1.8 ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18179ms
rtt min/avg/max/mdev = 13.153/89.550/341.517/93.916 ms


Is that radio in Hardware Scheduling 2x mode?

What's RSSI/Jitter and Link Test results?

Subscriber Module Stats
Session Status : REGISTERED VC 25 Rate 2X/2X
Registered AP :
RSSI : 1326
Power Level : -51 dBm
Jitter : 8
Air Delay : 270 approximately 2.51 miles (13230 feet)

What does your link test report?

I typically see (900Mhz) in HWSched 2x about 8-15ms ping times with rare peaks of 20-30ms. If I see pings all over the place like that it’s usually due to high jitter and/or poor link efficiency.

when u test whats all the setting u use for link test

Link Test 99/100

Jitter seems on the high side, whenever I see jitter jump above 5 the ping goes up with it. Watch the jitter on that link, I bet it’s jumping around.

BM

PWH wrote:
Subscriber Module Stats
Session Status : REGISTERED VC 25 Rate 2X/2X
Registered AP :
RSSI : 1326
Power Level : -51 dBm
Jitter : 8
Air Delay : 270 approximately 2.51 miles (13230 feet)


Link looks good for a 2X link... the RSSI is a bit low for the power level... Question??? is the jitter stable at 8 or is it all over the place... if it is up and down I would look for either structural interference or surrounding RF interference... Just my 2 cents.

Good luck

CM

Is the SM in NAT? If not is the customer running P2P software?

no not using NAT or no p2p running all install do the same

Replace the SM or try 1x mode. I find a lot of links just do not survive 2x mode.