Idő...

Alaplapok

Üdv!

Elkezdtem a napokban irtani a gépemről a gány megoldásokat, és eljutottam az idő problémájához.

Ugyanis, nekem xp és frugal dualboot gépem van. Jelenleg mindkét rendszer localtime-ot használ, amivel alapjában véve nem is lenne probléma. Csakhogy amikor óraátállítás van, akkor a windows automatikusan átáll, a linux viszont nem. Ez így annyira nem rossz, mert ha bootolok egy windowst, akkor átáll. Nade ha nekem nincs kedvem windowst bootolni, akkor linuxon nem áll át az óra. Viszont ha átállítom linuxon, akkor lehet, hogy a következő windows bootoláskor még egyszer átállítódik az óra.

Első körben arra gondoltam, hogy átállítom az xp-t is, és a linuxot is utc-re. (Windowshoz help itt.) De aztán rájöttem, hogy ez nem biztos, hogy megoldja a problémámat. Szerintetek?

Szóval ebben a kérdésben kérem a segítségeteket!

  • 2055 megtekintés

( bitumen | 2008. 04. 07., h – 22:28 )

ntpupdate bekapcsn'al? vagy az is tul g'any? ;-)

Elvileg mind2 rendszeren megy. 


$ ps aux|grep ntp
root      3685  0.0  0.0   3156   944 ?        Ss   14:30   0:00 /usr/sbin/ntpd
_ntp      3686  0.0  0.0   3060   916 ?        S    14:30   0:00 /usr/sbin/ntpd
tibi     32464  0.0  0.0   4252   752 pts/0    R+   23:00   0:00 grep ntp

Mind2 rendszeren a time.kfki.hu van beállítva. De én úgy tudom, az ntp inkább csak a kisebb eltéréseket tudja pontosítani, az egy órást már nem... Erre meg van másik szolgáltatás, csak az meg már gány lenne. :)

"time.kfki.hu mostanában (nekem legalábbis) nem válaszol." 

PING ubul.kfki.hu (148.6.0.1): 56 data bytes
64 bytes from 148.6.0.1: icmp_seq=0 ttl=56 time=18.6 ms
64 bytes from 148.6.0.1: icmp_seq=1 ttl=56 time=16.5 ms
64 bytes from 148.6.0.1: icmp_seq=2 ttl=56 time=17.0 ms
64 bytes from 148.6.0.1: icmp_seq=3 ttl=56 time=17.8 ms
64 bytes from 148.6.0.1: icmp_seq=4 ttl=56 time=17.6 ms
--- ubul.kfki.hu ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 16.5/17.5/18.6 ms

Válaszolni legalábbis válaszol.

Most hirtelen nem tudom megmondani, hogy szinkronizálni tud-e, ntpd ahogy látom csak akkor hajlandó azonnal frissíteni, ha 3 percig nem ment a helyi óra. Az pedig menet közben ki van zárva. Esetleg holnap bootolok egy windowst, abban van ilyen gomb, hogy azonnali frissítés. :)

Aztán:

-sSet the time immediately at startup if the local clock is off by more than 180 seconds. Allows for a large time correction, eliminating the need to
run rdate(8) before starting .

( Nyosigomboc v | 2008. 04. 08., k – 01:50 )

Ezt en ugy oldottam meg, hogy xp-n kikapcsoltam az automatikus oraatallitast, Ubin meg bekapcsolva hagytam. Az ido jelentos reszeben az utobbi fut.

----
Sooner or later you had to talk, even if it was only because you'd run out of things to throw. - Pratchett
honlap készítés

( mazursky | 2008. 04. 08., k – 11:44 )

Én a gépeimen a hardware clock-ot beállítottam nyári időszámításra, még évekkel ezelőtt. Azóta néhány percet már "rásiet", de mindegy, legalább nem kések el, ha menni kell valahova.

A disztrók is a hardware_clock-ból olvassák az időt. Az ubuntun ehhez ki kellett irtanom az ntp és localtime dolgokat (dehát jó parancs az rm).

A téli időszámítást humán_intelligenciával "állítom be": marad a nyári időszámítás, és levonok az órából 1-et. Miért olyan bonyolult ez?

/mazursky

( asch v | 2008. 04. 08., k – 11:47 )

A szép megoldás az UTC használata. A fizikai óra átállításánál nagyobb hülyeséget programozó nem találhatott volna ki.

Persze az UTC használata mellé beállíthatod hogy ntp-vel szinkronizáljon valami szerverhez a gép és akkor a kis csúszások is meg fognak szűnni.

Szóval ha a gány megoldásokat írtod, akkor a géped fizikai órája legyen UTC és ne állítgassa senki sehova!

Ok. Ez eddig is 90% volt, hogy beállítom utc-re, csak maradt egy kérdés. (Aminek akár utána is nézhetnék a neten...) Miszerint ha utc-t használok, akkor megoldódik-e ez a téli-nyári időszámítás probléma? Tehát a rendszerek tudni fogják, hogy mennyit kell hozzáadniuk az utc időhöz? (Nyilván be kell egyszer állítanom, de utána?)

( uid_4672 | 2008. 04. 08., k – 12:19 )

idézet a MSDN tzset függvényleírásából:

"Three-letter daylight-saving-time zone such as PDT. If daylight saving time is never in effect in the locality, set TZ without a value for dzn. The C run-time library assumes the United States' rules for implementing the calculation of Daylight Saving Time (DST)."

Szóval a májkroszoft C library csak a US szabályokat hajlandó figyelembevenni, ami a dátumállítást illeti. szívtunk is vele rendesen...

( gmesko | 2008. 04. 08., k – 16:04 )

Nálam a dual boot miatt, a gépi óra a local time-ot mutatja. Igy a winnek jó.
A linux ugy van konfigolva, hogy a gépi óra nem UTC-t, hanem local time-ot mutat.
Elég rég csináltam meg, azóta nem nyúltam hozzá, mintha a hwclock utilitire emlékeznék, hogy azzal állítottam.

Ja és mindkét rendszeren szinkronizálom az időt. :)

Na hát épp ez az, nálam most pont ez a helyzet, amit leírtál. Nem is ez a baj, hanem az, hogy a windows automatikusan átáll nyári időszámításra, a linux meg nem. És ha én egy hónapig nem bootolok windowst, akkor egy hónapig nem áll át az óra. Tehát olyan megoldást keresek, ami virtuálisan állítgatja át magát, és mindkét rendszeren megy. Az utc épp ezért lenne jó (ahogy látod, megy windowson is, ha átállítják), csak nem tudom, ez megoldja-e az eredeti problémámat.

( BaT | 2008. 04. 14., h – 20:24 )

Mintha nem írtam volna, hogy átállítottam a két rendszert UTC-re. De úgy néz ki, mégsem annyira működik jól, mint kellene. Ugyanis, miután bejelentkezek Windowson, az óra 2 órát késik. Érdekes módon, ha szinkronizálom egy ntp szerverrel, utána rendbe jön, és a helyes időt mutatja. Tehát vagy az ntp szerver által küldött időt fogadja el a valós időnek, vagy valami hülye bug miatt nem automatikus az utc, a beállítás ellenére.

Van ötlete valakinek?

Szerk: próbaképpen átállítottam anya laptopját is, azon csak XP van, és úgy látom, azzal nincs probléma... Érdekes...