Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Dobry den.
Pisu nastroj na statistiku odezvy udp provozu dns cache.
Server ma 2 provozni sitove karty - dotazy mohou prijit po jakekoli, odpovedi mohou odejit take po jakekoli.
Server ma vetsi mnozstvi ip adres na kterych odpovida.
Server ma vice views, jsou rozdelene dle rozsahu, ze ktereho jde dotaz.
Zajimaji mne statistiky pro kazdou adresu serveru a pro kazdy view.
Mam hotovy prototip mereni:
Vzdy 2 parove tcpdumpy s omezenim na view a sitovku (mam 2 sitovky), ktere pomoci pipe posilaji pcap data scriptum, ktere dotaz rozparsuji(ip/udp/dns) a posilaji unix sockety dalsim procesum, ktere:
si drzi okno dotazu a prirazuji jim odpovedi, odecitaji z pcapu rozdil casu a na vyzadani vypisuji statistiky.
Zda se, ze vse funguje jak ma, vzhledem k tomu, ze ma server dost zdroju, to vypada, ze si zatizeni ani nevsimne.
Jen mne trochu desi, ze tam bezi cca 90 procesu tcpdumpu s docela vyzivnym filtrem.
Muj dotaz tedy zni:
Tusite nekdo, zda vetsi mnozstvi spustenych tcpdumpu neudela v systemu nejake uzke hrdlo?
Pripadne zda je nejaky principialni problem tohoto reseni..... kde hledat?
Dekuji
marekDekuji za odpoved.
Bohuzel se obavam, ze mi prilis nepomuze.
Asi jsem zapomel zminit, ze ta cast se statistikama je zcela funkcni a vyhovujici.
Na serveru je takovy provoz, ze to stejne musi byt stejne napsano viceprocesove.
Na podobne projekty jsem se samozrejme podival, z nekterych ponaucil ...
Problem je v tom, ze prave nechci vynalezat hranate kolo, ale chci vyuzit filtry tcpdumpu.
Python je na moji ulohu pomaly, parser mam v golang a i tam jsem musel tvrde optimalizovat.
marek
Pisu nastroj na statistiku odezvy udp provozu dns cache.Třeba takový unbound umí vypisovat hodně detailní statistiky i s histogramem odezvy. V konfiguráku nastavíš
extended-statistics: yesa není potřeba nic zachytávat tcpdumpem.
unbound-control stats_noreset
Bohuzel nas dns software sice histogram vypisuje, ale dolni mez je 1ms.
Do toho se vejde skoro vse, mimo erroru zpusobenych rekurzi.
Takze na vyhodnoceni zhorseni sluzby pri zatezi je to zcela nevyhovujici.
vrchol histogramu mam o rad jinde (0.000062500s)
Dale dotazovaci nastoj, ktery pouzivame na tvorbu statistik (dle adres serveru) ve spickach nestiha...
Dekuji
marekDekuji za reakci.
Duvod proz pcap a ne rovnou sniff interface - je pak mozne delegovat vykon na jiny stroj (tcpdump muze bezet na vyrazne slabsi sonde nez parser/parovac/tvorba statistik.)
90 samostatnych vlaken vychazi z kombinace poctu views X pocet cilovych ip adres X pocet sitovych karet.
Minimalne mi tam musi bezet 2x equivalent tcpdumpu v kolone s parserem, protoze mam 2 sitovky.
Jenomze 2 procesy, kazdy na jednom CPU, nedaji dostatecny vykon.
Takze to stejne musim nekde paralelizovat.
Proto tam mam tu komunikaci pres unix sockety - protoze jsem to zacal psat v go, a pri testovani optimalizaci jsem zjistil, ze parsovani pcap streamu je nejrychlejsi jednovlanove pri uzamceni procesu na konkretni CPU.
Mohl bych to rozbocovat pri tom parsovani, ze bych to posilal na ruzne sockety, ale musel bych zajistit, ze dotaz i parova odpoved pujde na ten samy socket (treba dle srcip srcport dstip dstport hash - pro odpoved samozrejme obracene).
Dale bych musel stejne zajistit, ze se parser bude paralelizovat (pro dostatecny vykon). To bych asi resil s netsniff-ng a fanout.
A jeste je problem s definicema views. Je to docela dost rozsahu i s excludama, takze si napsat funkci, ktera rika pro konkretni IP do jakeho rozsahu patri je radove slozitejsi, nezli zbytek ulohy.
Proto jsem to zpocatku napsal pro kazdou ip adresu serveru, sitovku a view tcpdump->parser->parovac_dotazu_odpovedi/tvorba_statistik
Jenze to znamena 90 samostatnych vlaken.
Uzke hrdlo je parovac_dotazu_odpovedi/tvorba_statistik.
Ve spicce si to pri jednovlaknovem zpracovani bere okolo 60% procesosu. Mame pravidlo, ze bychom meli byt schopni odbavit 10-ti nasobek bezne spicky.
Parser si bere okolo 20% procesoru.
Takze 2 parsery na 1 parovac jsou asi tak akorat?
Z toho vyplyva ze 90 je asi kanon na vrabce, ale kolem 10-20 by to asi chtelo - urcite to rozlozeni nebude rovnomerne...
V tento okamzik to vypada, ze by mohlo vykonove stacit pouze kombinace poctu views X pocet sitovych karet X ipv4/6 X rozpuleni velkych views.
Akorat musim dopsat do tvorby_statistik, ze to ma pocitat pro jednotlive adresy serveru(tim zase trochu snizim vykon).
Zatim to testuji pri beznem provozu a predpokladane vysledky extrapoluji.
Testovaci scenar se stresovymi testy nebude vubec jednoduchy(vygenerovat dostatecny load).
Stejne mi tam ale nakonec zbudou vysoke jednotky instanci tcpdumpu, takze ma puvodni otazka stale plati.
marekProsim co si predstavujete pod cistem reseni?
Zatim jsem nenasel nic, co by se architektonicky blizilo tomuto reseni.
Pokud nekdo o necem vite, sem s tim (proto se take ptam). Ty odkazy co Vam trvaly 5 minut resi bud jiny problem, nebo jsou vykonove o rad slabsi...
Zde se bavime radove o 300 000 dotazu za sec.
"Aplikacni vrsta" je v tomto pripade zabbix a influx/grafana oboje ma ve sprave nekdo jiny, ja mam pouze dodavat data.
Dekuji
marek
Tiskni
Sdílej: