Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - RDa

Stran: 1 ... 10 11 [12] 13 14 ... 153
166
Software / Re:Škálování výkonu v dual-socket systému
« kdy: 04. 05. 2023, 12:59:32 »
Myslím, že kompilaci kernelu nelze ideálně (lineárně) škálovat.
Jsou tam závislosti, na které se čeká, některé operace se neškálují, atd...
Podle mých zkušeností naopak build jádra škáluje při běžném počtu CPU (nižší desítky) velmi dobře, pokud (1) je konfigurace dostatečně bohatá (třeba allmodconfig nebo distribuční jádra), (2) je dost paměti a (3) úzkým hrdlem je opravdu CPU, ne třeba disk (tj. překlad např. na tmpfs). Je potřeba si uvědomit, že většinu času se překládají jednotlivé soubory, které na sobě nezávisejí; v podstatě jediná část, která škáluje opravdu špatně, je linker (a i to se snad v dohledné době změní).

Presne tak. Ta konfigurace sice neni allconfig, ale mam zapnuto hodne modulu pro pripad co by kdyby jedou bylo treba a je to cca 2x delsi kompilace nez kdybych udelal jadro na miru konfigurace jednoho stroje.

Temer cela kompilace je vicevlaknova, jsou tam nizsi jednotky vterin nez se rozhodne o kompilacnim poradi na pocatku, a pak vyssi jednotky vterin se stravi jednovlaknove na linkeru a kompresi vysledneho jadra. Cele to bezi vzdy z cerstve rozbalene testovaci sady do /dev/shm.

Extremni vysledky z me testovaci sady stroju jsou 1m14s (Epyc Rome 7702P 64C/128T) vs 1h:57m09s (Celeron N3050 2C/2T). Pod 5 minut to da moderni highend, pod 10 minut to da bezna desktop sestava. Cokoliv nad 15-30min je z dnesniho pohledu spis pomalej komp.

Samozrjeme absolutni cas nebylo to co me zajimalo, ale efektivita - takze mam i data o idle/load spotrebe a nektere stare systemy celkem prekvapily - pokud se to ma vzit nejakym TCO vzorcem, tak porad existuji optimalni reseni (pro ruzne potreby to vychazi ruzne). Plus je zajimave videt, ze kdyz se operacni bod posune mimo boost/turbo, tak o kolik lepsi je dane reseni.

167
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 04. 05. 2023, 10:59:40 »
Tak jsem zjistil, že bez najetého OPNsense, které mi startuje automaticky, je spotřeba o 10W nižší (už se dostanu pod 40W). Když se OPNsense spustí, tak se spotřeba o 10W zvedne, i když v něm samotném ukazuje CPU usage 0%.
Myslel jsem si, že by to mohlo být integrovanou LAN kartou, což už tady bylo zmíněno od @bmansvk, ale když jsem integrovanou LAN kartu v BIOSu vypnul a WAN port přehodil na jeden port ze 4x LAN, tak se to chová stejně, přitom už jsou všechny porty ze 4x LAN nahozené v Proxmoxu a do OPNsense je předávám jako virtualizované, takže mi to vychází jen na spotřebu toho OPNsense. Zkusím kolem toho něco zjistit.

Tech 10W je s nejakym trafficem, nebo jen link up, nebo link down a jen sw je bezici?

168
Vývoj / Re:Pískání penalt pomocí neuronové sítě
« kdy: 04. 05. 2023, 10:58:30 »
Predstavoval bych si to tak, ze by se natrenovala sit na vzorku videi, s labelem, zda je spravne nebo spatne odpiskana penalta. Je neco takoveho proveditelne?

On ale ten vysledek nebude lepsi nez kdyz to bude posuzovat clovek (trenovaci vzorek), takze proc to delat?

169
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 01. 05. 2023, 21:25:57 »
Taky si myslim, ze problem je treba hledat smerem k tomu OC - zacal bych biosem v defaultu a zadne OC neaktivoval, natoz menil rucne ty hodnoty. Mit OC totiz znamena, ze muzou byt omezeny ty setrici rezimy ze kterych trva aktivace nejdele - pro vyzdimani co nejvyssiho vykonu, ktery by se jinak promarnil cekanim nez nabehne cpu na plnej vykon - takze se drzi vzdy nachystanej.

A mozna by stalo za to se podivat kolik takova typicka sestava s 5800X ma tahat wattu v idle.

170
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 30. 04. 2023, 15:05:35 »
DDR4 maji standardne 1.2V, tak bych spis pouzil nejaky nepretaktovany rezim u pameti, ale je mozny ze ti to pak spadne na 2400 MT/s

171
Software / Škálování výkonu v dual-socket systému
« kdy: 30. 04. 2023, 13:56:29 »
Ahoj, nějakou dobu testuji hromadu sestav se stejnou zátěží (kompilace kernelu v ramdisku) a měřím čas a idle/load spotřebu.

Na sestavách, které mají dva sockety dostávám při 2 CPU podprůměrný - handicapovaný výkon, např.

Kód: [Vybrat]
1S 1xE5-2603 v3 (4x8GB ram) ... 17m55s
2S 2xE5-2603 v3 (8x8GB ram) ... 10m01s

Očekávaný ideální stav by byl spíše 8m58s, teď je 2S o cca 11% pomalejší.

Tuším, že problém bude někde v NUMA - jakože část té hromady (make -j13 pro 2x 6C/6T) gcc instancí má alokace paměti z druhého socketu, ke kterému vede celkem úzké spojení a s velkými latencemi.

Jak lze tohle řešit na obecné úloze (kernel make) ?
Na custom aplikaci by asi šlo přidat hinty ohledně alokace paměti, ale zde fakt nevím.


172
Hardware / Re:CPU AMD Ryzen 7 5800X a co nejnižší spotřeba
« kdy: 30. 04. 2023, 13:30:12 »
Zkus jeste snizit napajeni IO DIE, protoze to je to co tady nejvice zere (hned po chipsetu a te quad sitove karte)

Prechod na jine CPU ma smysl jenom kdyz najdes nejake single-die APU, abys tam nemel ten zravej pausal od iodie, a taky pak je lepsi jit do chipset-less desky (protoze ty APU dokazou jet jako SOC), ale tim ztratis hodne konektivity.

HT-off nemeni idle spotrebu, ale zhorsuje celkovou energetickou efektivitu v zatezi (HT je v podstate vypocetni vykon zdarma).

Nejnizsi idle spotreby dosahuji holt jakekoliv Intely (od seste-sedme generace vejs).

173
Server / Re:Smysluplnost "aliasů" v hlavičkách To,Cc
« kdy: 29. 04. 2023, 18:19:35 »
Vetsinou to ma smysl, kdyz je ten alias jako "NazevFirmy NecoKveci" <noreply@firma.tld>, konkretni priklady ze soucasnosti:

Kód: [Vybrat]
ANSWEAR.cz <obchod@answear.cz>
STMicroelectronics <st@event.st.com>
AMD Xilinx <noreply@info.xilinx.com>
LUCID Vision Labs <webmaster@thinklucid.com>
LEXMARK <contact@collectedbylexmark.com>
Zásilkovna <noreply@zasilkovna.cz>
The Box Team <boxteam@customer.box.com>
Samsung Cloud <no-reply@samsungcloud.com>

u vsech preferuji videt takto lidsky zformovanej alias, nez nejakou slozitejsi a casto zbytecnou (noreply) emailovou adresu.

A pak samozrejme u lidi ze tam maj "titul jmeno prijmeni, titul", kdyz jejich mail muze byt cislo@skola.tld nebo nejaky zkraceny login (vivat studentske xPrijmNN@ ucty na VUT Brno).

Pokud to nejaky internetovy straspytel nevyplnuje nebo randomizuje, tak samozjreme "452hs73" 82jhn@domenta.tld postrada nejaky prakticky prinos.

174
Server / Re:Vzdálená komunikace s Linuxem
« kdy: 25. 04. 2023, 13:01:28 »
Co potrebujes tahat za data z toho ciloveho stroje?

Typicky se na reseni "rekni mi XYZ, rekni mi XYZ, rekni mi XYZ" pouziva SNMP - protoze ma mensi overhead nez navazovani TLS spojeni. Ale zda potrebujes sifrovat je uz otazka toho, co za data tahas a jak dulezita je jejich ochrana.

https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

175
Distribuce / Re:Hledám konkrétní distribuci
« kdy: 24. 04. 2023, 15:43:22 »

176
Jsem o necem podobnem premyslel, mam pusteno Radio1 pres net ze streamu a nekdy me fakt zaujme dobrej song.. ale to by chtelo fyzicke tlacitko jako v televiznich soutezich, at to proste cinknes a ono se to omarkuje. Me reseni bylo spise ze bych nahraval treba 24h smycku, pripadne vice dle kapacity. Ono to audio zas tolik nezere.

177
Je znamy objem (pocet kusu) co protoci PC engines vs napr. Mikrotik ? (pripadne i Turris?)
Na tom pak zavisi zrejme nejvic.

Jako HW navrhar nevidim problem dnes cokoliv navrhnout - technicky tomu fakt nic nebrani
(tedy pokud tise ignorujeme fakt, ze efektivita CPU se za poslednich X let nikam neposunula).

Nejvetsi problem je v objemu - kdyz budete brat byt i desitky tisic "obskurnich" cipu od Intel/Amd, tak jste v podstate nezajimavy looser z chude vesnice a nemate prilis sanci. Pri 100K vas mozna pozdravi a pri 1M se s vama budou bavit. Jejich veci jsou cileny holt na desetimilionove objemy aktualni generace v rocnim okne.. ne na desetilete dodavky z tohoto networking segmentu. Na to se hodi jini vyrobci, co industrialni portfolio opecovavaji lepe (napr. Freescale). Btw, kdyby se jednalo i o ten 1M zarizeni, tak to uz je mozna zajimave pro mensi podniky, ktere vam slepi SoC na miru.. jen to holt nebude x86.

To, co se realne da vymyslet a obchodne i udelat dobre predvadi Mikrotik, ackoliv zadne jejich zarizeni nemam a vzdy najdu nejaky duvod proc ho nemit - bud je to silena bota v architekture a uzke hrdlo, nebo snaha resit hw problem v sw, nebo srotove streva - cipy ktere jini uz posilaj do kose.

Kdyz vidim jak se tu placaj odkazy na consumer hnuj, tak asi hodne lidi nepochopilo otazku, nebo netusi v jakem segmentu se ti PC engines vubec nachazeli.

Ad cina - na to me napadaji jenom neslusna slova. Ted jsem vybiral projektor.. a takovy hezky cinsky (xgimi horizon) ma sice zajimavou vyhajpovanou reklamu, lokalizovanou i ceskymi dobroseri, ale clovek se nemuze dopatrat ani hmatatelne specifikaci, natoz dokumentaci. Tak tohle panove fakt ne. ISP networking neni trh, kde si poridite nejaky nepodarek a pak to hodite na bazar, protoze jste dokazal rozpoznat jaky kram to je (a ze to vetsina lidi ani nepozna.. je uz dalsi problem).

178
Vývoj / Re:C pre-preprocesor
« kdy: 20. 04. 2023, 22:56:01 »
Tak realny kod ale muze byt v binarce taky out of order - takze to bude skakat sem tam a tohle nezaindentuje ani clovek, natoz stroj.

Takze si vem par jednodussich pravidel a zkus je aplikovat na svuj code flow na vystupu disasm

179
Server / Re:Je takýto výkon VPS OK?
« kdy: 19. 04. 2023, 20:08:39 »
Uf, přijde mi, že mícháte dohromady typ hypervizoru a způsob virtualizace.

Vubec. Bavim se pouze o ciste - HW nativni - virtualizaci (v mem pripade KVM)

Odchylky mimo - jako emulaci/jit uznavam pouze pro pripad cizi architektury - a paravirtualizace je mozna tak vhodna pro QubesOS, kde by ten IO/IPC overhead byl z plne virtualizace (a emulace hw virtualniho stroje skrze trapy) precejenom zbytecny.

180
Server / Re:Je takýto výkon VPS OK?
« kdy: 19. 04. 2023, 19:30:54 »
... Xen spravuje RAM – typicky hostitel se části RAM vzdá a nechá Xen ji přidělit jinému VM. O swap se pak stará až kernel, tedy každá VM zvlášť. Tak mi to funguje v QubesOS, což je OS založený na virtualizaci.

Podobnou situaci bych čekal u hypervizorů s podobnou architekturou, třeba HyperV, na kterém stojí mj. WSL.

A vlastně to dává smysl i u tradičnějších virtualizátorů jako VirtualBox a KVM. Jednak kvůli výkonu (přístup k paměti ve VM by si vyžádal průchod zbytečně mnoho vrstvami), jednak kvůli zmíněným překvapením, a jednak protože takovéto věci typicky běží v kernelu a mohou dělat různé psí kusy…

Od nejake generace procesoru (cca xeon 5500 *1) existuje rozsireni TLB na dvojurovnove mapovani pameti (EPT), ktere proste dovoluje delat virtualizaci pohodlneji, a neni uz treba pouzivat baremetal hypervisor. A nektere verze vmware na tom zaviseli, takze ty novejsi nesli pustit na starem hw.

*1
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-69CDC049-8B42-4D26-8B47-94961B1777A4.html

EPT here:
https://en.wikipedia.org/wiki/Second_Level_Address_Translation
https://www.alibabacloud.com/blog/a-tribute-to-hackers-the-way-to-explore-memory-virtualization_599058

Citace
# cat /proc/cpuinfo | grep vmx\ flags
vmx flags       : vnmi preemption_timer invvpid ept_x_only ept_ad ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid unrestricted_guest ple shadow_vmcs pml ept_mode_based_exec
model name      : Intel(R) Xeon(R) CPU E3-1220 v6 @ 3.00GHz

imho xen bylo "in" do doby nez prislo EPT, ktere pak umoznilo vznik reseni jako KVM
(pred 15 lety jsem xen zkousel, dnes s qemu-system/kvm neni duvod)

Stran: 1 ... 10 11 [12] 13 14 ... 153