perfSONAR User Q&A and Other Discussion

[Louis-Berthier Soullière <>]

I did some more investigation and :

 

Simulating latency with a host in LAN does not allow to reproduce the problem.With that out of the way, I dug into the api and found where the mtu test is done :

 

The file python-pscheduler/pscheduler/pscheduler/mtu.py use tracepath to get the mtu, so I tried to use it manually :

 

LOCALHOST

# tracepath 10.249.143.17

1:  perfsonar.reg00.rtss.qc.ca                            0.093ms reached

     Resume: pmtu 65535 hops 1 back 1

 

SAME SUBNET HOST

# tracepath 10.x.x.2

1?: [LOCALHOST]                                         pmtu 1500

1:  host1                           2.009ms !H

1:  host1                           1.341ms !H

     Resume: pmtu 1500

 

WAN HOST

# tracepath 10.x.x.1

1?: [LOCALHOST]                                         pmtu 1500

1:  host1                           12.314ms

1:  host1                           46.396ms

2:  host2                           1.691ms asymm  3

3:  host3                                          1.431ms

4:  host4                                          1.234ms asymm  6

5:  host5                                          1.225ms asymm  6

6:  host6                                        1.855ms

7:  host7                                         5.872ms

8:  host8                                         5.252ms asymm  9

9:  host9                                          5.803ms

10:  host10                                          6.891ms

11:  host11                                         6.822ms

12:  host12                                         6.287ms pmtu 1460

12:  host12                                       557.388ms

13:  host13                                       556.250ms

14:  host14                                         558.090ms

15:  host15                                         558.033ms reached

     Resume: pmtu 1460 hops 15 back 15

 

The "resume" line seems to output differently depending on the number of hops?!

 

Could it be why pscheduler report "too many values to unpack"

 

Thanks!

 

Louis

 

De : [mailto:] De la part de Louis-Berthier Soullière
Envoyé : 15 juillet 2019 08:42
À :
Objet : [perfsonar-user] MTU SAFE error ?

 

Hi!

 

When I launch a troubleshoot, I get an error and I can't find how to fix it.

 

# pscheduler troubleshoot 10.x.x.1

 

Performing basic troubleshooting of localhost and 10.x.x.1.

 

localhost:

 

  Measuring MTU... 65535 (Local)

  Looking for pScheduler... OK.

  Checking clock... OK.

  Exercising API... Status... Tests... Tools... OK.

  Idle test.... 7 seconds.... Checking archiving... OK.

 

10.x.x.1 :

 

  Measuring MTU... Failed.

too many values to unpack

 

# cat /var/log/pscheduler/pscheduler.log

 

Jul 15 08:04:36 localhost journal: pscheduler-api ERROR    Exception: ValueError: too many values to unpack

Jul 15 08:04:36 localhost journal: pscheduler-api ERROR    Traceback (most recent call last):

Jul 15 08:04:36 localhost journal: pscheduler-api ERROR      File "./pschedulerapiserver/admin.py", line 104, in mtu_safe

Jul 15 08:04:36 localhost journal: pscheduler-api ERROR    ValueError: too many values to unpack

Jul 15 08:04:36 localhost journal: pscheduler-api ERROR    Internal error ::1 GET https://localhost/pscheduler/mtu-safe: too many values to unpack

 

If I use the REST-API directly :

 

# links https://localhost/pscheduler/mtu-safe?dest=10.x.x.1 (over satellite)

 

too many values to unpack

 

I'm running this test over satellite with a latency of 530 ish ms. The real MTU is 1460.

 

If I do the test with a local IP :

 

# links https://localhost/pscheduler/mtu-safe?dest=10.x.x.2 (LAN)

 

{"message": "1500+", "safe": true}

 

 

 

Running beta ISO : pS-Toolkit-4.2.0b1-CentOS7-FullInstall-x86_64-2019Jul09

 

Thanks!

 

Louis