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 
  • From: Thomas Tsagklas <>
  • To: Mark Feit <>, "" <>
  • Subject: Re: [perfsonar-user] RTT --deadline option issue
  • Date: Thu, 21 Mar 2024 09:07:40 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=6x+yn+RUgyATpwRGjdOmjD1nwWlG4sgkfP1t0HRLvmQ=; b=fjeJSMuVePXIDhs+Vl6+rx9beMRknYsDBx9u1TYN87ZTNoViyDc1+2xANQM4jtIIBcH15mmC34BOB9+CFggASV78IhbLts9+j+dg4/TUJZzxcgjyj0qm7NKOqejRoyKpeVQnAZvtPR9pBB8CRoBKfq7m84NqSZbgmoUMFsvYEopzYRqhGg4UV4na2aVZRFFepHwhF0i8lIPeiGAitplUTjJImK2xaAFr6vh0qVsWmwVl6/s/hkyitEgQysOO9QOFmQtGRXKFR6PQdarahdTZl6nqrrr0sF8+w1dP3nPEZ6o5TN5FHuBPkgHJqql8NXi47APVhIMW76u1hP3bn4NG+A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c7oHpcaBiJBRsh3dWiQWBxnPLjOdLVMwv3hRA3NZdHRk1g4OUl7q6eT5n3HkSjNwfGVanKFcdejOSp6Fpch5n5NFM7LIAErST+eYG7jWWGvl39tK9mDSxdAErQ3sO9LirvNFR18+H8l7T18mro4hYU/P45vbHzO0wJXvELC425rTXFpooGdQ7HtgFzTjvNGWCk9STAA5vwYbd4CFztjZlkpwNfIPoLm4CvdkzNG5WaL67rChtxWwHDdQ9Jms9UWlHsLFkiti6SruLX/BhTNlBLpa+LqHdF7rnWz63vHggLs5vb4tlrBseGXQP8xWNFy77wByOxBY/cdxBSEZhDTr1g==
  • Msip_labels:

Thanks Mark, 

Apologies for the ignorance but what is the full URL  I should be adding to the  --diags command option?

From: Mark Feit <>
Sent: 20 March 2024 20:21
To: Thomas Tsagklas <>; <>
Subject: Re: [perfsonar-user] RTT --deadline option issue
 

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