Pontosan így van. A kimenő feszültség az áramterheléstől függ (pillanatnyilag milyen eszközökön milyen program fut, vagy nem fut). A tápegység visszaszabályozása, és a csatlakozók meg a kábelek ellenállása véges érték.

Nem csak a szoftver miatt, hanem maga a hardver, ami mér (aminek aztán a mért adatait mutatja a szoftver), az sem pontos egy alaplapon.
Aztán látod, ha még a szoftver sem jól számol utána, az csak tetézi a pontatlanságot.

A másik, hogy még ha véletlenül éppen pontos is a hardver, az, hogy kijön egy szám néhány másodpercenként, hogy mondjuk 5.02 V, az nem jelent semmit, csak valamiféle átlag (ha folyamatosan figyeled, akkor láthatod is, hogy egy tartományon belül mozog folyamatosan)
Igazából nem egy egyenes vízszintes vonal a képe, hanem egy "recés", vagy "göröngyös", esetleg kisebb-nagyobb tüskékkel tarkított görbe.

Előbb kellett volna mérni.
Nálam az Ultimate is hülyeséget ír ki. Egyész egyszerűen a Winbond átalakító sz.ar. A program csak rossz adatot dogoz fel.

Üdv! Everest free átverése miatt vettem új tápot, mert rinyáltam, hogy valami elszáll az idétlen értékek miatt. Az új tápon is hasonló volt a helyzet. Megmértem a feszültségeket és kiderült, teljesen normálisak. Ultimat-tal jó értéket mutatott. A régi tápnál is. Elsőre semminek nem lehet hinni, míg nincs megbizonyosodás.
Van tartalék tápom.

Nagy cégeknél az nem úgy megy, hogy 20 vagy 40 ezerért vegyünk-e alaplapot.
Hanem vesznek 110-ért! Abból 50 az enyém, 50 a tied és 10 az alaplap.
Szóval sajna abszolúte nincs beleszólásunk...

+ alaplapból is. És ennyiben maradhatunk!

A szoftveres mérés nem mérés, gyakorlatilag semmit sem jelent.

Néha előfordulnak X-aktás ügyek, ez van.
Tápból érdemes márkásabbat venni.

a kettõ (a hibás alaplap + táp) okozta a jelenséget.

Lehet, hogy a kvarc időalap nem szerette a noname táp instabil feszültségeit?

Az egész egy áramszünettel és táp füstöléssel kezdődött. Azóta vacakol az óra, mióta egy NoName táp be lett szerelve. A bekapcsolása is bizonytalan, csak teljes áramtalanítás után lehet indítani. Illetve lehetett! Mert ma reggel ki lett dobva, és egy márkás, atombiztos, high-end tápegység lett beszerelve: Codegen 300 Most néztem az atomóra szinkron naplózását. Pöpec, semmi eltérés. Szóval most jó, de az összefüggéseket nem értem. Olyan, mintha esetenként pár percre lefagyizott volna a gép s majd ment tovább. De ez már sosem derül ki...

Ha lapot nem is,de a quartzot ki kell dobni a mellette lévő kondival egyetemben..ez az olcsóbbik megoldás..átpakolni egy egyéb okból gallyrakerültből pl.

én is alaplapot cserélnék. Vagy egy érdekes vírus...

Boldogult dosos koromban még pascaloztam a 8254-et. Nem tudom, hogy ez az idézet a mostani alaplapokra is igaz-e?Szerk: közben rájöttem, hogy igaz, mert azok az ősi -a fenti időzítőt használó- programok dos-ba bootolva most is működnek laptop és asztali gépeken.

Meg nem mondom miért, de én az alaplapra tippelnék.

Szervusztok!

Folyamatosan fut a cégénl egy PIII 733 MHz gép XP+SP3 oprendszerrel. A feladatütemezővel 15 percenként adatokat másol, rendez, email-t küld. Hetente egyszer atomórához szinkronizál. Naplófájl szerint 3-4 mp a pontosidő eltérése 1 hét alatt. Pár hete tápegységet kellett benne cserélni. Azóta a windows rendszeridő össze-vissza késik. 6 óránként naplóztatom az atomóra szinkronizálást. Van amikor pontos, van amikor 1-2 percet korrigál, de gyakran 20-30-40 percet is késik 6 óra alatt. Most átállítottam, hogy 15 percenként szinkronizáljon. Agyilag nem vágom, hogyan függ a tápegységtől egy folyamatos üzemű gépen a windows rendszeridő? Everest szerint a +5 az 4,87 V, a többinél még kisebb az eltérés. És miért rendszertelen a késés? Eseménynaplóban semmi rendkívüli bejegyzés nincs. Noszogatom az RG-t egy újabb táp cserére, de még valami nyomósabb indok kellene, mert ez a rendszertelen késés még nem elég meggyőző neki.

A soros porttal kapcsolatos problémát én se tudom, de azt igen, hogy a process vagyis a program prioritását az
unit Windows;
SetPriorityClass(GetCurrentProcess, $100); - al lehet átállítani real time prioritásúra (Delphiben)(ha másba programozol, akkor nézz utána a dll függvények után), azért vigyázni kell a valós idejű progrmokkal, mert könnyen fagyáshoz vezethetnek!

Köszönetem mindenkinek!
Oda jutottam, hogy a Windows-t sehogy nem bírom rávenni (real time prioritás sem) arra, hogy ne várjon egy soros porti jel feldolgozásával addig, amíg jónak látja...
A cikkek is hasznosak + érdekesek voltak, de rájöttem, hogy nem ez a baj. Marad a PIC, kívül megmérendő és betöltendő az időt.
Még egyszer kösz, G.

Az időzítő programozható, és a Windows sem ezen a frekvencián használja. A SetTimer() függvénynek például ms pontossággal kell megadni mennyi idő múlva jelezzen. Ezen kívül vannak még precízebb időzítők is, mivel a multimédia alkalmazásoknak bizony az kell.

Nézd meg ezeket az oldalakat, hátha találsz hasznosítható dolgot:
http://www.weizmann.ac.il/home/chaipi/TimeTest.htm
http://technet.microsoft.com/en-us/sysi ... 97569.aspx
http://support.microsoft.com/kb/180736
http://www.xs4all.nl/~rjg70/vbapi/ref/s/settimer.html

Esetleg a high resolution timer, high precision timer kifejezésekre próbálj rákeresni a weben.

Nm. De próbáld meg a programot magas prioritásban futtatni vagy valós idejű prioritásban, akkor talán pontos lesz, bár valós idejűben nagy valószínűséggel lassú lesz a gép, de lényegében a programot nem fogja megszakítani semmi, a programnak a lehető legideálísabb környezetet kell biztosítani (felesleges programokat leállítani). Talán ez az ami még bekavar(hat)

Köszönöm a tanácsokat!
Közben sokat olvastam utána én is, s az első két módszerre rábukkantam. De sajnos rá kellett jönnöm, hogy a korábbi "érzetemen" túl nem is igazán a windows időmérésével van gond, hanem a külső eszközről kapott jelek feldolgozásával - megszakításkezelésével.
Ha nekem század pontosan meg kell mérnem két infrakaputól kapott jel között eltelt időt, azt egy soros, vagy párhuzamos port szkennelésével tudom megoldani...ehhez viszont valamilyen jelhez szinkronizált időzítő szükséges...ami az a bizonyos 1/18.2 mpen ketyeg.

Fast&Dirty megoldásban megpróbálkoztam egy egyszerű teszttel:
- "kicsomagoltam" egy egyszerű USB-s egeret
- A középső gombját - kiforrasztva - rákötöttem egy Függvénygenerátorra, ami 1 s négyszügjelet ütemelt nekem.
- Egy egyszerű program VB.Net-ben, ami az egér Click eseményét használja Now() függvénnyel a két klikk között eltelt időt gyűjti. (Ugyan tudom, hogy ez csak a 0.055-ös pontosság, de a stabilitására voltam kíváncsi)
Eredmény: Gyönyörű szépen ezzel a pontossággal ketyeg...mindaddig, amígy el nem jön egy-egy CPU peak. Akkor - valószínű a Windows miatt -a mért idő 2-3 tizedet(!) nő. Bizonytalan sajnos.
Szóval nem is a belső időméréssel van gond, hanem a jel pontos bevitelével és lekezelésével.
Marad a külső eszköz, kívül megmérve az időt és soros porton beadva az eredményt,
Köszönöm még1x!

Szerintem lehet külső eszköz nélkül is századmásodperc pontosan mérni. Erre több módszer is létezik:
-eltelt másodpercek mérése a DOS vagy a BIOS órája segítségével 0.055 (1 / 18.2) másodperces pontosságú időmérés
-a BIOS számlálója segítségével 0.00000084 (1 / 1193000) másodperces pontosság elérése
-a PIT (Programmable Interval Timer) használatával 0.000000002 (1 / 500000000) másodperces pontosság (500 MHz-en)
-a TSC (Time Stamp Counter) használatával
A legpontosabb mérési módszer az utolsó.
A TSC a legelső Pentium processzorban jelent meg először. A TSC nem más, mint egy olyan számláló, mely a processzor minden órajelütése alkalmával növekszik 1-gyel. Ennél pontosabban nem lehet mérni az időt. A TSC használata azonban csak DOS alatt egyszerű, multitaszkos környezetben csak 32 bites védett módú programok használhatják. Ha tehát egy valós módú, DOS alapú, mondjuk Pascalban íródott programban szeretnénk a TSC-t használni, akkor le kell mondanunk a Windows, OS/2 és Linux alatti futásról, hacsak nem veszünk elő valami trükköt. Pl. írhatunk egy külső, 32 bites védett módú modult (pl. DOS32, PMODE vagy Watcom C/C++ segítségével), melyet az Exec paranccsal bármikor futtathatunk, s csak a mérési paraméterek, majd az eredmények átadását kell megoldanunk...
Van még egy apró probléma a TSC-vel: mivel nagyon nagy pontosságú számláló, ezért a szélessége 64 bit, melyet egy 16 bites programban nehézkesen tudunk csak kezelni. A feladat azonban nem lehetetlen!

Üdv mindenkinek!

Az érdekelne, hogy vajon létezik e olyan külső PC hardver, ami század pontos idő tud mérni (két kapcsolás - egyszerű pozitív jel között) és a mért eredmény valamilyen porton keresztül kiolvasható.
Windows alatt sajnos azt látom, hogy nem lehet ezzel a pontossággal mérni...nekem meg az kellene ...ezért gondoltam külső eszközre. Azonban további építő ötleteket szívesen olvasnék!

Thx for all, G