You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(24) |
Dec
(6) |
| 2002 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2006 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(8) |
Oct
(10) |
Nov
(27) |
Dec
(30) |
| 2009 |
Jan
(15) |
Feb
(13) |
Mar
(18) |
Apr
(23) |
May
(35) |
Jun
(20) |
Jul
(23) |
Aug
(7) |
Sep
(3) |
Oct
|
Nov
|
Dec
(10) |
| 2010 |
Jan
(4) |
Feb
(3) |
Mar
(5) |
Apr
|
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
|
16
|
17
|
18
(1) |
19
|
20
|
21
|
22
|
|
23
|
24
|
25
|
26
|
27
|
28
|
29
|
|
30
|
31
|
|
|
|
|
|
|
From: Juan C. R. F. <jc...@ca...> - 2000-07-18 10:54:21
|
Hi everybody.
Spanish traslation at end.
First of all, the GPS is an important accessory, but I repeat, I do not believe that it will be our tarjet.
Always it can be mounted external to Nova, as an option of the system.
The lion's share of the system clock's drift can be corrected or minimized with facility
using standard Linux tools, like "hwclock", that uses the file /etc/adjtime
to make the adjutement. I recommend you a detained reading of the manual 8 for
"hwclock " and "timed".
Extract of the manual of hwclock:
"The Hardware Clock is usually not very accurate. However, much of its inaccuracy is completely predictable
- - it gains or leoses the same amount of time every day. This is called systematic drift. Hwclock's "adjust"
function lets you make systematic corrections to correct the systematic drift."
We can use other cheap methods, as for example the clock marks issued by some radio transmiters (i.e. WWV),
using a relatively simple receiver attached to a Linux machine. Of course, also GPS, and even using a small
quartz oscillator stabilized in temperature, whose stability can become better than 1 ppm. Other systems use
a RTC chip with a stabilized quartz, all with a bus I2C, etc...
For more information about this topic I suggest :
http://seti1.setileague.org/hardware/clock/ and http://www.ubr.com/clocks/
My question is: we should integrate a GPS system for follow-up of the time in Nova?. I continue believing that not,
because there are other alternatives that operate and that can be implemented externally to Nova, it avoid thus
to consume time and resources in something that already it is makeed or that they are making other equipment.
Therefore it concerns to the error in the position, if we use a telescope type LX200, the greater weight concerning
the precision of the position will come consider the internal clock of the LX200 and by the care put in the adjustements.
The hour of the anfitrion computer is easy to adjust. Yet putting the greater care on the adjustements,
we will will have a tolerance in the positioning up to the 10%. Would not be dificult to make manual adjustements
and that these adjustements remained reflected in Nova as a shift of the calculated position. A similar system
is used to control the periodic mechanical errors (PEC).
Also we should take into account, if we use more than two serial ports or multiport cards, that our machine will
spend resources to make pooling in the ports that are not interrupt driven. I can speak of this with knowledge,
since I have a card with 8 serial ports and already I have makeed the necessary test to know the consumption
of cpu, and it is not small, though depends logically on the number on ports to control.
In any case, if you consider the GPS of great importance, I do not put objections so that appear in the RFC,
as a subsystem of control of the time. In the same way, when it is written on the implementation, we should
make reference of the other systems of control., we call them "economic".
Ah!!!, 2 minutes in a day is excessive, but it can happen, however, in my department we have more than 40
computers, and in the periodic controls that we realize on them, the shifts do not surpass 2 minutes/month!.
Concretely, of the two computers that I use in my office, one (IBM PII with OS/2 Warp 4.0) has suffered a
shift of 3 minutes from the end of April and the other (IBM PIII with Linux R.H. 6.2) only 1.5 minutes in the
same period. I must clarify that the Linux machine its permanently connected, therefore the thermal stability
is greater.
Regards,
Juan Carlos.
-- Spanish --
Lo primero de todo, el GPS es un accesorio importante, pero repito, no creo que sea un objetivo nuestro.
Siempre se puede montar externo a Nova, como una opción del sistema.
La mayor parte de los desplazamientos del reloj del sistema pueden ser corregidos o minimizados con facilidad empleando herramientas estandar de
Linux., com "hwclock", que emplea el archivo /etc/adjtime para realizar los ajustes. Os recomiendo una lectura detenida del manual 8 para "hwclock " y
"timed"
Extracto del manual de hwclock:
"The Hardware Clock is usually not very accurate. However, much of its inaccuratcy is completely predictable -- it gains or leoses the same amount of
time every day. This is called systematic drift. Hwclock's "adjust" function lets you make systematic corrections to correct the systematic drift.
It works like this: Hwclock keeps a file, /etc/adjtiime, that keeps some historical information. This is called the adjtime file.
...."
Podemos emplear otros medios como por ejemplo las señales horarias emitidas por algunas emisoras de radio, utilizando un receptor relativamente simple
unido a una máquina Linux para decodificar las señales. Por supuesto, también GPS, e incluso usando un pequeño oscilador de cuarzo estabilizado en
temperatura cuya estabilidad puede llegar a ser mejor que 1 ppm. Otros sistemas utilizan un chip RTC
con oscilador de cuarzo estabilizado, todo con un bus I2C.
Para más información acerca de éste tema sugiero que veais: http://seti1.setileague.org/hardware/clock/ y http://www.ubr.com/clocks/
Mi pregunta es: ¿debemos integrar un sistema GPS para seguimiento del tiempo en Nova?. Sigo creyendo que no, porque hay otras
alternativas que funcionan y que pueden implementarse externamente a Nova, evitando así consumir tiempo y recursos en algo que ya está hecho o que
están haciendo otros equipos.
En último caso, para mi, su orden de importancia no es grande en comparación con la gran cantidad de tareas que debemos emprender, pero podría tener
importancia en una segunda fase...
Por lo que respecta al error en la posición, si utilizamos un telescopio tipo LX200, el peso mayor en cuanto a la precisión de la posición y del
seguimiento vendrá dado por el reloj interno del LX200 y
por el cuidado puesto en el ajuste. La hora del ordenador anfitrion es bien fácil de ajustar.
Aún poniendo el mayor de los cuidados en los ajustes, tendremos una tolerancia en el posicionamiento
como mínimo del 10%. No sería dificil hacer ajustes manuales y que estos ajustes quedaran reflejados en Nova
como un desplazamiento de la posición prevista. Un sistema similar se utiliza para controlar los errores mecánicos periódicos (PEC).
También debemos tener en cuenta, si usamos más de dos puertos serie o tarjetas multiport, que nuestra máquina gastará bastantes recursos
para hacer pooling en los puertos que no están conducidos por interrupciones. Puedo hablar de ello con conocimiento de causa,
ya que tengo una tarjeta con 8 puertos serie y ya he hecho las pruebas necesarias para conocer el consumo de cpu, y no es pequeño,
aunque depende lógicamente del número de puertos a controlar.
En todo caso, si considerais el GPS de gran importancia, no pongo objeciones para que aparezca en el RFC, pero como subsistema de
de control del tiempo. Asímismo, si lo creeis conveniente, cuando se escriba sobre la implementación, debemos hacer mención de los
otros sistemas, llamemosles económicos, de control.
¡ Ah, 2 minutos de desplazamiento en un día es excesivo, pero puede ocurrir, sin embargo, en mi departamento
tenemos más de 40 ordenadores, y en los controles periódicos que realizamos sobre ellos, los desplazamientos
no sobrepasan los 2 minutos de media al mes. En concreto, de los dos ordenadores que uso habitualmente en
mi despacho, uno (IBM PII con OS/2 4.0) ha sufrido un desplazamiento de 3 minutos desde finales de abril y el otro
(IBM PIII con Linux R.H. 6.2) solamente 1.5 minutos en el mismo periódo. Debo aclarar que la máquina Linux está permanentemente
encencida, por lo que su estabilidad térmica es mayor.
Saludos,
Juan Carlos.
|