111
-
dez #111 (Persze nem teljes idle-ben, hanem fut a torrentkliens a háttérben.) -
dez #110 3. Van egy olyan, hogy RightMark CPU Clock Utility, AMD procikhoz. Külön méri az OS által közölt, és a valódi prociterhelést. Nos, miközben az OS (WinXP) ilyen néhány %-okat jelez, a valódi terhelés szép csendben 30+%. :) -
#109
> Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
Ezt honnan veszed? -
#108
Szo nem volt itt szerveriparrol, sem annak a felnivalojatol. -
#107
1. Hogy neked miert lesz jobb/rosszabb azt te tudod. Azoknak viszont mindenkeppen akik csak azert nem tudnak megvenni egy igenyeiknek megfelelo hardvert, mert nincsen a celfeladathoz valasztott OS-re driver. Ha te nem ilyen user vagy akkor nem neked valo.
2. Szinten egyeni szoc prob.
3. Akkor ha nincsen kardiologus a kozeledben NE szamolj utana (benchmark), hogy az OS-ed kerneljenek mekkora az overheadje. (min 30-40%) -
dez #106 Fejlesztettem már PC-vel USB-n kommunikáló hw-t ipari célra. Mikrokontrollerrel volt megvalósítva az eszköz oldali USB kezelés, és nem mondhatnám, hogy túl bonyolult volt a program. Persze egy egyszerű soros port-kezelésnél bonyolultabb volt. Na és? Viszont jól szervezett az egész, jópár féle eszköz-típust alapból ismer, szabványosított protokollok vannak, amik lekezelése eleve benne van az OS alatti driverben, stb. Nem kell 0-ról kitalálni mindent (mindenkinek máshogy, össze-vissza), OS alatti driverét 0-ról megcsinálni, stb.
Abban a többszázezer(???) soros OS driverben nem csak egyszerűen az USB port lekezelése van, hanem jópár szabványosított eszköztípus lekezelése, protokollok, stb. Neked application-programozóként nagy részével nem kell foglalkoznod, készen kapod az adatokat. Ha valamilyen nem-szabványos eszközhöz kell is kiegészítő driver, az sem sokkal bonyolultabb, mintha egy sima soros interfészről lenne szó. -
turul16 #105 EFI drivert ugyan azok fogják irni akik winest.
Valószinüleg nem kernel space driverek rágják a memódat, hanem userspace cuccok.
AZ ELLEN NEM VÉD. -
turul16 #104 4GFC 4.25 Gbit/sec Fibre Channel. -
waterman #103 nekem spec megérne +2%-al több proci időt, ha a windóz nem 4+ gigán hanem csak másfélen terjeszkedne, mert az efi-driverek megoldják. -
turul16 #102 SAS
Azért ne féltsd a szerver piacot, nem fognak desktop csatolókra átállni. Nem biznisz nekik. -
turul16 #101 1. És akkor azok a workaroundok az EFI -ben lesznek az miért jobb nekem ?
2. De éreznék. Hatáskorömön kivüli kód miatt sokkal rosszabbul aludnék :)
3. Inkább 2% -ra saccolom minimum , ezen felül kb. 0.1 usec hozzá adódik minimum minden rendszer hívás jellegű dolgohoz. Ami sok rövid rendszer hivás esetében az idő nagyobb részét teheti ki, EFI feleslegesen rágja a 33% -ot mondjuk, vagy többet.
Real time működés, felejtős lesz. -
#100
Az USB 3.0-mat tavaly mutattak be, az lesz az ami verni fog SCSI-t, egyebeket. 4.8 Gb/s. -
#99
> Nem ezért veszek nagyobb hardwaret, hogy egy letisztultnak nevezett modell szerint felépülő nyavaja pocsékolja a hátammögöt az erőforrásokat.
Akkor megegyszer:
1. Ez a letisztultnak nevezett nyavaja - tobbek kozott - azert pocsekol hangyanyi eroforrast, hogy kesobb kilehessen szorni olyan workaroundokat a kernelekbol, hogy azok tucatjaval szabaduljanak meg mas jellegu "eroforraszabaloktol".
2. Az EFI akar virtualizacios reteg felett futtatja a user OS-t akar nem, szamottevo kulonbseget nem fogsz eszrevenni.
3. A jovo processzorai mar egyre inkabb virtualizacios extensionnel erkeznek, amik ezt a temerdek (kb. 0.1%) EFI overheadet is eltuntetik. -
#98
Jogos, en emlekeztem rosszul. Ezek szerint nem ez az egyetlen rossz diagramm (kis "b", nagy "B" dilemma). 
-
turul16 #97 Nem ezért veszek nagyobb hardwaret, hogy egy letisztultnak nevezett modell szerint felépülő nyavaja pocsékolja a hátammögöt az erőforrásokat. Ettől kisebb pocséklások miatt is lázadozok. Ill. kisebb nem elenörzött/nem látható kódok miatt is . -
waterman #96 nem is attól tartok hogy nem kikapcsolható, mert gondolom feltelepíted, aztán az efi konzolján beállítod hasonlóan mondjuk egy apache-hoz. de ha pl nem tök nyílt az az efi, akkor ki garantálja, hogy az os és a hardver közé nem pakolnak egy olyan progit, ami esetleg árulkodik rólam? -
turul16 #95 SCSI
A digrammod rosz. azok mega BYTE per sec ek.
Az USB meg Mega BIT.
Kb. 10 éves lehet a 160MB/sec -es.
"Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer."
Valószínüleg igazad van. -
waterman #94 usb - 480 megabit/sec = 60 megabyte/sec
a linkelt képen meg magebyte-ok vannak.
tehát a komolyabb scsi rendszereknek nem lenne elegendő az usb nyújtotta sávszél. -
#93
> szerintem ha kipakolják az os-ekből a mindenféle varázslást, hókuszpókuszt és kapnak egy letisztult csatlakozási felületet, akkor a virtualizáció lassító hatása már nem is lsz olyan félelmetes
Ez a vegso cel. Kilapatolni a ganyolast a kernelekbol es konnyen karbantarthato, egyszeru felepitesu kerneleket fejleszteni a komplexitasban elveszo, lassu monstrumok helyek.
> nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülről az adataimhoz férjenek.
Ezek mind kikapcsolhato funkciok lesznek. -
#92
> Lassú. Kapok egy felesleges memoria managert ami nem kell, kapok egy köztes réteget amin keresztül kell tolnom a legegyszereűbb műveleteket is, ami jó esélyél egy pár felesleges context switchet is jelent, ami sok pici egyszerű műveletnél, jelentős hatékonyságbeli veszteség.
A kernelspace/userspace mappelese is egy ilyen reteg...
Ugyanezekbol az okokbol a kernelek 60%-a is egy ilyen felesleges reteg.
> Rengeteg CPU -mat basztató kód, memória, cpu idő kikerül a látómezőmből. Hiba beazonositás szinte lehetetlen lesz.
Azert a multitaszkos kernelek alatt ezt eddig is megoldottuk valahogy...
-
waterman #91 szerintem ha kipakolják az os-ekből a mindenféle varázslást, hókuszpókuszt és kapnak egy letisztult csatlakozási felületet, akkor a virtualizáció lassító hatása már nem is lsz olyan félelmetes (pláne mire elterjed, addigra alap lesz a 4 magos proci).
plusz, lejjebb linkeltem az intel féle efi megoldás efi-tools honlapját. http, ftp szervereket lehet csinálni az efi-vel, ha tényleg virtualizál akkor az os-en kívül. ez ugye mondani sem kell biztos gyorsabb, mint egy os-en belüli valami, hiszen célspecifikus.
nekem egyetlen bajom van az egésszel, az pedig hogy nem kell oprendszer, hogy kívülről az adataimhoz férjenek. mondjuk ezt is át lehet hidalni az os által titkosított particiókkal, de azért remélem nem ilyen kuruzslással kell majd védeni az adatokat.. -
#90
> 480Mbit, egy modern SCSI csatoló ettől jovál többet tud.
Ja, meg se kozeliti.
> Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni
Amiert ugye nem a csatoloszabvany teheto felelosse hanem az erintett operacios rendszer. -
turul16 #89 Lassú. Kapok egy felesleges memoria managert ami nem kell, kapok egy köztes réteget amin keresztül kell tolnom a legegyszereűbb műveleteket is, ami jó esélyél egy pár felesleges context switchet is jelent, ami sok pici egyszerű műveletnél, jelentős hatékonyságbeli veszteség.
Rengeteg CPU -mat basztató kód, memória, cpu idő kikerül a látómezőmből. Hiba beazonositás szinte lehetetlen lesz.
Ezeket kódokat ugyan azok fogják írni akik a BIOS-okat vagy kékhalál drivereket.
Lehet, hogy lehetőségem sem lesz javítani a bugjaikat. Honan fogod tudni, hogy melyik rejtett folyamat eszi meg CPU -dat,memóriádat , mivel nem látod cpu idő monitoron, csak azt látod, hogy kurva lassú az égész szemetes ládád. -
turul16 #88 480Mbit, egy modern SCSI csatoló ettől jovál többet tud.
Sokak szerint nem megy ilyen jól sem a gyakorlatban, Latency-ket, meg CPU terheléseket szoktak emlegetni -
#87
> Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest?
Persze. Mi ezzel a baj? -
#86
> Az más kérdés, hogy SCSI sokak szerint nem elég egységes.
De nem igazán alternativa, mert sebbeségben nincs ott az USB.
480 Mb/s
-
turul16 #85 Nem tudom te hányszor kerülted meg bios-t, mert a te kódod jobb, gyorsabb, jobban illeszthető .. etc. Ez az EFI nekem kurvára réteg modellnek tűnik, amit nem kerülhetsz meg . Sőt, ha jól sejtem még, ha keresztül engedő üzemmodba is váltod a dolgot akkor abban sem lesz köszönet, olyanról még nem halottam, hogy virtualizáció gyorsított volna hardware elérésen.
SCSI specifikációt nem láttam, de nem fogadnék rá, hogy az USB specek egyszerűbbek (már csak topológiailag sem). Az más kérdés, hogy SCSI sokak szerint nem elég egységes.
De nem igazán alternativa, mert sebbeségben nincs ott az USB. Sőt sokan esküsznek rá, hogy pl. a FireWire is jobb, pl. kamerákhoz.
Ha nagyon akarod akkor az r=1 lusernek egyszerűbb dolga van vele.
Olyan rémhirek is keringenek, hogy te mint mezei programozó/gép vásárló nem leszel jogsult sáját kódodat bele passzintani. (Sealed storage)
Valami OEM-ek meg akkarják törni a Pokoli Operátor hatalmát :) -
turul16 #84 "A system and method is disclosed for protecting extensible firmware interface (EFI) runtime services utilizing virtualization technology. The runtime services used by an operating system (OS) are executed by a runtime services monitor (RSM) rather than the operating system itself. When the OS accesses a runtime service, the processor mode automatically switches context to the RSM, which then executes the runtime service and puts the results back in a shared memory location. Virtualization technology is used to effect the automatic context switching. Other embodiments as described and claimed above are disclosed."
src
Értsem úgy, hogy virtulizálva fut maga az OS is, mint EFI guest ?
!= jó. -
#83
> Mi az, hogy OS független driver?
Ekkora baromságot még az életemben nem hallottam.
Akkor eppen itt volt az ideje. Az OS fuggetlen driver azt jelenti, hogy az EFI-hez keszit drivert az adott hardverelem gyartoja, igy az OS felol elegendo csupan az EFI azon absztrakcios reteget kezelni ami az adott hardverelemhez biztosit kotest. Magyarul: van egy vodornyi, kulonbozo gyartotol szarmazo EFI tamogatott halozati kartyad, melyek hasznalatahoz nem kell vacakolnod driverekkel kulon minden OS-nel, hanem elegendo feltenned az adott kartyahoz tartozo EFI drivert. Onnettol kezdve barmilyen EFI tamogatott OS-t teszel fel, automatikusan latni fogja a kartyat. Ezt jelenti az OS fuggetlen driver. -
turul16 #82 Köszön mester, hogy hozzám szolottál.
Bizonyára csak nekem tűnt úgy, hogy bonyolultabb, mint egy RS-232 UART haverral, specifikáció is csak véltelenül van egy csaknem 10Mb .zip fileban (amit pár éve olvasgattam), biztos, mert a csatlakozók fényképeivel van tele. Linux kernel-ben is csak véletlenül van párszezezer sor ,csak usb host controller és core miatt.
És csak ezért, mert egy usb device controlert elég egyszerű bekötni, és libusb -vel userspace drivert csinálni, attól még nem lesz egyszerű a mögötte megbúvő több százezer félvezető elemből álló eszközök hada. De te biztosan naponta tudsz ilyet tervezni, csak lusta vagy rá. Ha még is időt szakítanál rá örömmel venném ,ha feltöltenéd a terveket. http://www.opencores.org -csak rád várt eddig. -
#81
Turul. Itt a technologia nem marol holnapra valo egyszerusiteserol van szo hanem egy hosszutavon megterulo fejlesztesrol. Ezt tessek megerteni. Nyilvan rovidtavon osszetettebbe valik egy rendszer tole, de hosszutavon eltavolithatok lesznek mas egysegek.
> Nem váltotta ki. Csak van ahol azt hiszik.
Egyszerűbb lett ? Nem. (See USB spec.)
Lenyegesen egyszerubb mint az SCSI, UW SCSI, stb. -
#80
> Nem lehet hibátlant gyártani? Hát, te sem láttál még Ferrarit.
Vezettem is. Ettol meg az osszehasonlitasi alap tovabbra is messze van a BIOS/EFI kerdestol.
> És azért van még pár dolog a világon, amelyből hibátlant gyártanak, a pulóvertől a repülőgépekig
1. Egy pulover az osszetettsegeben fenyevekre van egy gozgeptol is, nemhogy szamitogep alkatreszektol.
2. Repulogepek kozott sincsen hibatlan, ezert vannak a kulonbozo biztonsagi berendezesek is. Redundans hajtomuvek, robot pilotak, uzemanyagtartalyok, szivattyuk, stb. Ha valami leall, hasznaljak annak valamelyik redundans parjat. Ja, hogy ha van ilyen incidens nem basszak oda lepten-nyomon az utasok orra ele? Ettol meg a problema letezik. -
dez #79 
-
dez #78 Vakok közt a félszemű a király, mi? -
dez #77 Ha neked túl bonyolult az USB (akár OS, akár hw oldalról), inkább ne programozz... -
dez #76 Látom, te is magasra fejlesztetted a lényeg levételének képességét... -
dez #75 Ha esetleg gondolkodni is eszedbe jutott volna...
Mond az valamit, hogy standard (szoftver) interfészek...? (Ipari standard, nem egy cég belsős standardja.)
Ha az OS-ekben lennének ilyenek a főbb input/output csatornákra/eszközökre, ezekhez az interfészekhez illeszthetne az alaplapi driver, nem az adott OS sajátságaihoz (mint pl. DirectX, ami csak Windowson van).
Na, pislákol már valami? -
waterman #74 szerintem úgy értik az os-független drivert, hogy a microcode ugyanaz ami viszi a hardware-t különben rá se bagózna mit szövegel a szoftver. ergó ha szabványosítjuk a rendszer eléréséhez szükséges bios feletti rétegeket, akkor az os gyártók rá lennének kényszerülve egy szabványos interface használatára (az os rész alatt ugyanazt használnák). így aztán meg tök mindegy lenne, hogy egy linux egy solaris egy windóz vagy unix vagy freebsd vagy akármi nyúl a hardware-hez, mindegyik ugyanazt látná. de ez csak talán a távoli jövő. mindenesetre átjárhatóság és fejleszthetőség tekintetében egyszerűbb dolga lenne a programozóknak. a felhsználók meg azt vennék észre hogy minden működik minden os alatt. szvsz.
itt valaki lentebb írta, hogy minden os gyártó és programozó nekiáll "összetaknyolni" azt ami nincs meg, gyártsunk egy _sajátot_. na ez szűnne meg legalább driver téren. talán. -
turul16 #73 "Itt nem hiszem, hogy sokan ismerik a sed-et turul :D Ez nem az a hely."
Ideje kulturálódniuk :) -
whitehawk #72 Itt nem hiszem, hogy sokan ismerik a sed-et turul :D Ez nem az a hely.
Szerintem az USB azért bizonyos szempontokból mindenképpen egyszerűséget hozott. Ha nem is feltétlen programozói oldalról.