...
| Info | ||
|---|---|---|
Hot to write a new ticket: Old style tickets
| ||
| Info | ||
| ||
|
| Anchor | ||||
|---|---|---|---|---|
|
| Info |
|---|
Jump ahead to old style tickets: the old style tickets (from 01/2012 to 01/2021, formerly on Google Drive) are reported as plain text at the end of this page. |
| Jira | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Info |
|---|
Old style tickets (imported from Google Drive. The original document is discontinued and deprecated). |
Data: 21/01/2021
Oggetto: Data errata su dante003 (ntp spento)
ID: 20210121.1
Autore: P.C.
Problema: La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987)
Soluzione: Il client ntp era spento. Lanciato di nuovo da utente root con il comando /usr/lib/inet/xntpd
Descrizione:
...
ATTENZIONE: Etichettatura, relativa alla vecchia linea seriale dipolo BTF, insufficiente (potrebbe indurre in errore).
Data: 17/03/2015
Oggetto: Ripetute perdite di connessione con sistemi CompactDAQ della RF
ID:20150317
Autore: A.S., R.G.
Our setup (see fig. 1) consists of three CompactDAQ crates connected to a dedicated VLan and controlled by a LabVIEW 2012 program running on a Windows computer, which is connected to the same VLan.
Fig. 1 - CompactDAQ crates connection layout
With this setup, we are suffering frequent connection drops between the Windows computer and the CompactDAQ modules (random disconnections of one or more modules installed into one or more crates). When this happens, we have to:
- stop the LabVIEW program
- recover the lost connection/s with MAX start the LabVIEW program again
At first, we deeply checked the network health and performance and it turned out to be ok.
Then — looking at our Nagios monitoring system — we looked for any correlation between the disconnection events and the Windows machine parameters logged by Nagios and we found a strict and repetitive concurrence between the connection drops and the Windows system time synchronisation events.
Fig. 2 - Plot of the Windows System Time Offset (respect to our ntp server) from the Nagios monitoring system
Looking at the Nagios “system time offset” plot (see fig. 2), three different regimes can be identified:
Until the 5th day of week 09
The synchronisation period is set to 24 hours.
The System Time drifts of few seconds per day (respect to the ntp server ) and then it re-synchronises. We didn’t experience connection drops in this condition;From the 5th day of week 09 up to the mid 6th day of week 11
The synchronisation period is set to 1 week.
The System Time drifts of about 30 s per week and then it re-syncs. We had two connection drops in correspondence of the two big re-syncs;From the mid 6th day of week 11 onwards
The synchronisation period is set to 1 hour.
The System Time doesn’t significantly drift. We didn’t experience connection drops in this condition.
We guess that something happens about the CompactDAQ connection management when contiguous TCP/IP packets have their timestamps mixed up due to the sharp time reset.
Data: 27/01/2015
Oggetto: Finestra dell’orbita in OVERSAMPLING senza nessun dato e DEVIL366 fuori comunicazione
...