• Created by Unknown User (amberzeb), last modified on Feb 20, 2012

Minutes for SLAC SEECS Meeting February 15th 2012

General

An email has been sent out to the contacts of the monitoring hosts telling them about: Pinger Explorer, ICFA report, motion charts, traceroute archive, PingER video and PingER Map.

Amber is writing a script to automatically check the status of the nodes which are not gathering data. She has automated the data gathering and pinging checks. Next step is to add a new html page with the problem in the node, days since it is having problem and the contact information of the node.

Once again there has been little email from Pakistan people. This is not good, we need to communicate outside this meeting.

I have modified traceroute.pl to also provide tracepath. The new version is 5.6. if you are updating any monitors then this is the version to install. It is available at http://www.slac.stanford.edu/comp/net/traceroute/traceroute.pl

IPV6 - Anjum and Ghulam (this has been de-prioritized until new database PingER is working)

IPV6 machine is working fine. Ghulam installed pinger2 on it and tried to collect data. But it was unable to resolve the IPV6 address. Seems like we need to do some changes in the whole architecture to make it workable with IPV6. Les looked at pinger2.pl, it verifies the address is IPv4 4 octets. He made a suggestion to use valid_ip.pl to verify both ipv4 and ipv6 addresses. Ghulam are there other parts of pinger2.pl that need modifiying. It already can access ping6. In addition one will need a copy of pinger.xml with IPv6 hosts and their addresses.

A possible project would be to make traceroute.pl work on a dual stack IPv6 host (say to traceroute to ipv6.google.com). Will need to look at gethostbyname etc. Is there any interest?

Another is to make pingtable.pl and getdata.pl IPV6 capable, again this could use valid_ip.pl. Since Ghulam is working on these it would be good for him to add this.

pinger2.pl

There was a bug in pinger2.pl that resulted in the <BeaconList> being empty. Les has made many mods to not delete the old copy or the update time until after the new <BeaconList> is successfully loaded and to provide more detailed logging to assist if the problem still occurs. It is in production at SLAC. Unfortunately SLAC has not exeperienced a loss of <BeaconList> so we cannot test. Joun has been notified of the new version. It needs to be tested, i.e. <BeaconList> is not lost or if it is the log will help us understand and fix the problem. Once it is fixed then we will need to re-create the tar file /afs/slac/g/www/www-iepm/pinger/tools/pingER-2.0.4.tar.gz and update the various Pakistani monitoring machines. Joun have you had a chance to install the new version (2.0.4), if not please pick up the latest version at http://www-iepm.slac.stanford.edu/pinger/tools/pinger2.pl

Joun has installed the new pinger2.pl at cae.seecs.edu.pk, maggie2.seecs.edu.pk, aup.seecs.edu.pk, we now await the next refresh of the <BeaconList>

HEC Report - Anjum and Amber

The report has been sent to Anjum. Its also placed in Case studies at https://confluence.slac.stanford.edu/display/IEPM/PERN+Six+Monthly+Report+%28June+2011-+November+2011%29.

Dr. Anjum has asked Imdad fro some required changes in the report. They will be presenting 6 monthly data to HEC on coming Monday.

Pakistani Hosts

  1. There is a discrepancy between the PERN monitors reported by Joun as not working and those SLAC is able to gather data from (reported in checkdata, here). It was reported a couple of weeks ago. Kashif and Joun are looking at it. For example we are unable to gather data from pinger.pern.edu.pk, there is something strange with the wget not working (see here). This maybe tied to some improvements to security installed on Dec 14th. Les confirmed there are still problems affecting 4 PERN POP nodes and 12 other Pakistani monitors. See Hosts pingable from some regions but not others for more details.
    1. Currently pinger.pern.edu.pk is not pingable so we are unable to test further. Progress
    2. All nodes deployed at PERN PoPs are being upgraded to enhance security. Anjum had discussed with Umar as to what security features should be implemented on these nodes. 
  2. In addition some PERN POP monitoring hosts (pingerisl-fjwu.pern.edu.pk, pingerisl-qau.pern.edu.pk, nuisb.seecs.edu.pk, nukhimain.seecs.edu.pk and pinger.pern.edu.pk ) are only pingable from Pakistan and Jordan. This may or may not be related. This needs to be resolved.  Using reflector.pl to ping nukhimain.seecs.edu.pk and also www.cern.ch, the number of landmarks able to ping nukhiman was 26, while for cern it was 106. It appears only landmarks in Pakistan, Algeria, India, Brazil, and Russia can ping nukhimain. Kashif and Joun are looking at. Progress
  3. Kashif reports we need a system for air university because they have a shortage of systems. Anjum
    The status of hosts as of 20th Jan and 8th Feb, 2012 is available here .

Responsible person: Joun Muhammad

HEC is sending out letters to the contact persons (who are non-cooperative) after which the nodes will be more reliable. 2-3 weeks will show much more stable nodes. Any progress?

Joun is looking at archiving the reports where we can get at them if we need to mine them.  Ghulam will be helping him in this.

PingER Archive Site - Ghulam

Ghulam has rebuilt the database.

After all  the discussions, it was decided to try the database scheme for any previous one month data to see the further steps required for sharding and managing the data. As PerfSonar has some fields which are not measured/needed by pingER, they can be left NULL. PerfSonar libraries will take that a NULL. The  fields which are required by pingER but not  applicable in PerfSonar, will be added in table. PerfSonar libraries will ignore these new added columns. Progress Ghulam

Current Schema : see here|^updated pinger schema(18jan).docx|||\

There will be three tables(just like Seecs schema)

  1. host table: will have PerfSonar host table fields and location_location fields (only which are required by PingER) plus pingER required feilds.
  2. data table will be the same as new proposed one.However packet recieved/sent if used by pingER packet loss calculation or in anywhere can be added in data table.(Sadia believes there might be some PerfSonar library which will deal with it. She will see and tell Ghulam if there exist any)
  3. Add "by-class" field as required by pingER in metadata table.

Raw data for one month will be dumped into database and aggregation will done only for monthly data( which means one extra table for selected month for time being) Progress?

Ghulam: 

  1. Build database based on new schema(Send it to Sadia as well so same database can be built at SLAC)
  2. Modify getdata.pl(fine if its without parallel loops or threads as long a sit takes less than 5-6hours
  3. Run and test the getdata.pl
  4. Test it with queries as if one gives from pingtable.pl html page and measure the performance

Sadia 

  1. Modify getdata.pl to shift data from flat files to database

Ghulam is working on modifying getadata.pl to work without threads.

Future concerns:(Will be considered once  the performance of above monthly aggregated data is observed)

  1. How to store raw data for one year
  2. How should it be sharded
  3. For how long data should be in database

Sadia :Adding max RTT and Alpha to pingtable.pl and the analyze scripts 

  • We need the alpha for identifying strange Pakistani routes. This will be done before we move to the new schema, it cannot wait anymore. Sadia has modified analyze hourly and analyze daily for Max RTT, MOS & alpha. Now she has to run for all days back to 1998. This is in progress
  • Ghulam there was some problem in pingtable.pl alpha value. For some links alpha was having value of 200 . As we know alpha can have maximum of value 2. So there must be something wrong in calculation. Progress

TULIP - Bilal

One is to change the appolonius code, and the other is to give up on appollonius as we have already proved that Appollonius is useless.

Bilal: Remove apollonius. Bilal Says:

"We cannot completely remove Apollonius code because its calculations are also used in Trilateration method. Trilateration method also draw three circle with help Apollonius code because both use  ping method .If we want to completely remove the Apollonius code it will complete effect on entire  result of code. While collecting the data of North America every target is shown on map .Algorithm will only collapse when something wrong in Tulip Database not due to inactive of landmark’s .I think it is not a good option to remove the Apollonius code. I made some changing in code like throw exception but it still collapse."

Bilal will be delivering three tasks in this week:

  1. Trying stress testing with reflector instead of reflex. Results are available at Target Data for reflector tier all.
  2. Writing a report about the stress testing of all the regional results and the comparison of reflex and reflector results.
  3. A draft of the paper of Tulip work.
  4. Complete data report will be presented in the next meeting. The errors should be given in terms pf lat and long and not in terms of distance.
PerfSONAR (Pakistan)
  • Bilal and Ghulam will have a meeting with Zafar to know about PerfSonar and to maintain it in future. Update?

Possible projects

  • There can be a paper kind of talking on Pinger if we could just find the right conference. MCN, ICC and Globecomm do provide network monitoring topics. We can talk of GEO-Location experiences. For example within Pakistan it works fine, however as we go within regions or continents this gets worse. We can publish some stats on that for example. We are yet not ready for Tulip paper.
  • See [https://confluence.slac.stanford.edu/display/IEPM/Future+Projects].
  • Extend the NODEDETAILS data base to allow entry support for whether the host is currenty pingable. 
  • Extend Checkdata to provide emails automatically, see [https://confluence.slac.stanford.edu/display/IEPM/Extend+checkdata+to+make+it+more+useful]. Many of the ideas in the script node-contacts.pl are a step in this direction.
  • Improve the PingER2 installation procedures to make it more robust. This might be something for the person(s) in Pakistan who are responsible for installing PingER2 at the Pakistani monitoring sites. They probably have found where the failures occurs. Also look at the FAQ, and ping_data.pl which has been improved to assist in debugging, could it be further improved (e.g. provide access to the httpd.conf file so one can see if it properly configured)? There are 2 students working on the PingER archive. Is this something they could work on?
  •  [Fix PingER archiving/analysis package to be IPv6 conformant|IEPM:Make PingER IPV6 compliant]. Will build a proposal for an IPv6 testbed. They will try various transition techniques. A proposal has been prepared and that has been submitted to PTA. Adnan is a co PI. It is being evaluated today.  A small testbed has been established in SEECS and the plan to shift some of the network to IPv6. Bilal is part of 3 students involved with PingER and they will be involved with IPv6. They are porting the PingER archive site site to using a database. They have redeveloped the archive site using Umar's documentation. They have set up a small test archive site. They have gathering, archiving, analysis. They will design a new database. They will also try a port of PingER to IPv6. 
  • Look at RRD event detection based on thresholds and how to extend, maybe adding plateau algorithm. Umar's algorithm did  not work in a predictable manner. 
  • Provide near realtime plots of current pinger data using getdata_all.pl/wget. It will work as a CGI script with a form to select the host, the ping size, and the time frame to plot. It will use wget or getdata_all.pl to get the relevant data and possibly RRD/smokeping to display the data. 
  • See above for potential IPv6 projects.

Future meeting time - Les

  1. Next meeting on Wednesday 22nd February, 2012 at 8:00 pm in US and Thursday 23rd February, 2012 at 9:00am in Pakistan.
  • No labels