Příspěvky

1171

Server / Re:Domácí virtuální server postavený na Proxmoxu

« kdy: 30. 12. 2020, 16:12:11 »

24 linek je rozdeleno jako 16 PEG (pcie graphic) (16/8+8/8+4+4) a 4+4 GPP (general purpose), tyto jsou typicky x4 pro chipset a x4 pro NVMe (M.2), aby to nemuselo chodit skrz chipset a zabirat pasmo/piny/tdp.

Lebo ak Ryzen 5 3600 ma pozitelnych 20 lanes tak:
8+8 pouziju 2 GPU
4 pouzije chipset
4 M.2
a skoncil som lebo neni co pouzit na PCIe kam by isla sietova resp SATA karta

Mam z toho hlavu ako tekvica a zacinam uz pomaly chapat preco je serverovy hardware lepsi na taketo veci.

Probuh, nekomplikuj to. Chipset ma typicky dalsich 12 az 24 PCIe linek, ktere vedou na ruzne dalsi x1/x2/x4 porty (druha sitovka, wifi, usb3.x radice, firewire, a samozrejme PCIe sloty - typicky tam byva jeden v X4 rezimu a pak jeden nebo vice v x1 rezimu). Pokud se nekde pise "pouzitelnych 20", to znamena ze uz 4 odecetli kvuli chipsetu.

Vzdy se divej na blokovy diagram konkretni desky - co kam vede. Pokud to vyrobce neukazuje, vem jineho vyrobce - zde opravdu neni rozdil, zda budes mit Gigabyte nebo ASUS.

Ohledne rozdilu tabulky vlevo/vpravo, toto ode me jsi prehlednul:
Ad porovnani desek: ta vlevo je "jednoslotova" (vsechno PEG na 1 slot), a ta v pravo "dvojslotova" (s muxem).

Pokud na obou doskach je dalsi slot, oznacen napr. PCIEX4 - tak ten vede nejcasteji skrze chipset. Jako neni to uplne idealni, sdilet pasmo skrze chipset, takze AMD odstehovalo alespon jedno x4 NVMe na CPU o par let driv, nez to udelal intel v poslednich/pristich modelech.

Osobne bych sel do vetsi desky, ktera ma ten mux - je to pak univerzalnejsi, kdybys to rozsiroval a nemusis to pak prodavat pod cenu.

Napr. ja mam ASUS P10S-M (kvuli ECC) - https://www.asus.com/Commercial-Servers-Workstations/P10S-M/ - a ta podporuje vsechny kombinace 16/0/0, 8/8/0, 8/4/4 a plus ctvrtej slot je x4 pres chipset. Karty tam jsou osazeny takto: x8:sas-raid/hba, x8:40ge, x0:sas-expander, x4:10ge (je to spis jako NAS, s par VM)

1172

Server / Re:Domácí virtuální server postavený na Proxmoxu

« kdy: 30. 12. 2020, 13:27:53 »

Kdysi jsem si dělal testy s Nvidií řady 900 zda dochází k propadu výkonu u GPU, která pracuje v řežimu x8 vs. x16. Výkon u x8 byl stejný jako u x16, ale když jsem mrkl na světhardware, tak to vypadá, že s posledními Nvidiemi řady 3000 už je ten propad výkonu (u hry Civilization VI) v módu x8 znatelný.

Tak u AMD CPU + NV3000 je sance to rozjet v Gen4, takze kazda karta ma pasmo jako Gen3x16 - coz je rozhodne lepsi nez Intel (vcetne entry level 2011/2066 s 28 pcie, snad az drazsi 40 linkove kousky jsou k tomuto obstojnym ekvivalentem, pak muze mit deska dva plne x16 sloty).

Nevim ale zda to Gen4 budou umoznovat ty muxovane sloty - zda to pak neskonci na tom, ze primo pripojena bude Gen4 (prvni grafika a NVMe) a ta sekundarni jen Gen3, kvuli muxum... stejne jak to bylo v dobe prechodu Gen2/Gen3, kdy se pak vyrobci chlubili i osazenim schopnejsich prepinacu

1173

Server / Re:Domácí virtuální server postavený na Proxmoxu

« kdy: 30. 12. 2020, 11:19:18 »

Este som sa chel opytat ze ak Ryzen 5 3600 podporuje 24 pcie lanes z toho je pouzitelnych 20 lebo 4 su komunikacia s chipsetom a jedna GPU zozerie 16 lanes druha GPU zozerie tiez 16 to je ked spravne ratam 32. Nieje to trosku problem? Niekde som cital ze vraj karty mozu chodit aj v rezime 8x len neviem ci to treba nastavovat v BIOSe alebo sa to prepne samo? Ak to pojde 2x8 znamena to ze este mi ostane dalsich 8?

ale posledne si napisal ze by to malo ist ako 16x + 8x co celkom dava zmysel lebo neviem naco mat dosku so Zen2 compatible ktora ma 2xPCIe16x - to mi dajak nevychadza

a zaroven to znamena ze tam uz nic ine nepripojim?
resp obe karty su PCI Express 3.0 x16 doska je pcie 4.0 tak neviem ci aj toto ma na to vplyv

24 linek je rozdeleno jako 16 PEG (pcie graphic) (16/8+8/8+4+4) a 4+4 GPP (general purpose), tyto jsou typicky x4 pro chipset a x4 pro NVMe (M.2), aby to nemuselo chodit skrz chipset a zabirat pasmo/piny/tdp.

PCIe se ti automaticky "prizpusobi" - tj. kdyz jedna strana umi jen 3.0, tak to pojede nanejvys v te rychlosti. A sirkou to bude taky automagicke - kdyz obe karty osadis, kazde deska posle pulku (8+8) linek. Ta "dvojslotova" deska totiz umi jen rezimy 16+0 a 8+8, mezi kteryma prepina podle existence karty ve slotu oznacenem PCIEX8.

Ad porovnani desek: ta vlevo je "jednoslotova" (vsechno PEG na 1 slot), a ta v pravo "dvojslotova" (s muxem).

1174

Server / Re:Domácí virtuální server postavený na Proxmoxu

« kdy: 30. 12. 2020, 11:13:51 »

Nasiel som napr toto https://forum.level1techs.com/t/gigabyte-x570-aorus-elite-iommu-groups/144937/37 ale neviem ci spravne chapem tomu co sa tam pise, chlapik proste skusal niekolko biosov az nasiel f10a a snim IOMMU vyzera takto:

Toto je porovnanie dosiek GIGABYTE X570 AORUS ELITE vs  GIGABYTE X570 AORUS PRO podla oficialnej stranky:
https://pasteboard.co/JHerTVJ.png

GIGABYTE X570 AORUS PRO by vraj mala vediet GPU passtrought dvoch GPU do dvoch VM. Je tam vidiet to co som spominal a teda ze ELITE verzia ma 1xPCIe pripojenu priamo ku CPU a PRO verzia ma 2xPCIe pripojenu priamo ku CPU. Ja si myslim ze pre moj use case kde chem 1 GPU chcem ponechat hypervisory a druhu GPU spravit passtrought to problem nieje alebo sa mylim?

Jen v rychlosti jsem na to nahlídnul. Takže když jsou tam 2 GPU, tak to funguje:
- u Ryzenu 3rd generace v konfiguraci x16-x8
- u Ryzenu 2rd generace v konfiguraci x8-x8
Je to tak?
Pokud ano, tak ani u té 3rd gen nejde takto odhadnout zda budou 2 GPU ve dvou různých IOMMU skupinách. Chtělo by to vygooglit více info.

NENI. Primo tam pisou, ze kdyz pouzijes PCIEX8 slot, tak ten, co je oznacen jako PCIEX16 bezi v x8, plati to pro 2nd i 3rd gen Ryzen. (a v pripade APU s grafikou tam je jenom 8 linek takze pojede jenom jeden z tech slotu - PCIEX16, v x8 modu).

Toto je zcela normalni reseni, ktere uz existuje snad deset let, ze ma cpu 16 PEG linek, ktere lze rozdelit na 8+8, a deska tu pulku jenom pasivnim prepinacem (muxem) predratuje do druheho slotu (tomu nekdo rika "sdileni linek mezi sloty"). Pozdejsi cpu meli jeste moznost 8+4+4, pro trislotove workstation desky (tedy slotu tam bylo vice, pac neco jede z chipsetu, typicky treti/ctvrte x4)

1175

Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API

« kdy: 30. 12. 2020, 00:21:24 »

Mam jeste dotaz, o wsl se uz tady zminovalo, ale uplne jste neodpovedel - proc vlastne nemuzete tyhle utilitky na widlich spoustet pres wsl? Pripadne pres docker (for windows/desktop) ?

imho to je problem verzovani napr. GLIBC, kdy prislusne exporty tam bud jeste nejsou, nebo uz nejsou. Stejny problem potkavam pri spousteni binarek skrze ruzne linuxy.. pritom to je nekdy fakt takova prkotina, kdyz se podivate, ze v cem se lisi 2.25 a 2.32 :-)

1176

Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API

« kdy: 29. 12. 2020, 18:07:12 »

Nebylo by snazsi zkompilovat qemu-user pro win, a pak tomu predhazovat tvoje linux binarky?

1177

Windows a jiné systémy / Re:Vynucení 16:9 při připojení bezdrátového displeje. (příliš širokoúhlý displej)

« kdy: 29. 12. 2020, 14:12:07 »

prikazem wm size SIRKAxVYSKA, ze pujde zmenit pomer stran negarantuji

1178

Server / Re:Domácí virtuální server postavený na Proxmoxu

« kdy: 29. 12. 2020, 00:34:40 »

PS: nejedu proxmox, ale obycejne qemu/kvm, a do VM koukam skrze RDP, pripadne spicy klienta - kdyz vm nebootuje dobre. FS/raid/lvm resim uz v hypervisoru.

SPICY umoznuje remote management este pred startom VM (teda vidim tam post, grub atd) a teda je to riesene nejak tak ze ani nepotrebujem mat vo VM nejaku dedikovanu aplikaciu? Je to nejako vyrazne pomalsie napr oproti sominanemu RDP?

Tak ono to funguje podobne jako hw IP KVM (napr. ASPEED BMC) reseni - mas pristup k UI od VM (klavesnice/video), takze se to hodi napr. na instalaci OS. Mozna nekdy i pro pouzivani, ale k tomu me prijde uz lepsi to RDP (jedu tam stary office napr.). Mozna to ale souvisi s tim, ze VM mi bezi na jinem zeleze (serveru), nez moje uzivatelske rozhrani odkud to spravuji, takze to SPICY me prislo jako nejsnazsi cesta, jak to ovladat se vsim vsudy. Vetsinou tim resim ruzne - proc to nebootuje - stavy a pak kdyz uz je VM up, tak skrze ssh to neni problem ovladat, ze jo.

Ohledne ECC a server hw - myslim ze pocituji za ta leta znatelnou vyssi stabilitu u serveroveho zeleza, a vlastne samovolne restarty se tam nekonaji, na rozdil od desktopovych/consumer reseni. Kdyz mas jedno PC, a takovy incident se stane jednou za rok, tak to ignorujes, ale pokud jedes rekneme 12 systemu a restart se pak kona s cetnosti jednou za mesic.. te to zacne samozrejme stvat. Nemam jasny dukaz ze za to muze ECC nebo Xeon - je to porad jenom subjektivni pocit.

Osobne jsem na ECC systemy presel postupne.. stejne tak jak se zelezo zmigrovalo do 19" rack systemu, casem poresila UPS, PDU, backup, VLANy a jine "vyssi divci". Postune k tomu mozna dospejes, nebo budes mit stesti ze te nestesti nepotka.

1179

Odkladiště / Re:Reklamace chybné transakce v PayPal

« kdy: 28. 12. 2020, 21:13:08 »

Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.

To není bug, ale feature. Pokud byste pracoval na stejném účtu ve dvou oknech paralelně, tak budete klikat do stavu, který už není platný a to může způsobit různé podivuhodné věci (které třeba nechcete). A co se týče peněz, tak "better safe than sorry".

Ale on tam zadny evidentni stav neni - typicky use case je, ze chcete zopakovat X transakci (treba platby odvodu, najem, vyplaty), tak se doklikam v historii to obdobi ktere opakuji, ale nesmim otevrit v novych tabech "opakovat transakci" u vsech naraz - musim to delat po jednom - opakovat+k podepsani, opakovat+k podepsani... holt to UX pak trpi, radeji bych si pripravil do tabu co chci opakovat a pak je po jednom upravoval/odesilal a zaviral, nez mit vedle papirek a skrtat co jsem udelal nebo neudelal a musel stridat typ ukolu, protoze to maj napsany blbe.

Nepredpokladam ze to udelali takto umyslne (aka featura), spis to nemaj vychytany nebo je to technologicke omezeni frameworku (a s tim jako integratori nic nenadelaj).

1180

Odkladiště / Re:Reklamace chybné transakce v PayPal

« kdy: 28. 12. 2020, 14:59:56 »

Podobny problem melo FORPSI, kdyz vam expiruje >1 domena a vy si v nekolika tabech otevrete prodlouzeni a platbu - nejak tam maj bordel v cookies a vlatne provedete platbu na 1 domenu, vicekrat :-)

Samozrejme to je koncepcni chyba, protoze nejake frameworky jsou napytel, kdyz si stav vedou v cookies, a nemaji ho v URL.

Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.

Tohle nevyreklamujes - zadny moloch neprizna vadu, nebo zamestnava indy, kteri nejsou ochotni pripustit novou vadu - znaj jen sve existujici problemy.

1181

Server / Re:Domaci virtualny server postaveny na Proxmoxe

« kdy: 28. 12. 2020, 03:14:25 »

Pokud tam mas jen iGPU tak to bude hodne drbani se s GPU passthrough, protoze musis hypervisor bootovat jako headless, takze se to bude blbe ladit, pokud nejsi kamarad se seriakem. Ma-li ho tva deska ovsem.

U ostatnich veci - samozrejme taky muzes udelat 1:1 virtualni disk k nativnimu, ale moc jako passthrough to nepocitam - to by bylo az bys mel nejaky extra sata radic (jinej nez na hypervisor) ktery muzes predat do VM jiz jako PCIe device.

Osobne me to prijde ponekud overengineered (ale chapu ze si lidi potrebuji hrat a ucit se necemu novemu), a tlak na vykon je na spatnem miste - napr. NAS node bude stejne mit jen GbE konektivitu (doufam ze nejedes wifi only) a tech 1GbE ti saturuje i raid nad hodne vrstvama virtualizace - jediny problem bude ve spotrebe, a ze namisto 10% cpu bude zatez 60% (ilustrativne!).

Holt to zacni zkouset nejak poskladat - nemyslim si ze tohle (kvuli rozsahu/pozadavkum) jde udelat na prvni dobrou a bude to na nekolik predelavani.. pokud si dokazes udelat nejake metriky a replikovat mereni (treba prenos dat vs. utilizace resp. spotreba), tak se muzes dooptimalizovat casem k dobremu reseni.

Co me tam chybi jeste je pak ondemand rizeni nejakych priorit - napr. "game mode" da vsechny VM krome te s grafikou do "nice" priority, ze dostanou pridel az kdyby nebylo co delat.

PS: nejedu proxmox, ale obycejne qemu/kvm, a do VM koukam skrze RDP, pripadne spicy klienta - kdyz vm nebootuje dobre. FS/raid/lvm resim uz v hypervisoru.

1182

Hardware / Re:Nabíječka do mobilu nedá nad 5V při použití USB-C na obou stranách s redukcí

« kdy: 28. 12. 2020, 00:21:49 »

Ja ani nevim co cekas. Mas cinskej telefon, cinskou nabijecku, cinskej kabel. Poptej se tedy na ambasade, aby ti to vysvetlili, jak je mozny ze to spolu nechodi. Ale u nich evidentne nechodi ani lidske standardy, ne to jeste dodrzovat neco technickeho.

Kdybych to vzal dle pravidel nejvetsiho spolecneho jmenovatele, tak C-A redukce je USB 2.0, a usb 2.0 znamena 480mbit a 5V/100mA, s konfiguraci pak 500mA a nazdar.

Ze to leze proudem nad tohle - je bud z duvodu neexistence ochran na strane nabijecky (ty jsou typicky na 2A a domlouvani se je jaksi netrapi), nebo to muze znacit to, ze se to domluvilo na nejakem rozsirenem charging rezimu kde ten proud ma telefon od  nabijecky domluven nad ty 500mA.

Osobne bych nechtel, aby cokoliv do klasickeho USB (ne type C) poustelo napeti vyssi nez 5V. Kdo chce vic, at pouziva C+C a nevymysli pitome kombinace.

1183

Software / Re:Linux SW falešný RAID 0 (zrcadlení)

« kdy: 27. 12. 2020, 13:10:55 »

Prehistorická možnost je použít md raid a ve chvíli, kdy je vše synchronizované, pomocí mdadm odebrat disk. Při záloze ho zase přidat. Mělo by to být bezpečné, ale jen teoreticky. MD na to není určený - ten je určený k tomu, že oba disky jsou rovnocenné. Stačí selhání ve vyhodnocení toho, který z disků má starší, a který mladší data, a máte na světě synchronizaci opačným směrem, než chcete. Riziko není velké, ale existuje. MD bych se vyhnul.

A jak toto muze nastat, kdyz vyhodnoceni je otazkou porovnani "Events counter" (mimo uuid identifikaci pole, ktere zabranuje vlozeni disku z jineho pole)?

Mimo jine to, ktery disk se pridava je ten, na ktery se bude synchronizovat - nelze do aktivniho degradovaneho mirroru pridat disk za chodu, aby se prepsal bezici. Tak blbej ten raid fakt neni.

Pokud stroj vypnete, pridate disk, zapnete, tak se bud pole neslozi vubec, slozi jako readonly z disku s vetsimi events, nebo zacne synchronizovat (je to o nastaveni mdraid-u, ktere zabezpeci to, aby slo nastartovat stroj bez zasahu uzivatele, s rootfs na degradovanem poli).

Osobně bych použil obyčejné zálohování. Mám rád borg backup - rychle zálohuje, rychle obnovuje. Při havárii nainstalujete jen základní systém a borg a za chvíli natáhnete data ze zálohy. Výhodou bude vyšší rychlost, než u image a taky získáte deduplikovaný a komprimovaný archiv záloh v čase. Do stejného prostoru dostanete násobně víc záloh, než do obyčejného image.

Pokud se nevyzaduje inkrementalni zaloha a vicero kopii - tak lze cas obnovy lze redukovat temer na 0 (tedy na nutne minimum k prohozeni disku / prenastaveni boot from), kdyz udrzujete cilovej disk v bootovatelnem stavu (aktualizujete mu /boot, a zabranite prepisu rootfs identifikace u grub.conf a /etc/fstab, pripadne mate gentoo se svym initrd, ktery pri nenalezeni root= jako disku se zepta kde tedy je.. takze staci jedno obligatne /dev/sdxy enter a jede se ze zalohy).

1184

Software / Re:Linux SW falešný RAID 0 (zrcadlení)

« kdy: 27. 12. 2020, 02:45:50 »

Nez delat takove veci jak zamyslite, tak zde mate tri lepsi moznosti:

1) RSYNC (sice nebudete mit kompresi, ale na souborove urovni to bude konzistentni)

2) MDRAID a skutecny R1, v cronu pak nejake to sachovani s --fail --remove a --re-add, a spolehnuti na to, ze v bitmape nebude moc bloku, aby se nesyncoval pokazde celej rozsah disku

3) A mozna nejidealnejsi v pripade velkeho rozdilu kapacit vasich disku: BTRFS / ZFS a nastaveni raid urovne pro dulezita data, ktera budou v kopii, a nejaky docasny bordel nebude v raidu (napr. torrenty)

1185

Vývoj / Re:C++ ako naformátovať std::chrono::system_clock::time_point?

« kdy: 26. 12. 2020, 11:50:10 »

Samozrejme muze to mit sve vyjimecne vyuziti interne v nakem vlastnim kodu, ktery navenek vystavuje tridy uz jako final, takze se dedit nedaji. Ale stejne, kdyz se ten kod rozroste, tak stejne je potreba si v nem udrzovat trochu poradek a tohle k tomu neprispeje.

Vidis, tohle me privadi na myslenku - lze menit viditelnost memberu v hierarchii dedeni, ze to co bylo protected, uz bude od urcite urovne private? (marne si vzpominam, ze v necem byl konstrukt kde viditelnost byla jen pro urcitou skupinu trid..)