...
NUST: (No update 11/19/2018)
Les sent email to Wajahat 12/6/2018 requesting update to the following:
Wajahat proposes to get a list of the new Universities in Pakistan and contact them encouraging them to participate in PingER and set up MA. They have made a list of new university sites, communications networks, Labs in different regions of Pakistan (especially the remote regions) and will make contact.
Wajahat was unable to attend but provided the following update 12/8/2018
- "We have been aggressively pursuing the three nodes(121.52.146.180 (kohat.edu.pk) down since Nov 22/2017; cae.seecs.edu.pk last time we were able to gather any data was September 2nd 2018; and pinger.isra.edu.pk no data since 5th Sept 2018, so it is a candidate to Disable). It appears to me that the participating institutes have started to lose interest in the project. Anyhow we will keep pushing. Maybe a letter of appreciation from SLAC might rejuvenate their energies. What is your opinion.
- We also need to formulate some research problems that have the potential of appearing in some well known places. This might help in attracting NUST students which is getting harder these days. I need your help in this regard."
UAF/GHZU (Updated 11/19/2018)
- Saqib's future at GZHU will be much clearer after November, current contract expires February 2019.
- Gathering data is no longer working. Saqib tried to make the Beijing MA live again. However, he has little control over it as it is in the CERNET cloud. We have given up. It has been Disabled.
PingER at SLAC (Updated 11/19/2018)
PingER IPV6 support
- Les cleaned up the Beacons and added some more hosts. Now have 161 Beacons in 156 different countries, all are working.
- We now monitor 830 targets from SLAC this is an increase of ~100 in the last year and is the most monitored from SLAC ever.
- We are monitoring 48 IPv6 nodes from SLAC.
| Host | State | last seen | Status |
|---|---|---|---|
| pinger.gzhu.edu.cn | Is not working | 10/20/2018 | |
| pingersonar-um.myren.net.my | No response | 6/26/2018 | |
| pinger.isra.edu.pk | Down, it came up Sep 2-4, 2018. It is pinging, however, all the targets are not responding after 31 tries, email sent to Wajahat 9/18/2018. As of 10/14/2018 it is not pingable. | March 6, 2018 | |
| pingeramity.in | It has been working since 28th July. It is unclear how stable it is. It is down again 9/5/2018. Worked again from 9/24/2018 to 9/28/2018. Emailed Amity requesting clarification 10/3/2018. They are looking at it. | April 27, 2018 |
Context:
- Is there any statistical difference between ICMP and TCP Ping? The context here is the Internet (not data center). This is important because the network stack is different (e.g., MPI over infiniband) and latencies are significantly less.
Questions:
- Why should we focus on minimum RTT instead of average RTT
- Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
- Link to raw results with minRTT results:
- Are the R plots generated using minRTT?
- Averages and computed. Min RTT is available. Scripts need to be updated to use minRTT.
- What is the breakdown of latency between endpoints? If there is a difference, is it because of the type or location of the source? What if the source of traffic was not SLAC? Is there a correlation with the distance between the endpoints?
- Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we can not breakdown the two in a public network without using an active look like
- To replicate use system tap. See: https://unix.stackexchange.com/questions/419449/how-can-i-determine-if-a-latency-is-due-to-a-driver-or-the-scheduler
- pathchirp etc, we'll continue to consider these as a single component.
- Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we can not breakdown the two in a public network without using an active look like
- Are the differences limited to a particular region? How do we determine/understand if traffic prioritization is implemented?Test in a controlled environment to avoid variables such as traffic prioritization, queuing delay due to cross traffic. Review the time series of latencies for both ICMP and TCP ping, instead of averages?
- It may be that end hosts which are farther away have larger variances and thus the pronounced differences.
- Is there a difference between IPv4 measurements vs. IPv6.
Next Meeting
Next meeting: There will be a Doodle poll. January week of of 14-18, 8 pm Pacific time (Nb now on winter time); a day later 9:00 am Pakistan time; 9:30 am India time; 12:00 noon Malaysian & Guangzhou time; 11 am Thailand time; 6:00am Jordan time (I think). If Shadi and Co. can attend we will move the time forward by 2 hours to accomodate the time in Jordan.
...
Old information
NUST moved here 12/8/2018
Wajahat proposes to get a list of the new Universities in Pakistan and contact them encouraging them to participate in PingER and set up MA. They have made a list of new university sites, communications networks, Labs in different regions of Pakistan (especially the remote regions) and will make contact.
- The list of new universities is ready. Just need resources to engage them.
- Les pointed out that several Pakistani MAs have been disabled, i.e. the data is no longer gathered from them. From Wajahat 10/6/2018. "We are working on the nodes you have mentioned. The intern is new and trying hard to understand the programs. Hopefully within a week he will start repairing the nodes."
- Wajahat will provide a list of working or potentially working Pakistani MAs to Les, and if they are not enabled, Les will enter or re-enable the gathering of data from these MAs.
SLAC was unable to gather data from:
- 121.52.146.180 (kohat.edu.pk) down since Nov 22/2017. Wajahat recommends continuing at least until the new student is up to speed (3/8/2018). No data available 3/24/2018. Disabled 10/3/2018. Wajahat emailed 10/12/2018.
- pinger.kohat.edu.pk status is that the concerned person is on leave and the other person doesn't know any status of the system at site.
- cae.seecs.edu.pk last time we were able to gather any data was February 27th. Disabled 8/19/2018. Wajahat emailed 10/12/2018.For several months we were unable to gather data from pinger.isra.edu.pk starting 3/6/2018, also it did not ping. Then it started working as of September 2nd, 2018 and we gathered data for 3 days. Failed again starting on Sept 5th. At this time (Sept 6th) it was pinging, however, all pings failed (i.e. no response after 31 pings). Now (10/14/2018) it is not pingable.
- cae.seecs.edu.pk status is that the system at node is totally out of order. The system isn't in working condition. The concerned person there requires full technical support on how the linux can be installed and used. He knows windows only. He also requires all the support on making the system run the pinger scripts etc.
- Wajahat now has a permanent staff engineer so that person can be trained on how to manage MAs and possibly improve the installation process. How is it going? What Pakistani hosts are now working, do I need to re-enable any hosts. The only hosts we try to gather data from are seen in http://www-iepm.slac.stanford.edu/monitoring/checkdata/. They are:
comsatsswl.seecs.edu, maggie1.seecs.edu.pk, maggie2.seecs.edu.pk, monitor.seecs.edu.pk,
pinger.isra.edu.pk (no data since 5th Sept 2018, so it is a candidate to Disable),
pinger.nwfpuet.edu.pk, pinger.vu.edu.pk
...
- Wajahat will provide a list of working or potentially working Pakistani MAs to Les, and if they are not enabled, Les will enter or re-enable the gathering of data from these MAs.
SLAC was unable to gather data from:
- 121.52.146.180 (kohat.edu.pk) down since Nov 22/2017. Wajahat recommends continuing at least until the new student is up to speed (3/8/2018). No data available 3/24/2018. Disabled 10/3/2018. Wajahat emailed 10/12/2018.
- pinger.kohat.edu.pk status is that the concerned person is on leave and the other person doesn't know any status of the system at site.
- cae.seecs.edu.pk last time we were able to gather any data was February 27th. Disabled 8/19/2018. Wajahat emailed 10/12/2018.For several months we were unable to gather data from pinger.isra.edu.pk starting 3/6/2018, also it did not ping. Then it started working as of September 2nd, 2018 and we gathered data for 3 days. Failed again starting on Sept 5th. At this time (Sept 6th) it was pinging, however, all pings failed (i.e. no response after 31 pings). Now (10/14/2018) it is not pingable.
- cae.seecs.edu.pk status is that the system at node is totally out of order. The system isn't in working condition. The concerned person there requires full technical support on how the linux can be installed and used. He knows windows only. He also requires all the support on making the system run the pinger scripts etc.
- Wajahat now has a permanent staff engineer so that person can be trained on how to manage MAs and possibly improve the installation process. How is it going? What Pakistani hosts are now working, do I need to re-enable any hosts. The only hosts we try to gather data from are seen in http://www-iepm.slac.stanford.edu/monitoring/checkdata/. They are:
comsatsswl.seecs.edu, maggie1.seecs.edu.pk, maggie2.seecs.edu.pk, monitor.seecs.edu.pk,
pinger.isra.edu.pk (no data since 5th Sept 2018, so it is a candidate to Disable),
pinger.nwfpuet.edu.pk, pinger.vu.edu.pk
UAF/GHZU (Updated 11/19/2018)
- Saqib's future at GZHU will be much clearer after November, current contract expires February 2019.
- Gathering data is no longer working. Saqib tried to make the Beijing MA live again. However, he has little control over it as it is in the CERNET cloud. We have given up. It has been Disabled.
PingER at SLAC (Updated 11/19/2018)
PingER IPV6 support
- Les cleaned up the Beacons and added some more hosts. Now have 161 Beacons in 156 different countries, all are working.
- We now monitor 830 targets from SLAC this is an increase of ~100 in the last year and is the most monitored from SLAC ever.
- We are monitoring 48 IPv6 nodes from SLAC.
| Host | State | last seen | Status |
|---|---|---|---|
| pinger.gzhu.edu.cn | Is not working | 10/20/2018 | |
| pingersonar-um.myren.net.my | No response | 6/26/2018 | |
| pinger.isra.edu.pk | Down, it came up Sep 2-4, 2018. It is pinging, however, all the targets are not responding after 31 tries, email sent to Wajahat 9/18/2018. As of 10/14/2018 it is not pingable. | March 6, 2018 | |
| pingeramity.in | It has been working since 28th July. It is unclear how stable it is. It is down again 9/5/2018. Worked again from 9/24/2018 to 9/28/2018. Emailed Amity requesting clarification 10/3/2018. They are looking at it. | April 27, 2018 |
Context:
- Is there any statistical difference between ICMP and TCP Ping? The context here is the Internet (not data center). This is important because the network stack is different (e.g., MPI over infiniband) and latencies are significantly less.
Questions:
- Why should we focus on minimum RTT instead of average RTT
- Min RTT essentially reflects fixed delay, while average RTT subsumes variations and path load
- Link to raw results with minRTT results:
- Are the R plots generated using minRTT?
- Averages and computed. Min RTT is available. Scripts need to be updated to use minRTT.
- What is the breakdown of latency between endpoints? If there is a difference, is it because of the type or location of the source? What if the source of traffic was not SLAC? Is there a correlation with the distance between the endpoints?
- Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we can not breakdown the two in a public network without using an active look like
- To replicate use system tap. See: https://unix.stackexchange.com/questions/419449/how-can-i-determine-if-a-latency-is-due-to-a-driver-or-the-scheduler
- pathchirp etc, we'll continue to consider these as a single component.
- Latency for an echo packet to travel up the stack and back down is about 3.75 micro seconds (see StackMap https://www.usenix.org/conference/atc16/technical-sessions/presentation/yasukata). As expected, this is negligible when considered with milli second latencies.The remaining components would be propagation and queuing delay. As we can not breakdown the two in a public network without using an active look like
- Are the differences limited to a particular region? How do we determine/understand if traffic prioritization is implemented?Test in a controlled environment to avoid variables such as traffic prioritization, queuing delay due to cross traffic. Review the time series of latencies for both ICMP and TCP ping, instead of averages?
- It may be that end hosts which are farther away have larger variances and thus the pronounced differences.
- Is there a difference between IPv4 measurements vs. IPv6.
Next Meeting
Next meeting: There will be a Doodle poll. January week of of 14-18, 8 pm Pacific time (Nb now on winter time); a day later 9:00 am Pakistan time; 9:30 am India time; 12:00 noon Malaysian & Guangzhou time; 11 am Thailand time; 6:00am Jordan time (I think). If Shadi and Co. can attend we will move the time forward by 2 hours to accomodate the time in Jordan.
...
GZHU moved 11/28/2018
Blockchain
...