Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] RTT --deadline option issue

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] RTT --deadline option issue


Chronological Thread 
    < Chronological >      < Thread >
  • From: Mark Feit <>
  • To: Thomas Tsagklas <>, "" <>
  • Subject: Re: [perfsonar-user] RTT --deadline option issue
  • Date: Wed, 20 Mar 2024 20:21:48 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=internet2.edu; dmarc=pass action=none header.from=internet2.edu; dkim=pass header.d=internet2.edu; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KVdXMjJk3vpOI+fshkcJ2wjyNIvgcaZRXsFskNvrCCg=; b=SqNWFuX6yIt5cjmXFRKxS6J4HYGa1kl+2Wq+ErSUFeyJ5a1C0C48iOT7t0Rlqw1C9wTlE2e6ZX7yltyMo5mE3UKOV5JzeekC4AnZP1+qtX+Aw3o+3F+p3DslviHLhqedXnl3kY6ymidJf66eKBC4PStbCsMlxyvC9md8PrKirbFj7K3Jn+FhqRx5G5Kh9NQ0Z1xfLYXY/eMtmga2y8S8VQcNPyiMocg3fy2MwQqBj0xa4Nvc9qn6AoUqMubINKQd51XHFbWWNzPprYZeECr5U8ql00IGsmejgGTcXUbOTlJAU8JEmwjXaj/khAttF66p4KEKz1Z5eVtKHPqxuP8vwQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A+qy8+ifYWveW9nraNcKrPatC0odPXoJht1tZfTnZkMYEIjB6usQ6Qzxtfk2rcFRGNy2+leDQ3s1aVE+I1yuy7WwfSxlH37n+rjfGGb2l8bc3AltV3vFV6IxeV/0lV02hvvCBGmhwrOg2qOstod0bFiV8OjCiHiGIeP++EMZ+Oew+tYoGx7nJna5Be6FeLEejJz1qkvVdM/Jxwz4aQ/HUUG57B5HsE1U9eqOEPzYAo4E76eHj6lEvStWI8kxyiVKbqiQ1uaDMMT//VSmX4Kz6B8OSP4PgwjcdUIT7SwkXGSQ8TdisSxUb+FWEK1bhkFJp/sFDAbroh+h0yYVIR7qCg==

Thomas Tsagklas writes:


When I run an RTT test just with the -d option, the test runs normally and I'm
getting results. When I add the --duration option, there are 2 unexpected
things happening:

1. The duration period doesn't take effect on the test, and
2. I'm getting 100% packet loss
…

DESKTOP-00407:~$ pscheduler task rtt -d 192.168.1.244 --deadline PT20S
…
100% Packet Loss  RTT Min/Mean/Max/StdDev = Unknown/Unknown/Unknown/Unknown ms

 

I’m unable to reproduce this on any of my systems.  Next time this happens, ask pScheduler to pull the diagnostics from the result, which will show how it invoked ping and what it returned.  For example:

 

myhost$ pscheduler result --diags https://myhost/...

2024-03-20T19:53:40+00:00 on myhost with ping:

…

Diagnostics from myhost:

  ping -n -c 5 -i 1.0 -w 20.0 -W 1.0 163.253.16.23

 

  PING 163.253.16.23 (163.253.16.23) 56(84) bytes of data.

  64 bytes from 163.253.16.23: icmp_seq=1 ttl=61 time=31.3 ms

  64 bytes from 163.253.16.23: icmp_seq=2 ttl=61 time=31.3 ms

  64 bytes from 163.253.16.23: icmp_seq=3 ttl=61 time=31.2 ms

  64 bytes from 163.253.16.23: icmp_seq=4 ttl=61 time=31.2 ms

  64 bytes from 163.253.16.23: icmp_seq=5 ttl=61 time=31.2 ms

 

  --- 163.253.16.23 ping statistics ---

  5 packets transmitted, 5 received, 0% packet loss, time 4006ms

  rtt min/avg/max/mdev = 31.179/31.218/31.272/0.227 ms

 

The ping tool plugin converts the deadline value to the number of seconds and passes it through to ping via its -w switch.  There is otherwise no difference in how pScheduler handles invoking ping or interpreting the results.  If you can post the diagnostics, I can look at it further.

 

--Mark

 


Archive powered by MHonArc 2.6.24.

Top of Page