Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Testovat to takto mi poradil kamarád, který se stará o wifi síť ve svém okolí už delší dobu. Neptal jsem se proč,hm, to je zásadní chyba; pokud něco dělám, je dobré vědět, proč to dělám ... takových "zaručených" rad je ... já se domnívám, že je to blbost - nebýt lenosti se zeptat, mohl jsem teď být poučen, že se mýlím
ale výsledky to má slušné.to znamená co?
Pochopil jsem to tak, že tím otestuju jestli tím projde více dat za sebou a v pořádku. Normální packet je tak malý, že tím projde docela rychle a linka je pak většinu času volná.hmm ... tak počítejme, za jak dlouho projde 15 kilobyte:
1 Mbps ... 117,2 ms 2 Mbps ... 58,6 ms 5,5 Mbps ... 21,3 ms 11 Mbps ... 10,7 ms(dovolil jsem si zjednodušení, reálné hodnoty jsou jiné, co jsem zkoušel na 100 Mbps ethernetu, mám rtt 3.1 ms, podle užitého vzorce by to mělo být 2*1,2 ms) jestliže se pingá standardně jednou za sekundu, pak při těchto hodnotách rovněž platí "linka je většinu času volná" ... takže kýžený efekt se nám nějak rozplynul, ne? co se týče "více dat za sebou", jelikož chyby jsou rozloženy víceméně náhodně (rytmus pingu těžko sesynchronisuješ s rytmem rušení, i pokud je pravidelné), více informací o jejich četnosti získáš z toho, jestli se trefují do častěji posílaných malých paketů, nežli z toho, že poměrně spolehlivě zruší pakety velké - aneb že někdo trefí vrata od stodoly je jasné, zajímavější je, zda (jak často) trefí i dveře, kterými zrovna prochází člověk
Nevím pořádně jak jinak to otestovat s tím, co je na tom AP nainstalováno.
man ping
také něco málo napoví ...
Slušné výsledky - vidím, že je něco špatně.aha ... to lze ovšem vyčíst i jednodušeji ... jinak jak jsem naznačil, z deseti pingů získám podrobnější informaci, vím kolik jich dojde, to je deset hodnot, než z jednoho rozděleného do deseti fragmentů (resp. asi jedenácti), vím jen jestli došel nebo ne, to jsou dvě hodnoty ... jedině že by vysílání kontinuálního toku dat mělo z hlediska WiFi nějaký speciální význam, který mi uniká dík neznalosti, jak to fyzicky tím vzduchem chodí - v tom případě to ale stále lze nasimulovat pakety posílanými rychle za sebou
Statistika ping pro 192.168.1.3: Pakety: Odeslané = 10, Přijaté = 9, Ztracené = 1 (ztráta 10%), Přibližná doba do přijetí odezvy v milisekundách: Minimum = 127ms, Maximum = 170ms, Průměr = 145ms Ctrl+Break Odpověď od 192.168.1.3: bajty=20000 čas=156ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=136ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=134ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=126ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=158ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=166ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=171ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=150ms TTL=255 Odpověď od 192.168.1.3: bajty=20000 čas=145ms TTL=255Menší pakety mají odezvu do 5ms. PS: To sw řešení bych nevymyslel. Blahopřeji. PPS: Dobře propájejte konektory
eth1 IEEE 802.11b/g ESSID:"SmrkNet" Nickname:"Mrakoplas" Mode:Managed Frequency:2.412 GHz Access Point: 00:07:40:A0:5E:59 Bit Rate:24 Mb/s Tx-Power=31 dBm Sensitivity=20/200 Retry min limit:20 RTS thr:2347 B Fragment thr:2346 B Link Quality=66/0 Signal level=-71 dBm Noise level=-132 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Nechapu, proc tu vsichni tak nadavate?proč? třeba proto, že dělá něco, o čem nicmoc neví, čemuž se bohužel člověk občas nevyhne, ale ani se to nesnaží dozvědět (!) - pokud chci diagnostikovat spoj, nevím jak na to a nechám si poradit, tak jako součást té rady chci také vědět, co tím vlastně zjistím, moje první otázka by byla proč zrovna tahle velikost, na co to má vliv či co se projeví ... on se prostě nezeptal, neví, ale už hodnotí výsledky metody (že jsou "slušné"? to jako že nemluví sprostě?) ... třeba se s tím, že pingat většími pakety než je MTU je zavádějící, mýlím a budu za nevzdělance nakonec já, ale aspoň jsem o tom ochoten otevřít diskusi a neberu to jako fakt, že mi to někdo nadiktoval ...
Tiskni Sdílej: