Changes between Version 36 and Version 37 of GEMINIv1.1Tutorial


Ignore:
Timestamp:
10/23/12 10:48:04 (11 years ago)
Author:
Ahmed El-Hassany
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEMINIv1.1Tutorial

    v36 v37  
    393393[[Image(s6.png,border=1)]]
    394394
     395
     396
     397
     398=== 3) Configure I&M tools and experiment services ===
     399
     400==== 3.1)  Configuring Passive measurements ====
     401
    395402[wiki:GeminiPortal Intro To Gemini Portal]
    396 [[BR]]
    397 [wiki:PathControllerDemo Path Controller]
    398 
    399 === 3) Configure I&M tools and experiment services ===
    400 
    401 ==== 3.1)   Configuring Active Measuremens ====
     403
     404
     405==== 3.2)   Configuring Active Measuremens ====
    402406
    403407
     
    409413
    410414
    411 ===== 3.1.1 Accessing pSConfig UI =====
     415===== 3.2.1 Accessing pSConfig UI =====
    412416
    413417To configure active measurements we access the pSConfig Web UI. You can find the URL by clicking on the MC node on the GEMINI portal, or by going to https://<gn node>/psconfig.
     
    427431[[Image(0-unis.png)]]
    428432
    429 ===== 3.1.2 Enabling Services =====
     433===== 3.2.2 Enabling Services =====
    430434
    431435After we've made sure to have a recent copy of the topology information, we can move on to the Manage Services administration page. On this page we will enable the services required to perform on-demand and regularly scheduled tests. We start by enabling the  one-way latency services on VM1. Make sure to save the changes before continuing to the next node.
     
    453457
    454458
    455 ==== 3.2 Configuring Regular Active Measurements ====
     459==== 3.3 Configuring Regular Active Measurements ====
    456460
    457461Enabling the OWAMP and BWCTL daemons is all we need to perform on-demand active measurements. However, it's usually better to have active measurements running regularly to analyze the performance over time. Throughput and ping tests can be scheduled with a given interval (e.g. every 30 minutes). One-way delay tests are scheduled as a stream (a constant amount of packets is sent per second).
     
    482486[[Image(10-unis-push.png)]]
    483487
    484 ===== 3.2.1 Applying the Configuration =====
     488===== 3.3.1 Applying the Configuration =====
    485489
    486490pSConfig will pull the node's configuration from UNIS every 30 minutes (from the time it was started, not hh:00 and hh:30). Since we don't want to wait this long to start gathering data, we can restart pSConfig on each node by clicking the Apply Config link. This is achieved by ssh'ing to the node and restarting pSConfig, so errors are usually ssh related.
     
    493497 
    494498=== 4)  Run and orchestrate I&M services and experiment services to complete run of experiment ===
    495 
    496 
    497 4.1)  Initial setup:  start basic host measurements and basic ping active network measurements
    498 
    499  - objectives:
    500    - verify functionality of hosts
    501    - verify topology of slice
    502 
    503  - observe measurements with a real-time presentation service
    504  
    505  - continue measurements throughout duration of the test/tutorial/experiment
    506  
    507  - at completion:
    508    - functionality of hosts and topology of slice has been verified throughout duration of the experiment
    509  
    510  
    511 4.2)  Continuity test:  for a limited time, run iperf active network measurements
    512 
    513  - objectives:
    514    - verify ability of slice to carry traffic expected from experiment
    515 
    516  - observe measurements with a real-time presentation service
    517  
    518  - once satisfactory measurements have been observed, stop continuity test
    519  
    520  - at completion:
    521    - capability of slice to carry traffic expected from experiment has been verified
    522 
    523    
    524 4.3)  Instrument and run experiment: 
    525 
    526  - objectives:
    527    - gather measurements during experiment that allow experiment goals to be met
    528    
    529  - include desired measurement points within hosts and/or experiment services to instrument test/tutorial/experiment
    530  
    531  - begin to run and orchestrate measurement services
    532  
    533  - begin to run and orchestrate experiment services
    534  
    535  - observe measurements with a real-time presentation service, to verify expected operation of experiment
    536  
    537  - collect all measurements for duration of experiment
    538  
    539  - stop experiment services, when this run of the experiment has been completed
    540  
    541  - stop measurement services
    542  
    543  - at completion:
    544    - one run of experiment has been completed
    545    - real-time look at measurements has verified expected operation of experiment
    546    - a full set of measurements has been collected, for later analysis and presentation
    547    - collected measurements have been transferred to storage service, so that slice resources can be released (if desired)
    548    
    549 4.4)  Store collected measurements and other artifacts from test/tutorial/experiment in storage service
    550 
    551  - at completion:
    552    - collected measurements and other artifacts have been transfered to storage service
    553    - collected measurements and other artifacts are available for later analysis
    554    - slice resources can then be released at any time, without loss of any measurements or artifacts
    555    
     499[[BR]]
     500[wiki:PathControllerDemo Path Controller]
     501
     502
    556503=== 5)  Analyze and visualize measurement results after completing run of experiment ===
    557504