[Dxspider-support] Ping

[Kin]

Hi Tim,

Good explanation of ICMP ping. What I was asking about was ping at the application layer.
Conventional ping -as you know- only tells me if the host is accessible, but not if the DXSpider application is UP and responding.
What I am trying to do is use the internal spider command, also called ping, to see the status of the destination node. Obviously from the spider application itself. Here the node callsign (application level) is used.

I liked your explanation of ping, a widely used tool that complements others, especially for those of us who have been working in networks and systems.

I appreciate your answer.

73 de Kin

-----Mensaje original-----
De: Dxspider-support <dxspider-support-bounces at tobit.co.uk> En nombre de Tim Tuck via Dxspider-support
Enviado el: domingo, 25 de agosto de 2024 5:27
Para: Kin via Dxspider-support <dxspider-support at tobit.co.uk>
CC: Tim Tuck <vk2xax at skybase.net>
Asunto: Re: [Dxspider-support] Ping

Hi Kin,

To debug network issues you need to run a few long proper ping tests to see if there is actually something wrong with the intermediate connection.

from the linux cli  I like to run ping with the "-c" switch set to 120 and -q to keep it quite but print stats

i.e. ping -q -c10 8.8.8.8 will get you results like this...

$ ping -q -c10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms rtt min/avg/max/mdev = 13.224/14.285/15.063/0.670 ms

$

By default ping emits a packet once-per-second so 120 pings is 2 minutes worth.

This should show up any latency or loss issues.

Its also a good idea to run 3 simultaneous pings, one to the suspect target and the other to 2 different hosts known to be good.

That way if you got loss or latency on your target and not the others then you know its an issue with the target and not the network.


If you suspect dynamic routing changes are occurring you need to run a 
baseline traceroute between you and the target so you can see what the 
path is and then when you are having issues run the traceroute again to 
see if the path has changed.

what is the destination host ? is it a dedicated PC or a Pi or a VM or 
something else?

If the host is shared in anyway you might have some other process tying 
up the box causing dxspider to wait its turn.

Lots of things to look at :)

cheers

Tim

On 24/8/24 23:07, Kin via Dxspider-support wrote:
> Hi,
>
> I've been testing with the internal ping command, and it doesn't always
> respond. Sometimes it responds and the next time it doesn't, or it even says
> "not visible on the cluster". I guess it has to do with the routing tables,
> but the nodes tested have been dxspider 5457 latest build, and linked by a
> minimum of 2 hops. It has been verified that at no time has the node or the
> links gone down.
> Does anyone know the cause? Any ideas?
>
> 73 de Kin EA3CV
> -- 

VK2XAX : QF68KM : ITU59 : CQ30 : ORARC : WIA


_______________________________________________
Dxspider-support mailing list
Dxspider-support at tobit.co.uk
https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support