Americký výrobce čipů Nvidia získal od vlády prezidenta Donalda Trumpa souhlas s prodejem svých pokročilých počítačových čipů používaných k vývoji umělé inteligence (AI) H20 do Číny. Prodej těchto čipů speciálně upravených pro čínský trh by tak mohl být brzy obnoven, uvedla firma na svém blogu. Americká vláda zakázala prodej v dubnu, v době eskalace obchodního sporu mezi oběma zeměmi. Tehdy to zdůvodnila obavami, že by čipy mohla využívat čínská armáda.
3D software Blender byl vydán ve verzi 4.5 s prodlouženou podporou. Podrobnosti v poznámkách k vydání. Videopředstavení na YouTube.
Open source webový aplikační framework Django slaví 20. narozeniny.
V Brestu dnes začala konference vývojářů a uživatelů linuxové distribuce Debian DebConf25. Na programu je řada zajímavých přednášek. Sledovat je lze online.
Před 30 lety, tj. 14. července 1995, se začala používat přípona .mp3 pro soubory s hudbou komprimovanou pomocí MPEG-2 Audio Layer 3.
Výroba 8bitových domácích počítačů Commodore 64 byla ukončena v dubnu 1994. Po více než 30 letech byl představen nový oficiální Commodore 64 Ultimate (YouTube). S deskou postavenou na FPGA. Ve 3 edicích v ceně od 299 dolarů a plánovaným dodáním v říjnu a listopadu letošního roku.
Společnost Hugging Face ve spolupráci se společností Pollen Robotics představila open source robota Reachy Mini (YouTube). Předobjednat lze lite verzi za 299 dolarů a wireless verzi s Raspberry Pi 5 za 449 dolarů.
Dnes v 17:30 bude oficiálně vydána open source počítačová hra DOGWALK vytvořena v 3D softwaru Blender a herním enginu Godot. Release party proběhne na YouTube od 17:00.
McDonald's se spojil se společností Paradox a pracovníky nabírá také pomocí AI řešení s virtuální asistentkou Olivii běžící na webu McHire. Ian Carroll a Sam Curry se na toto AI řešení blíže podívali a opravdu je překvapilo, že se mohli přihlásit pomocí jména 123456 a hesla 123456 a získat přístup k údajům o 64 milionech uchazečů o práci.
Byla vydána (𝕏) červnová aktualizace aneb nová verze 1.102 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.102 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
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: