Da li slucajno znas kakva je konfiguracija tog kernela? Koliko znam kernel ima full tickless opciju tako da proces moze da se izvrsava ne nekom
core-u neometan od interapta no to je samo enablovano moras sam da podesis. Drugo tu je mozda stavljen MuQSS, koji od kernela 5.5 nije neophodan.
U svakom slucaju to zavisi kako ce biit i sta ce biti od distroa. Osim toga moze se i konfigurisati sta ima prioritet, koliko ce puta u sekundi da pali interapt
timer-a te da li ce kernel biti preemptive (low latency) ili voluntarilly preemptive. Nista ne znaci kada neki distro napise (real time kernel)

U nacelu real-time kerneli vise koriste procesor i imaju veci overhead. Sve dok imas neki headroom, radice bolje. Takodje, neki taskovi nisu dobri na takvom sistemu, drugi schedulers su bolji za procese koji obradjuju velike kolicine I/O-a, verovatno bi ti, na primer, bila sporija baza sa par stotina gigabajta podataka... takve stvari.

Kucanje i "4K" zvuk su ti kasnili na tom racunaru?

Kucanje teksta, da, i zvuk u okviru 4K video snimka, ne "4K zvuk".



Ko je radio sa Vega grafikama na Ryzen mobile čipovima i Linux-om zna vrlo dobro koliko loše funkcioniše hardverska akceleracija grafike. Zapravo, ne funkcioniše za video, uopšte.

Windows 10 ima druge probleme, zato ga izbegavam.

Vega 8/11 podrska za Linux je krsina teska... mislim da nema
distro-foruma na kom nisam pokrenuo temu oko iskustva sa tim
amd integrusama, i podaci su.. porazavajuci.

Imas neke kernele koje su kao bas optimizovali za amdgpu, pa probaj sa njima,
tu su kao neke stvari ispravljene...

Ja sam bas hteo da uzmem jednu masinu sa AMD Ryzen 5 3400g (ima Vega 11),
ali posle malo informisanja kako to radi na Linuxu... kanda ostajem na intelu i nvidiji.. jbg.

Cinjenica je da jednostavno sto se grafike na Linuxu tice, ne postoji nesto
sto je dostiglo kvalitet vlasnickih nvidia drivera.

https://aur.archlinux.org/packages/linux-amd-raven/

@Srđan Pavlović

Hvala na informacijama, upravo se pripremam da instaliram Arch i linux-amd-raven.

Nažalost, meni "jaka" grafika ne treba, bio bih potpuno zadovoljan Intel UHD grafikom, problem je što je Intel laptop jednakih performansi, u trenutku kupovine, bio 30% skuplji (~80 000 vs 60 000 din).

Nisam mogao da zamislim koji je pakao AMD Vega na Linux-u. Najgore je što nigde ne piše, proverio sam po forumima i reddit-u, nisam našao ni jedno upozorenje na stvarno stanje.

Hm, tebi nikako nista da radi kako treba :P

Kome radi Vega na Linux-u?

@Branimir, ma vidi bre malo forume svih distroa oko Vega amd integursa... bezi bre,
umalo se nisam zaebo pa to pazario... mislim, ne sumnjam da ce to vremeno da se pegla
al brate docekati da to bude stabilno...

/edit:
@Milan - ajde bas ako probas taj amd-raven kernel javi kako radi, on bi
trebalo da je pavovan i optimizovan za te amd integruse...

_{[Ovu poruku je menjao Srđan Pavlović dana 11.02.2020. u 15:54 GMT+1]}

Evo, procenite sami:

Mint:

https://forums.linuxmint.com/viewtopic.php?f=49&t=308958

MX-Linux:

https://forum.mxlinux.org/viewtopic.php?f=107&t=53413

Manjaro:

https://forum.manjaro.org/t/ma...g-vega-8-any-experience/110497

Po svemu sudeci bolja podrska za nove Navi cipove nego ove Raven Rigde il sta je vec Vega

Srdjane to radi, kad uzmes novu nvidiu mozes samo da gledas crn ekran jedno godinu dana...

Branimire, ja kukam za najobičnijim HW-accelerated video playback mogućnostima. Koje ima i Intel GMA, a o HD ili UHD grafikama da ne pričamo.

Mnogo sam se prevario sa ovim laptopom. Nikad više.

Pa vidim kako radi :D

Na koje tacno nove nvidija karte mislis? Sta tacno ne radi na njima i sa kojim drajverom i kernelom?

Recimo 2xxxx kad su izasle, trebalo je dosta vremena da budu podrzane na Linux-u. Tek od kernela 5.6 sad, a za nvidijin blob ne znam
tacno kada su podrzane...

A vidi, bleeding edge hardver na Linuxu... sto se toga tice uvek im "dajem"
dve do tri godine, posle toga vec ocekujem da radi kako treba... sad ne znam
tacno kada je recimo izasla nvidia 2080... plus me taj segment i ne zanima
preterano neam novaca za bleeding edge hardver, uglavnom sklopim desktop
masinu celu za par stotki eur.. :)

Nego sam se radovao sto su integruse AMD postale dovoljno jake za moj
ukus tako da mogu potpuno da izbacim dedicated kartu, ali jbg, podrska
za Vega 11 na Ryzen 5 3400g je recimo.. losa. Imam sad 16gb rama i to
u kombinaciji sa 2 SSD-a i tim rajzenom sa Vega 11 bi meni bilo vise nego
dovoljno.

Tako da cekam jos do leta sa apgrejdom treba izadju i novi AMD procesori
sa novim integursama koje ce da kidaju... u tom nekom jeftinijem segmentu,
dotle pratim kako se drajveri razvijaju, sta radi, sta ne...

Real-time kerneli moraju biti manje efikasni od "best effort" kernela zato sto real-time kernel mora da vodi dodatno "racunovodstvo" kako bi garantovao servis unutar definisanih kriterijuma.

Cela ta stvar kosta vise procesorskih instrukcija, interapta, context-switcheva i pravi gomilu viskova koji su apsolutno nepotrebni osim ako nemas aplikaciju koja MORA imati garantovan servis. Da li imas tako nesto? Osim ako nije nesto vrlo specificno tipa rad sa nekim specijalnim senzorima i sl. (u kom slucaju je verovatno bolje resenje neka embedded platforma).

Nista se nece lose desiti racunaru, pogotovu ne SSD-u (koji nema veze sa ovim) - jedino ce tvoji procesi imati manje vremena za izvrsavanje sopstvenog koda, zato sto ce niti provoditi vise vremena u kernel modu ili servisirajuci nepotrebne interapte.

Uzgred, real-time kernel moze da ti napravi cak i vecu stetu od dodatnih potrosenih ciklusa i interapta. Sa real-time kernelom je daleko lakse izazvati tzv. inverziju prioriteta u procesu sa vise niti ako autor nije obratio paznju na tu mogucnost. U tom slucaju ces imati vidljiv do drastican pad performansi u najboljem slucaju ili totalnu blokadu u najgorem.

Moj savet: osim ako nemas konkretnu potrebu za RT-om (u kom slucaju mislim da bi prvo trebao da se zapitas da li uopste trcis na pravoj platformi, posto ti real-time kernel nece pomoci ama bas nista ako je firmware vendor idiot i, recimo, u SMM modu ti sprzi gomilu procesorskih ciklusa emulirajuci nesto ili sl. glupost) batali to sto pre.

@Ivan Dimkovic

Jasno. Međutim, "best effort", tj. default kernel sa Ubuntu-specifičnim dodacima, ima problem da isprati kucanje tastature, pa se dešava da čekam 2 sekunde da "pohvata" sve što sam otkucao.

Caps Lock lag-uje, pa brzo prebacivanje npr. on/off/on/off[...] izaziva AAaaAAaaAAAaAAAaa umesto AaAaAaAaAaAaAaAaAaAa...

Zvuk kod reprodukcije videa kasni i nestaje.

Što se tiče SSD-a, konkretno nisam mislio na oštećenje hardvera, već eventualna korupcija podataka kod upisa.

Svejedno, opet sam na Win 10 jer nisam uspeo Arch da instaliram kako bih probao linux-amd-raven.

Hmm nisam siguran kakve veze ima kolicina pisanja na SSD sa scheduling parameterima Kernela?

Mislim, ista I/O operacija na istoj platformi i SSD-u ce upisati istu kolicinu podataka na SSD, bez obzira na to kako kernel radi scheduling thread-ova. Postoji memorijski kes za podatke (osim ako ga ne iskljucis) i sistem ce se potruditi da upis izvrsi na takav nacin da se upise maksimalna kolicina podataka unutar obecanja za RT performanse.

Blokovi na SSD-u su relativno male velicine, i verovatno se mogu savrseno upisati unutar vremena garantovanog kupcu za RT performanse.

Sto se tvog problema tice, mislim da svakako nema veze sa "best effort" kernela vec da ili imas ozbiljan konflikt periferija ili je neki genije lansirao ~1000 interapta u sekundi.

Pominjes audio probleme kad pustas 4K video - to mi daleko vise zvuci kao saturacija procesora i internih kola (hw. dekoder, kompozitor slojeva za UI) - najverovatnije losi drajveri koji mozda ne prate "best practice" dokumente.

Ne znam za Linux, ali na Windows-u od Vista-e postoji mogucnost da se audio nitima da specijalni prioritet (ili to mozes uraditi "rucno" u kodu) tako da ce audio rendering imati daleko veci prioritet od drugih komponenti u sistemu, sto bi trebalo da resi stvar.

Hvala na informacijama za SSD.

Što se tiče višeg prioriteta za audio dekoder, lepo je što može, ali ja to ne želim, jer smatram da video playback treba da radi na ovakvom procesoru jednako dobro kao i na jednojezgrenom ARM čipu na 1 GHz (npr. neki random BluRay plejer).

Probao sam Manjaro Linux, imao sam ovakve grafičke artefakte na stock kernelu, ažuriranom kernelu, linux-amd, linux-amd-raven, linux-amd-vega. Sve sam probao, potrošio ne znam koliko sati na kompajliranje, isto.

https://milankragujevic.com/uploads/IMG_20200213_010446.jpg
https://milankragujevic.com/uploads/IMG_20200213_010616.jpg
https://milankragujevic.com/uploads/IMG_20200213_011647.jpg
https://milankragujevic.com/uploads/IMG_20200213_011715.jpg
https://milankragujevic.com/uploads/IMG_20200213_023347.jpg

Trenutno sam na Mint 19.3 sa kernelom 5.6rc1, radi dobro za sada, probaću da ne menjam kernel na rc2, ili release.

Nije potrebno da audio dekoder radi na visem prioritetu, posto su obicno kompresovani audio frejmovi koje dekoder procesira reda velicine 20-30 milisekundi - ako aplikacija nije real-time (tipa VoIP) obicno ce imati neki bafer od bar nekoliko desetina milisekundi - cesto i stotinjak, tako da cak i ako dekoder nit malo zakasni, najgore sto moze da se desi je da nivo punjenja bafera opadne za 20-30 milisekundi, ali i dalje u mogucnosti da dostavlja podatke posto ima jos rezerve.

Ono sto je nekad potrebno je da audio rendering radi na visem prioritetu (sistemski mikser -> audio drajver) - ako ima dovoljno ciklusa za sve, onda nema potrebe. Ali u slucaju da dodje do 100% opteerecenja procesora, nije lose da audio rendering ima visok prioritet posto je audio hardver najvise osetljiv na kasnjenje zato sto obicno koriste vrlo male bafere (kako bi omogucili nisku latenciju zbog telekomunikacija itd.)

Ne znam za Linux, ali svaki noviji Windows-i komotno mogu da rade sa 2ms baferima osim ako na sistemu nema nekog lose projektovanog hardvera ili drajvera pa OS dosta vremena provodi u servisiranju interapta i ponekad izazove underrun bafera koji audio drajver koristi za dostavljanje semplova audio hardveru. Ako to nije slucaj, default podesavanja OS-a su sasvim OK.

Ako imas problema te prirode, najbolje je prvo da proveris da nemas neki hw/drajvere koji previse opterecuju sistem interaptima. Nisam Linux ekspert, tako da cu odgovor na to ostaviti drugima, na Windows-u ima alata koji prikazuju kolicinu interapta u sekundi kao i DPC latenciju - ako su u pitanju abnormalno velike cifre, to je razlog problema.

Real-time kernel scheduling tu nece pomoci, vec samo moze da odmogne jos vise zbog razloga koje sam naveo.

Sto se tice Linux-a, ovde ima informacija o tome:
https://jeremyeder.com/2013/11/15/nohz_fullgodmode/
Znaci mogucnost da se dizejbluju interapti po jezgru, tj da se jedno jezgro
posveti obradi interapta a ostali da se ne prekidaju.
Ne mogu da nadjem, ali kao da sam pisao o ovome ranije ;)

cat /proc/interrupts

Stavi ovo svake sekunde u nekoj skripti, grepuj deo koji ti treba i onda sracunaj average za neko vreme :)

configure IRQ afinity: https://www.mjmwired.net/kernel/Documentation/IRQ-affinity.txt

https://www.reddit.com/r/Amd/c..._for_ryzen_mobile_is_terrible/

Evo ljudi imaju iste probleme kao ja, koji eto još uvek nisu rešeni.

Ovaj Raven Ridge HP laptop je bukvalno najgori proizvod koji sam koristio.

Poslaću ga na servis, ako utvrde da je sve OK, prodaću ga i uzeću Intel. Ovo više nije smešno.

Koliko vidim problem je u drajverima ovde, prodaj bre kad te nervira ;)

Znam da je u drajverima, ali ide u servis, da ne bude da je neispravan i da sam ga takvog prodao.

Agoniji, inače, nikad neće doći kraj. Uzmem lepo Šintel sa integrušom UHD i sve radi kako treba, a meni novčanik duplo prazniji.

"Uzmem lepo Šintel sa integrušom UHD i sve radi kako treba"

Windows 10?

Sve.

Od kako sam prešao na Intel UHD integruše, nemam problema, možda je to razlog što imam sreće sa OS. ;) Ne znam da li sam gora iskustva imao sa amd ili nvidia grafikama. Srećom, nemam potrebe za ekstra grafikama jer sam prerastao igrice. ;)

calexx:"Ne znam da li sam gora iskustva imao sa amd ili nvidia grafikama."

Meni dobra iskustva i sa AMD i sa Nvidia grafom. Jedino sto ne mogu da
se igram pod Wayland-om sa Nvidiom posto ne podrzava XWayland, pa
sam presao na AMD.

Loše iskustvo sa nvidia grafikom sam imao pre neku godinu, kartica je bila malo starija i u krš kompu, kubuntu ~10 je lepo radio, 12 je brljao i ni apgrejd nije pomagao. Napuštena podrška. Problam sa Ati sam imao sa karticom koju mi je poslao drugar, relativno nova i Windows radi bez problema ali mislim da nijedan linux nisam mogao da instaliram, već u startu u terminalu totalno zabrlja sa bojama i pidžama efektom, totalno do nerazumljivosi onoga na ekranu. Onda sam u jednoj radnji probao linuxe sa fleške na kompu u kome je bila ploča koju sam planirao da kupim i intelova integruša je radila bez greška. Tako je i sada, još nisam menjao komp.

Ma ja grafu kupim generaciju iza uvek ;)
100% ima podrsku na Linux-u ;)

Mislim da problem sa performansama nema veze sa izborom GPU-a (eGPU / dGPU), vec je verovatno laptop vendor strpao bog-te-pita-sta u SMM rutine.

U principu, SMM mod preuzima potpunu kontrolu nad izvrsavanjem na procesoru i OS tu ne moze nista da uradi (SMM mod je vise privilegovan od ring 0 i bilo sta sto trci u ringu 0 ili visim ne moze da prekine SMM rutinu).

Jedini "trag" koji SMM ostavlja je protraceno vreme i povecan broj izvrsenih instrukcija. Ni ring0 kernel ili hipervizor nemaju pojma sta se desavalo za vreme SMM rutine.

Jedan od problema sa laptopovima je sto proizvodjaci koriste SMM za kojesta i, ako nisu pazljivi, dugacak boravak u SMM modu moze ozbiljno da poremeti scheduling algoritam kernela.

Da ne pricamo o tome da su SMM rutine potpuno slobodne da rade sta hoce i da se izvrsavaju koliko im treba da zavrsava posao.

Ukombinuj to sa firmware-om pisanim od strane upitno kompetentnih ljudi i genijima kojima je palo na pamet da sa SMM rutinama peglaju ko zna sta oko njihovog hardvera. Rezultat je predvidljiv.

Ima tu i kljakavih drajvera za GPU. Evo postao sam clanak upravo o tome na hardware/grafe podforum. Drajveri za nove AMD grafe ne valjaju.

OK, svaki drajver moze da za*ere sistem zato sto drajveri obicno servisiraju interapte, rade DMA transfere i sl.

Ne znam za AMD drajvere, ali znam da mogu dovesti NVIDIA drajver do toga da bukvalno zaglavi ceo ostatak OS-a dok prenosi gigabajte geometrije na GPU. To nije nenormalno ponasanje, posto je ceo use-case takav da prakticno nema nekog boljeg resenja. Trazio si od drajvera da sibne neku kompresovanu geometriju velicine 16 GB i da onda izvrsi neku nenormalno dugu operaciju nad tom geometrijom koja graficku karticu blokira za sve drugo (graficke kartice za sada nemaju OS sa schedulerom koji prekida niti), drajver jednostavno radi ono sto si trazio od njega, GUI be damned.

Windows Server ima neki timeout posle koga ubije GPU drajver, zbog cega prvo moras to da ugasis ako planiras operacije koje ce blokirati ostatak OS-a na vise od nekoliko sekundi.

Ako se sistem ponasa nenormalno u rezimu gde ne bi trebalo da bude problema, uvek bih prvo proverio:

1. Procese, ukljucujuci i kernel mode zauzece procesora
2. Interapte (kolicinu, kao i latenciju odlozenih procedura)
3. Kolicinu context switch-eva
4. CPU C i T stanja, da slucajno power management ne baca CPU u LFM mod ili zbog nekog razloga se aktivira throttling (u kom slucaju treba pogledati temperaturu, itd.)

Obicno nesto od ova 4 ne valja i ukazuje ili na hardverski problem (smaknut hladnjak), bagoviti drajver ili na los sistem (laptopovi su obicno krivci) gde je OEM raspisao neki sampionski SMM kod (mislim da je ovo danas sve redja i redja pojava kako je UEFI standardizovao gomilu stvari koje su nekada resavane proprietary kodom).

Mislim da se vecina problema nalazi u ovih 4 stavki.

Kad smo kod RTOS-eva, secam se vrlo komicne situacije gde su performanse softvera na jednom od poznatijih RTOS-eva bile katastrofalno lose (isti CPU, ali razlika izmedju Linuxa i RTOS-a k'o nebo i zemlja) - analiza problema je ukazala na inverziju prioriteta niti. Ko god da je pisao kod i nitima dodelio neke prioritete je stvar testirao na Linuxu i Windows-u gde je sve bilo OK (tj. "OK" pukom srecom), ali na konkretnom RTOS-u je scheduler vrlo bukvalno shvatao to sto se trazi od njega i dosledno blokirao nit koja proizvodi podatke dok se druga nit koja ceka na iste podatke vrtela za dzabe dok joj ne istekne alocirano vreme i RTOS pusti nesrecnog producer-a da nesto stvori.

Zakljucak iz te price je bio da se ne za*bavas sa proizvoljnim setovanjem prioriteta nitima osim ako zaista ne znas tacno sta ce da se desi u svim rezimima rada, sto vrlo verovatno nije bio slucaj, nego je neko primenio cargo-cult programiranje i nasetovao nekakve prioritete nitima iz nekog samo njemu objasnjivog razloga.

Drugi zakljucak je bio da RTOS-evi vrlo dosledno izvrsavaju ono sto se trazi od njih, cak i kada je to katastrofalna greska, RTOS ne diskriminise, ako si trazio da ti urnise proces, to ce uraditi bez problema.

Razlog sto se problem nije vidjao na Linuxu ili Windowsu je ideja "fer" schedulinga ugradjena u standardne Windows i Linux scheduler-e (i nit niskog prioriteta ce dobiti duzi slajs ponekad zbog "fer" raspodele) - iliti, kernel dev-ovi znaju da je vecina userland koda sampionska i da moraju ponekad da ispeglaju tudje gluposti, cak i ako to nije posao OS schedulera.

U stvari tek tad vidis genijalnost ljudi koji su razvijali popularne scheduler-e u Linuxu/Windows-u/Mac OS-u - njihov problem nije bio razviti scheduling algoritam koji nitima alocira neki % procesorskog vremena po nekoj formuli, vec peglanje beskonacne kolicine idiotizama u userland kodu koji korisnici ocekuju da ce da radi bez problema, iako programeri bukvalno traze od procesa da se samoubije sto se performansi tice.