Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

  • Analysis scripts to add Mean Opinion Score and Alpha, some things need to be correctly configured. It has been deployed athttp://pinger.seecs.edu.pk/cgi-bin/pingtable.pl for testing.
  • Alpha and MOS to be implemented at SLAC site. Sadia will be doing this with the help of Zafar. Currently Ghulam and Farhan are working on synchronizing the SLAC and SEECS scripts.

TULIP

  • TULIP (reflector.cgi) is faster since Zafar added some more parallelism. There are a couple of errors being reported which Zafar will look at. Update?

CBG TULIP Integration -- FYP (Bilal)

  • Bilal has observed that if he gives more than three targets simultaneously in different tabs then SLAC only provides data for two instance others don't get data from SLAC. It may  be a connection pooling limit problem. Les has replied him in email. Update?
  • TULIP setup on maggie2 server and CBG is running on PERN machine.
  • CBG is modified to talk to TULIP. TULIP is modified for integration. (Email Bilal to know the update. And ask him to )
  • CBG TULIP integration is almost done. user request will be forwarded to the server(clients java code not server), and then it goes back to CBG code and displays the result in CBG browser.
  • Bestline requires much larger data and the data remains same for one week, so to speed up tulip using bestline we are trying to save the data separately (not picking the data runtime). Once this is done, it will speed up the TULIP.
  • Matlab licence is here; Sadia, Les, Nick and Justus need to meet to discuss the installation issues. Where are we with this?
Best Line Approach CBG-TULIP (Zafar and Bilal)

First thing is the need of landmark sets and their RTT that can be fetched from a DB (They will be designing this DB).

Currently working on bestline approach. With bestline TULIP has 70% efficiency. Bestline will run before tiering and then reflex.cgi will be used.

Next Task is to enhance bestline.m so as to read data from table and use it for calculating geographical locations.

PerfSONAR (Pakistan)

  • PerfSONAR at SEECS: Problems were fixed. NTP servers were causing considerable clock delay. Added close-by Stratum 1 NTP servers to solve the problem. Nodes were updated to PerfSONAR version 3.2 (Fedora distro). Nodes however are offline since they were disrupting normal traffic. We are waiting for 10 Mbps dedicated connection to switch the nodes back on. We have a 1 Mbps link for PerfSONAR (on temporary purposes). NUST is purchasing a 2 Mbps dedicated link from WorldCall. No progress yet .. routing issues are showing live IPs as inaccessible.
  • PERN will deploy perfSONAR at HEC/Quetta. Someone is working on this. The university is close by HEC/Quetta. Hope in 4 weeks to have PingER monitoring node in 4 universities in the Quetta region.
  •  Dr. Anjum is trying to get some live IPs for deploying PerfSONAR, however, no progress yet.

Possible projects

  • The problem is that many hosts do not give high priority to pings and many block it. This results in high RTT for pings. It is a big difference for closer hosts than far hosts. Note the response time of pings vs HTTP hosts from slac to other hosts.
  • 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.
  • Wiki MarkupSee \ [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. 
  • Wiki MarkupExtend Checkdata to provide emails automatically, see \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. 

Future meeting time - Les

  1. Next meeting will be on Wednesday 24th August at 8:30 pm in US and Thursday 25th August at 8:30am in Pakistan.