...
SLAC SEECS
...
Status report May 22nd, 2012
General
The SEAMEW cable cut off Alexandria at about 12noon Pak time May 11th was observed in the monitoring stats of Micronet. As a result I have added two Nayatel/Micronet hosts to the PingER monitoring at SLAC? One connects via TransWorld the other by PTCL.
...
Maggie is not working due to no disk space. Les does not recognize any of the files. Anjum gave the go ahead to clean /tmp/
We are about to order new hardware for the PingER monitoring host at SLAC and the www-wanmon web server.
HEC Report - Anjum, Amber and Imdad
Amber will prepare the report when Amber gets back to SEECS. Progress, Amber, do you need any help?Amber is working on this report. The basic structure is the same as was of the last 6 monthly report. She will be sharing the report in a few days.
Pakistani Hosts
There are some Pakistani nodes that are recorded as working from SEECS while they are not working from SLAC. This mismatch was recorded by Amber and Joun. Amber and Joun will get together and see if the problem still exists or not.
- Les
...
- looked at which Pakistani monitoring hosts SLAC is unable to gather data from since the start of May. They are as follows:
- hu.seecs.edu.pk aka PK.HU.EDU.N2 does not appear as a monitoring host in SEECS pingtable.pl. Also SEECS pingtable.pl has no data this month from AIOU to hu.seecs
- lse.seecs.edu.pk aka PK.LSE.EDU.N3 does not appear as a monitoring host in SEECS pingtable.pl. Also SEECS pingtable.pl has no data this month from AIOU to lse
- pinger-itc.pu.edu.pk aka PK.PU.EDU.N2 does not appear in the SEECS pingtable.pl as a monitoring host
- pinger.giki.edu.pk aka PK.GIKI.EDU.N1 does not appear as a monitoring host in SEECS pingtable.pl
- pinger.uaar.edu.pk aka PK.UAAR.EDU.N1 does not appear as a monitoring host in SEECS pingtable.pl
- pinger.ustb.edu.pk aka PK.USTB.EDU.N2 does not appear as a monitoring host in SEECS pingtable.pl
- sbkwu.seecs.edu.pk aka PK.SBKWU.SEECS.EDU does not appear as a monitoring host in SEECS pingtable.pl
- Should they be designated as Monitoring hosts?
- Amber reports: Looking at this weeks status report on wiki, the list of the nodes which are not monitoring nodes in SEECS pingtable but are monitoring nodes at SLAC can be due to the fact that these nodes are the usual problematic nodes since months. It might be possible that SEECS team (who manage SEECS pingtable) have made these nodes as remote nodes to avoid hassle. However, I shall confirm this from Kashif tomorrow and will update you on this. If this turns out to be true, I shall change these nodes to remote nodes in SLAC pingtable as well.
FSBD POP have high unreachability values, which is not acceptable. They are looking into it. Backhaul network is currently leased from PTCL however in 3-4 months they will replace it with their own network. There would be no commercial traffic on it. As a result it is expected that RTT and losses will improve drastically. So next 6 months are important for observing the network performance.
PingER Archive Site - Sadia
| Wiki Markup |
|---|
Current Schema : see \[here\|IEPM:Pinger+PerfSonar schema\]. |
Sadia has partially implemented the new schema so now awaits finalization
Sadia had a meeting with Ghulam and Bilal . They gave her some relative material which she will document. It includes query regarding schema, and how to run Tulip test from Seecs machine. This would help new student to generate the reports for regions etc. As far as pinger database schema is concerned we need to discuss it with someone like Zafar who has worked on Perfsonar to see is it feasible or not . The main concern is that PerfSonar has single table for raw and analyzed data and it keeps data for not long enough like pinger. What Ghulam suggested is that there should be two main tables raw and data separately. Raw will have node id, ping sequence no, rrts , packet sent, packet received similar to what is currently in raw flat files. It will then have multiple tables to store either yearly or 6months data in each table. Similarly for analyzed data there would multiple hourly tables ,multiple monthly table and so on.Each table will be similar to analyzed data as in pinger a flat files. In such a case it will be different from PerfSonar where everything is in one table and if we place everything what is in raw table into analyzed table, there will replicate date(like 4 columns min/max/avg rtts and seqno) however it will be similar to PerfSonar.
The other query has to do with the timestamp. The timestamp is unique key in pingerDB assigned by Ghulam. So e.g
| Code Block |
|---|
pinger.slac.stanford.edu 134.79.240.30 www.eldjazair.net.dz 193.194.64.71 100 1208217601 10 10 217.063 218.753 223.276 0 1 2 3 4 5 6 7 8 9 219 219 217 218 218 218 217 223 217 218
pinger.slac.stanford.edu 134.79.240.30 www.eldjazair.net.dz 193.194.64.71 1000 1208217611 10 10 219.238 221.357 227.909 0 1 2 3 4 5 6 7 8 9 220 220 221 221 220 227 219 222 219 219
|
For above two record, method would be 1 and timestamp as 1208217601 for both .Database wont allow to add two duplicate records. However its not duplicate, its for two different packet sizes. What Ghulam suggested is to add another column as data_id with auto increment property. It will give each record a unique number. What Sadia believes could be done is to make packet size also unique key.
The last work done by Ghulam was to save raw pings like old pinger schema meaning concatenating pings for one hour. However we had decided , it would be storing all 48 pings half hour pings/day. So this is also left to be done.Sadia will prepare documentation and upload all information provided by GhulamOnce the database at SEECS is ready then Joun can move the data. Ghulam needs to interact with Zafar or Umar. Umar will contact Zafar and see if he can spare sometime. Sadia will work with Ghulam to document his questions on the schema so Umar can work with Zafar to provide feedback. Ghulam has recovered from his illness, but had little to report, so Sadia has made little progress. Sadia might have to do this all on her own.
Future concerns:(Will be considered once the performance of above monthly aggregated data is observed) We await a working version before this can start.
...
Bilal needs to add the number of landmarks in the region for his Excel Spreadsheest. This will be useful for his paper, i.e. reporting typical accuracy as a function of landmarks in region.unmigrated-wiki-markup
Another interesting study would be whether using different alphas (in distance\[km\]=alpha*min_RTT\[ms\]*100\[km/ms\]) based on the alphas found in PingER for the various regions (see for example[http://www-wanmon.slac.stanford.edu/cgi-wrap/pingtable.pl?file=alpha&by=by-node&size=100&tick=daily&year=2012&month=03&from=United+States&to=United+States&ex=none&only=all&dataset=new&percentage=any]) provides much benefit compared to the single current value of alpha. To facilitate this we have added PingER groups for N.AMERICA, EUROPE, AUSTRALASIA, S.ASIA, S.AMERICA.
Bilal will be sending the tulip draft paper before he leaves the job.
...
- There can be a paper about Pinger if we could just find the right conference. MCN, ICC and Globecomm do provide network monitoring topics. It could talk of the various metrics and their importance (in particular; MOS, Alpha, max RTT, min RTT), the lessons learnt from running such a worldwide infrastructure, the uses of the data etc.
- 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 can add the impact of changing alpha. We can also indicate the importance of landmark proximity.
Wiki Markup - Extend the NODEDETAILS data base to allow entry support for whether the host is currenty pingable.
- 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.
...