Aktív témák
-
Miracle
senior tag
''A légiirányítást meg általános célú RTOS-es gépre kéne bízni...''
vagy egy kevésbé balfasz programozóra a szoft fejlesztésését. Mondjuk aki tudja, hogy az említett számláló átfordul, és tudja, hogyan kezelni kell, vagy ismeri az alternatíváit.(mert vannak)értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
tocsa
senior tag
Az egy dolog, hogy a timernek milyen a felbontása. A felbontás az, hogy mi az a legkisebb időkülönbség, amit követni tud. Pl létezik olyan timer, ami elvileg mikroszekundumban jelez ki, de valójában a felbontása ennél kisebb, milliszekundumos. Erre akkor jön rá az ember, ha a felbontásánál sűrűbben kérdezi le, és azt látja, hogy nem változik az értéke.
Az meg megint egy másik kérdés, hogy mikor csordul túl 32 biten a számláló.
Nem az az óriási emberi felelőtlenség, és butaság, hogy nem kezelték le a számláló túlcsordulást a szoftverben. (Most mit csináljanak? Tartsák nyilván egy másik regsizterben, hogy hányszor csordult már túl? LOL).Vagy használjanak másik timer API-t? Nemnem! Az a felelőtlenség és butaság, hogy Windowst használtak. Teljesen alkalmatlan még a legminimálisabb RT feladatokra is. A Linux se teljesen jó (pl. mi van ha elindul egy locatedb update), de az klasszisokkal jobb, mondjuk kernel fordítás közben lehet videózni. Ilyen funkcióba (amitől összeomolhat a rendszer) QNX és hasonlók kellenek. A helyzet az, hogy a managert (továbbiakban managga), aki vezeti a projektet nem érdekli, hogy a tényleges megoldás milyen. Még csak az sem fontos, hogy ne legyen túl drága. A lényeg az, hogy ki ken többet a zsebébe, az nyeri a tendert, és ha az Windowsos cuccokat is telepít, akkor Windowsos cuccokat is telepít. De ebbe már nem megyek bele jobban, nagyon OFF.
Azonban miközben védjük a Windowst és az emberekre hárítjuk a dolgot. Az autós példához visszatérve gondoljunk már bele, hogy egy 49 naponként túlcsorduló számláló egy szerver esetében nem olyan, mintha 500 kilóméterenként kifogyna a benzin, hanem mintha 20 kilóméterenként! És bizony eza számláló már 8 éve is így túlcsordult.
De tekintsünk vissza egy kicsit az időben! Hogy és mikor derült ez ki? Hát relatíve nem is olyan régen, pár évvel ezelőtt a világon először ment egy Windows 49-nél több napig!
Na _ez_ a nagyon LOL!
Egy ROTFLMAOWPIMP
[Szerkesztve]Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz
-
faster
nagyúr
Egyetértek, sok dolog érthetetlen ezzel a rendszerrel kapcsolatban. Miért használtak Windowst egy ilyen feladatra, miért így használták, miért nem javították, ha tudtak a hibáról, ahelyett, hogy havonta újraindítják a rendszert. Ilyen realtime feladatra nem alkalmas a Windows, de szerintem ez nem a Windows hibája, hanem azé, aki erre a feladatra kiválasztotta a platformot.
Azért a Microsoft is csinálhatna már egy GetTickCountEx-et, ami 64 bites egészet ad vissza. :D
Egygyébként nem értem ezt a 49 napos dolgot, amit írtál. A GetTickCount régóta ilyen. A 49 naponkénti lefagyás a Win95-öt érinti.
[Szerkesztve] -
Miracle
senior tag
nos, kicsit el vagytok tájolva: alapjában véve windows ellenes vagyok, ez nem azt jelenti, hogy a windowst semmire sem lehet használni. ha rendesen lecsupaszítasz egy win2K szervert, akkor a helyzet az, hogy a csilli villi(és a hibákat okozó) külső alatt egy majdnem-VMS kernel lakozik(csak kicsit okosabb), ami sajnos legalább annyira stabil, mint bármelyik UNIX(sőt). a baj csakis ott van, hogy ezt a régen dokumentált függvényt, amit nem illik 10Ksornál nagyobb appokban használni még mindíg használta valaki, és ráadásul szerver oldalon. nomeg gáz az is, hogy a megrendelő átvett egy szoftvert, amiről tudta, hogy havonta újra kell indítani. no meg az is gáz, hogy az újraindításra ezek szerint semmi nem fogyelmeztetett. de ezen esetben a windows most nem hibás.
egyébként van olyan függvény, ami lepörgött órajelciklusokat számol, meg olyan, ami megmondja mennyi órajelciklus telik el 1 mp alatt, ezzel kell operálni. biztosan van más is, én ezeket szoktam használni.
szóval ezt most nem a windowsra kenni, mert nem a windows a hibás.
talán esetleg az a programozó, aki a win32 api tervezésekor nem gondolt ~50 napos uptime-ra, de ez megbocsátható, hiszen a legjobban a m$ lepődött meg, amikor az NT4 server oprendszerüket elkezdték komolyan webszerverként használni. nem erre tervezték a win32 APIt. (alapjában véve nem is szerver oldalra tervezték)értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
Miracle
senior tag
''Egyetértek, sok dolog érthetetlen ezzel a rendszerrel kapcsolatban. Miért használtak Windowst egy ilyen feladatra,''
mert a windows alapjában véve nam rossz rendszer, és a szerver nem a windows, hanem a szar program miatt omlott össze.
''Ilyen realtime feladatra nem alkalmas a Windows''
de, igen. csak hozzáértő rendszergazdi kell neki.
''Azért a Microsoft is csinálhatna már egy GetTickCountEx-et, ami 64 bites egészet ad vissza''
csinált.
''Egygyébként nem értem ezt a 49 napos dolgot, amit írtál. A GetTickCount régóta ilyen. A 49 naponkénti lefagyás a Win95-öt érinti.''
nem a indows halt meg, hanem a program, de valami olyan hihetetlen gigászi összeomlást csinált, amit csillagászati hasonlattal élve szupernovának nevezhetnénk, ezzel gallyravégta a backup szoftvert is.értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
Gregorius
őstag
'Ilyen realtime feladatra nem alkalmas a Windows'
de, igen. csak hozzáértő rendszergazdi kell neki.
Sajnálatos módon a windows-t nem arra tervezték, hogy válaszidőt tudjon garantálni. Korlátozott körülmények között alkalmas lehet kvázi real-time feladatokra (mondjuk az esetek 90%-ban legfeljebb az emberi reflexekkel összemérhető időben tartja a lépést), de ennél sokkal több nem várható el.
Persze jó volna tudni, hogy a kérdéses légiirányító rendszernek pontosan mi volt a feladata.
[Szerkesztve] -
faster
nagyúr
válasz Gregorius #58 üzenetére
Mi is készítettünk mikrokontroller vezérlést Windows NT-re, én is ismerem a response time problémáit. Meggyűltek a gondjaink akkor is, amikor pl. sleep-et használtunk, mert csak 10ms-enként lehetett sleep-ből visszahozni a threadet. A részleteket megkérdezhetem a programozótól, aki ezt a modult csinálta.
-
faster
nagyúr
''Azért a Microsoft is csinálhatna már egy GetTickCountEx-et, ami 64 bites egészet ad vissza''
csinált.
Tudtommal nincs olyan függvény, ami a bekapcsolás óta eltelt időt mérné, és 64 biten adná vissza milisec-ben (Olyan, mint a GetTickCount, csak 64 biten adja vissza). Persze lehet rá írni egyet.
''Egygyébként nem értem ezt a 49 napos dolgot, amit írtál. A GetTickCount régóta ilyen. A 49 naponkénti lefagyás a Win95-öt érinti.''
nem a indows halt meg, hanem a program, de valami olyan hihetetlen gigászi összeomlást csinált, amit csillagászati hasonlattal élve szupernovának nevezhetnénk, ezzel gallyravégta a backup szoftvert is.
Már bocs, de én Tocsának válaszoltam, jó lenne, ha megnéznéd, hogy mire.
[Szerkesztve] -
zrbite
csendes tag
''Ilyen realtime feladatra nem alkalmas a Windows''
de, igen. csak hozzáértő rendszergazdi kell neki.
Tudtommal minden Windows EULA-jaban van egy olyan resz, ahol kijelentik, hogy nem lehet/ajanlott hasznalni olyan helyeken, ahol a szoftver hibajabol kovetkezoleg embereletben eshet kar. Itt ugyanis nem egy egyszeru valosideju rendszer kell, hanem egy nagybiztonsagu rendszer, melyben garantaltan nem tortenik hiba. A Windows nem tartozik ebbe a kategoriaba. Marcsak a fejlesztes modja miatt sem, es a meretei es nagymennyisegu funkcioja miatt is rengeteg rejtett hiba lehet benne. -
faster
nagyúr
Egyébként annyiban igazat adok, hogy mivel nem ismerjük pontosan, milyen rendszerről is van szó, az is elképzelhető, hogy akár Windows is megfelelt volna arra a célra, ebben az esetben a programozó hibázott. Ha viszont igazi realtime OS kellett volna az adott helyre, akkor az hibázott a legnagyobbat, aki a platformot kijelölte erre a célra, de a programozó is, aki úgy használta a GetTickCountot, ahogy nem illik.
[Szerkesztve] -
LordX
veterán
válasz Gregorius #58 üzenetére
''Sajnálatos módon a windows-t nem arra tervezték, hogy válaszidőt tudjon garantálni''
Héhéhééé!!!
Ne keverjük a hard RTOS-t a soft RTOS-el. Maximális válaszidőt a Win valóban nem tud garantálni, tehát nem hard RTOS. Viszont átlagos válaszidőt tud garantálni, tehát soft RTOS.
Gyanusítom, hogy a légiirányításban nem ezredmásodperc szintű válaszidő kellenek, ugyanis nem a légiirányítás irányítja közvetlenül a repülőket, hanem a légiirányítók ezen gép alapján berádiózzák a repülőgép pilótájának, hogy mit csináljon, az meg megmondja a repülőgép számítógépének, hogy mi legyen.
Vegyük észre, hogy a láncban igencsak erőteljesen emberi válaszidők vannak (két helyen is), tehát valószínűleg teljesen fölösleges hard RTOS-t csinálni oda. Soft viszont kell.
Szóval hozzáértő rendszergazival/programozóval igenis alkalmas lett volna a Windows a feladatra. -
Miracle
senior tag
''Tudtommal nincs olyan függvény, ami a bekapcsolás óta eltelt időt mérné, és 64 biten adná vissza milisec-ben (Olyan, mint a GetTickCount, csak 64 biten adja vissza). Persze lehet rá írni egyet.''
QueryPerformanceCounter és a QueryPerformanceFrequency függvények hánydosa megadja az indítás óta eltelt időt másodpercben, de van ugye lehetőség részletesebb mérésre is.
egyébként a m$ doksikban a GetTickCount függvényt nem ajánlották semmilyen szerver- szoftverhez, szerverekhez az előbb említett két függvényt illik használni.értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
Miracle
senior tag
a win platform nem gagyi. csak vannak a divatlinuxosok, akik szerint az. de nem az. azt aláírom, hogy ellenszenves a m$ piaci stratégiája(de még mennyire) és szimpatizálok a linuxal, kedvencem a solaris, illetve a W95 meg talán még a 98 is hajlamos volt fagyni nem megfefllő hardveren(az előbbi azon is) de az NT vonallal nincs semmi baj, persze azt is szét lehet cseszni ha feltelepítesz rá ész nélkül 300 appot, és nem tartod rendben a dll könyvtárakat, nem ellenőrzöd a telepített appokat, stb. stb. de ennek az oka elsősorban az, hogy ne kelljen egy komolyabb számítógépes tanfolyamon résztvenned, és valamilyen szintű affinitással rendelkezned ahhoz, hogy __használni__ tudd a gépedet. sokan vannak, akiknek a windows is bonyolult, nekik akár tetszik, akár nem a linux nem alternatíva.
értelmező késziszótár :: rekurzió --> lásd : rekurzió
-
Gregorius
őstag
Gyanusítom, hogy a légiirányításban nem ezredmásodperc szintű válaszidő kellenek, ugyanis nem a légiirányítás irányítja közvetlenül a repülőket, hanem a légiirányítók ezen gép alapján berádiózzák a repülőgép pilótájának, hogy mit csináljon, az meg megmondja a repülőgép számítógépének, hogy mi legyen.
És egyéb információs csatornák nincsenek? Mondjuk real-time adatsorokat közvetít a rádió a fedélzeti műszereknek... Nem hinném, hogy emberek kiabálnák a mikrofonba a leszállási folyosó pontos koordinátáit például. -
TudorVigyor
aktív tag
-
-
TudorVigyor
aktív tag
''De nem azok irányítják a repülőt közvetlenül, hanem az emberek.''
Nem feltetlenul, mar tobb, landolni is kepes rendszert fejlesztettek, amik emberi beavatkozast csak a masodlagos (vagy a harmadlagos) rendszer kiesesenel igenyelnek, a futokiengedest is beleertve.
De hogy mondjak valami vidamat is, a legiiranyitashoz nem kell sem hard-RTOS, sem soft-RTOS, hanem eleg a hard-CKC vagy soft-CNT is, vagy a hot-ATC, ami nem osszekeverendo a cool-ATC-vel, amivel potencialisan kivedhetjuk az elsodleges doppler-radar alrendszer nem kritikus merteku meghibasodasat, es a gepekre szerelt inercialis-GPS vegyesuzemu helyzetjeladok jelet is kezelni tudjuk, minimalis latenciaval, mikozben a masodlagos monitoron nyomhatjuk a Solitaire death-matchet XP alatt.
Csak vicceltem. -
Gregorius
őstag
és ott sincs tízezred másodperces reakcióidőre szükség
Az tök mindegy, hogy milyen kicsi reakcióidőre van szükség - illetve az alkalmazási terület kívánja meg, hogy mekkorára. Sőt, hard-RTOS rendszerben másodlagos szempont, hogy milyen nagyon gyors a rendszer, a megbízható, számítható viselkedés (átlagos válaszidő helyett legrosszabb válaszidő) a fontos. És a windows ezt nem tudja garantálni. -
Jim Tonic
nagyúr
De buta vagy.
Gondolkodj! Ha egy autóról tudom, hogy 800Km után kifogy a benzin, időben tankolok. Ha elfelejtek, nem kenhetem másra...
Ha leállt volna timer, az más tészta.
Ismét egy hír, mely az amerikaiak végtelen butaságát mutatja. Nem kell ezeknek terrorizmus, elég bajt tudnak maguknak okozni.Alcohol & calculus don't mix. Never drink & derive.
-
-
Den
veterán
válasz Gregorius #75 üzenetére
már hogyne tudná. a hírben szereplő rendszerben is megbízhatóan működött mint az párszor már tisztázva lett. Egy rajta futó szoftver hibája okozta a problémát, arra meg még egy oprendszer sem képes hogy a rajta futó programban a programozó által vétett hibákat kijavítsa. Akárhogy csűröd csavarod, itt most nincs miért a vindowst rugdosni. Ettől még belerughatsz persze, csak úgy, mert utálod, csak ne akard mindenáron ilyen nyakatekert logikával megmagyarázni. :)
www.simson4t.hu
-
Jim Tonic
nagyúr
Figyelj már oda, barátom, mielőtt baromságokról beszélsz! Ki szólta le a szoftvertermelésüket? Éppen az MS-t védtem! Emberi mulasztásról beszéltem, nem szoftverhibáról! CSAK OLVASNOD KÉNE!
Én másról beszéltem. Pl. arról, hogy a légiirányítás miért nem használt normális timert.
Ehh, felhúzom magam az ilyen felszínes embereken!
''légyszives'' = légy szíves...Alcohol & calculus don't mix. Never drink & derive.
-
Jim Tonic
nagyúr
Már csak meg kellene magyaráznod. Ha valamiről véleményt fogalmazól, azt fejtsd is ki, a sárral dobálózás a tudatlanok sportja. De Te tudod...
A helyesírásba belekötés pedig nem érv (az érv valami mellett vagy ellen szól), hanem a tiédhez hasonló kötekedés...
szerk: esetleg olvasd hozzá a hozzászólást, amire én azt a választ írtam. Hátha kivilágosodik valami...
[Szerkesztve]Alcohol & calculus don't mix. Never drink & derive.
-
rii
nagyúr
[L]http://users.atw.hu/kalobenedek/bluetooth.jpg[/L]
[Szerkesztve]piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
rii
nagyúr
namégeccer kicsinyítve ...
piros-kapszula: https://www.youtube.com/watch?v=oW-VZVYohRg
-
Jim Tonic
nagyúr
Jó, egészségedre! Én meg azon húztam fel magam, hogy az amerikai légiirányítás Dél-Kaliforniában (ami mondjuk nem kis forgalom) azon múlik, hogy valaki reseteli-e a timert vagy sem. Hogy senkinek nem jutott eszébe egy ilyen fontosságú dologban precízebb megoldásokat alkalmazni, mint pl. egy komolyabb timer. Már ne haragudj, de pontosan azért, mert amerika ekkora szoftver exportőr, illetve fejlett ország, illetve világhatalom, illenék a légiirányítást nem ilyen alapokon tartani. Ennyi.
Ha rokonod ült volna a repcsin, nem ilyen mondatokon rágódnál.
Vagy ha a te fiad lyuggatták volna ki Irakban olajért. De ez már politika...
Végezetül annyit, hogy amin felhúztad magad, az csak egy vélemény, nem szakmai tény, ergo nem ''baromság''.
[Szerkesztve]Alcohol & calculus don't mix. Never drink & derive.
-
Gregorius
őstag
már hogyne tudná. a hírben szereplő rendszerben is megbízhatóan működött mint az párszor már tisztázva lett.
Akkor és ott igen. A jó átlagos működéstől/viselkedéstől még nem lesz a rendszer kiszámítható. Nem bizonyítható, hogy tudja a határidőt tartani, legfeljebb jó sok kísérlettel le tudod mérni a rendszer paramétereit, de abból is csak egy 99%-os biztonságú becslést kaphatsz, az pedig katasztrófaveszélyes helyzetben kevés.
Akárhogy csűröd csavarod, itt most nincs miért a vindowst rugdosni.
Kalapáccsal is be lehet csavarni egy csavart, de nem biztos, hogy az eredmény ugyanolyan strapabíró lesz, mint ha csavarhúzót használt volna az ember. Szerintem az nem rugdosás, hogy kijelentem a kalapácsról, hogy nem csavarhúzó.
Történt egy rossz tervezői döntés (mármint hogy windows platformot választottak, bár a unix se lett volna jobb) meg egy rossz implementációs döntés (a kérdéses timer). Én az előbbibe kapaszkodtam bele.
Ettől még belerughatsz persze, csak úgy, mert utálod
Én utálom a windowst?? Sértegetsz! :)
[Szerkesztve] -
LordX
veterán
válasz Gregorius #86 üzenetére
Akkor még egyszer: Nem hardríltájm a környezet, tehát nem kell, hogy előre kiszámítható legyen, az átlagos terhelésre oldja meg a feladatot. Ehhez nem kell semmi számítás, meg kell mérni, hogy bírja-e, azt kész.
Átlagosan bírja a Windows. Itt (nagyon valószínűleg) nincs kritikus maximális válaszidő, tehát teljesen mindegy, hogy milyen OS-t használsz. Minden OS ma már szoftríltájm, a Windows is. (Na jó, a 9x-ek nem azok :) )
Az összeomlásnak most köze nem volt, hogy most ríltájmOS-en futott, vagy sem a program. Szar volt, 40 naponta kihalt, mert nem megfelelő rendszerhívást használt. A rendszerhívás nem rossz, csak nem arra való. -
Gregorius
őstag
Nem hardríltájm a környezet, tehát nem kell, hogy előre kiszámítható legyen
Nem vagyok róla meggyőződve, hogy ahol tíz (vagy akár egy) perc kiesés/késés potenciálisan tömegszerencsétlenséget okozhat, az nem hard-RT környezet.
A nagyon valószínűleg az kevés, vagy inkább úgy mondom, idő kérdése, hogy mikor lesz belőle probléma.
Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen