next up previous


INTERNAL DRAFT, DO NOT DISTRIBUTE.






TB-states

Henk Uijterwaal[*]

RIPE-NCC
July 8, 2000

1 Which states do we have?


 \begin{figure}
% latex2html id marker 60

 \centerline{
\psfig {figure=states.ep...
 ...tween the states. The transistions are numbered for easy reference.}\end{figure}

Figure 1 shows the states and the possible transistions between them.

Reserved
The reserved state is intended for test-box IDs that have been assigned to a site, but no test-box reached the physical place yet. It is safe to consider test-boxes as RESERVED during initial installation in RIPE NCC workshop since no process should run in this state.
Off
The test-box exists and has arrived at the host site (for first installation). It is, however, not connected to the Internet yet (or reachable from the NCC). Boxes that have temporarily left a host site (e.g. for repairs) but are expected to return, are considered off.
Setup
The test-box is on the net and can be reached from the NCC. However, more work is required on installation or repair before the box can be used for data-taking.
Watch
The box is on the net, installed but the experimental conditions are such that the box cannot produce reliable data. (Reliable means the experimental errors in the data are small w.r.t. the quantities measured).
On
The box is on the net, properly installed and can be used to produce reliable data.
Historic
The historic state is intended for test-boxes that once existed but have been removed from the chain permanently, with no chance that they ever return. Information is kept for historic purposes, for example, when analyzing old data, one might need the location of a test-box that once existed.

2 Which processes should run when?

Which processes should run when is shown in table 1.

No processes should run when the box is in the Reserved or Historic state.

CFE should actively check that processes that should not run in a particular state are terminated should they still exist.


Process Off Setup Watch On historic reserved
Test connectivity            
by NCC (1) Yes Yes Yes Yes No No
Update software No Yes Yes Yes No No
Update configuration No Yes Yes Yes No No
- Chainfile Yes Yes Yes Yes No No
Data-taking            
- clock-monitor (2) No Yes Yes Yes No No
- data-taking (3) No No Yes Yes No No
Collect data No Yes Yes Yes No No
Analyze            
- Always (4) No No Yes Yes No No
- ``Good data'' (5) No No No Yes No No
Clean-up of old data            
on TB No Yes Yes Yes No No
TB-alarms No No No Yes No No
Configuration files            
- DNS file Yes Yes Yes Yes No No
- LIST_OF_TESTBOXES Yes Yes Yes Yes Yes No
- list_of_testboxes No No Yes Yes No No
- WWW-pages            
$\bullet$ empty/grey Yes Yes No No No No
$\bullet$ with data Yes Yes Yes Yes No No
- GPS Info Yes Yes Yes Yes No No
- MAPS Yes Yes Yes Yes No No
caption

[x] Which processes run in which state.


Some comments on the table:

1.
This is the replacement for the current restart process, it should check that the box can be reached from the NCC.
2.
clock_monitor, log_data, TailDaemon
3.
router, send_packet, receive_packet
4.
Analysis that can be done regardless of the quality of the data.
5.
Analysis where it is important to have reliable data (for example: performance scores).

3 How to move from one state to another

For the time being, by hand. As a longer term action, we should establish a list of conditions that always trigger a certain state change. This can then be added as ``artificial intelligence'' to the system. For example: if a box fails the connectivity test X times out of Y, then it should move to OFF.

4 Questions/Open issues

About this document ...


INTERNAL DRAFT, DO NOT DISTRIBUTE.






TB-states

This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997) + CO (February 20th, 2002 Manually)

Copyright © 1993, 1994, 1995, 1996, 1997 Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 states.

The translation was initiated by Henk Uijterwaal on 7/8/2000


Footnotes

...Uijterwaal
Email: henk@ripe.net


next up previous

Henk Uijterwaal
7/8/2000