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 - janevim11165123

Stran: [1] 2
1
Pak tu jsou ještě idustriální PC s Intelem. Např: https://www.bcmcom.com/bcm_product_MX6412J.html

Cena neveřejné. Evropský distributor mi to nabídl okolo 500 USD.

2
Pokud nevadí Intel a čína, tak jsou tu různe networking SBC, většinou dohledatelné pod názvem Topton. Jako základní klíč k hledání doporučuji zvolit si procesor. Odkazy dle CPU k některým které jsem si nedávno prohlížel:

Relativně starý, ale asi nejvíc low power Intel J4125: https://www.aliexpress.com/item/1005004145629664.html
Best seller N5105/N6005 (stejný CPU jako je v Odroid H3): https://www.aliexpress.com/item/1005003744743799.html
Trochu modernější než N5105, ale víceméně velmi podobné J6412/J6413: https://www.aliexpress.com/item/1005005310431543.html
Nejnovější Intel N95/N100/N200/N305 (tady bych doporučil počkat na nový návrh desky, to co číňané narychlo spatlali je přinejmšním divné. Např. to má "SATA power connektor", ale nemá SATA konektor...., nadruhou stranu ten jeden uživatel co k tomu napsal recenzi (s obrázky) je spokejný): https://www.aliexpress.com/item/1005005411300587.html

Žádný z nich jsem zatím nezkoušel, ale trochu mě lákají. Nejvíc recenzí na netu je k těm s procesorem N5105, který se dle Aliexpresu i nejvíce prodává. Např na youtube: https://www.youtube.com/watch?v=xExmvIHEQao

K všem zmíněným lze najít zmínky, že je vyrábí firma "Dongguan Tuofuton Electronic Technology Co., Ltd." a víceméně je na Aliexpresu přeprodávají obchody, které se označují jako Topton (nejčastější, pravěděpobně je to B2C kanál přímo Dongguanu), Kingynovy, Qotom, CWWK a další. Věšinou mají copy pastované obrázky a když se jich na cokoliv zeptáte, tak vám nejsou schopni odpovědět (tzn. vůbec neví co prodávají). Pozor si dejte na to že u spousty těch procesorů existuje více variant desky, tak si před koupi pořádně prohlédněte co mají na (rozmazaných) obrázcích. U těch best sellerů jze najít detailnější fotky v recenzích (hint pro větší rozlišení obrázků z recenzí: pravý klik na obrázek > kopírovat URL obrázku > nová záložka > ...).

Ty co jsem vyjmenoval mají 4 síťovky, ale existují i varianty s 5 a 6. jde je najít v menu příslušných obchodů na Ali. Pozor na mini PCIe, většinou je jen USB only (tzn bez PCIe linek).

Prakticky všechny mají síťovky od Intelu (narozdíl od Odroidu například). Nejčastěji I226, což je nástupce problematické I225 ale i na 226 někteří reportují taky nějaké bugy (zejména kolem EEE), takže s RTL8125 si asi nemají co vyčítat.

3
Vývoj / Re:Alternativa za Excel Visual Basic?
« kdy: 21. 11. 2022, 00:33:11 »
Můžeš C# jak už kolega výše zmínil. Hledej VSTO. Ale je to docela opruz, protože to je jen wrapper nad COM objekty, takže třeba Watch window nefunguje při debugování a asi se toho nejde víc.

4
Bazar / Re:Prodám: Odroid H2
« kdy: 14. 06. 2022, 09:54:53 »
To je nějaká nová alternativa Aukra? :-)

jo jo, něco takového.

5
Bazar / Re:Prodám: Odroid H2
« kdy: 14. 06. 2022, 07:40:51 »
Nabízím 1700Kč + zasílkovna
fajn :-) 1750Kc + zasilkovna

fajn :-) 1800Kc + zasilkovna

6
Bazar / Re:Prodám: Odroid H2
« kdy: 13. 06. 2022, 16:26:49 »
Nabízím 1700Kč + zasílkovna

7
Vývoj / Re:Má smysl vyrábět vlastní e-shop?
« kdy: 24. 01. 2022, 17:13:16 »
Hele a neexistuje nejaky zakladni eshop treba na githubu? Aby to umelo polozky s obrazky, kosik, a objednavku? Kdyby to bylo slusne napsane, tak uz bych si tam potom dodelal co je treba.

https://github.com/PrestaShop/PrestaShop

8
Software / Re:Výcuc 10TB disku, většinou nuly
« kdy: 01. 12. 2021, 09:34:27 »
[...] V diskuzi padlo několik mýtů.
[...] Pro připojení této zálohy je nutné ji rozbalit. Neznám žádný zpsůob jak by šel namountovat nerozbalený soubor.
to je mytus ;-) viz

Já jsem tam schválně nepsal že neexistuje žádný způsob, ale že ho neznám. Podle mě je ten výrok korektní (byť docela neužitečný).

9
Software / Re:Výcuc 10TB disku, většinou nuly
« kdy: 30. 11. 2021, 18:54:04 »
to co popisuješ používám na zálohování již několik let. Funguje to a má to některé velmi dobré vlastnosti. Doporučuji ale udělat několik zlepšení. Doplním i některé kvalitativní odhady o výkonu a efektivitě, které mám za ty roky vypozorované. Používám to na vytváření zálohy a to konrkténě buď zálohy oddílu (40 GiB) na kterém je spousta malých souborů a také na zálohy celých disků, které jsou v mém případě velké 500 GiB a 1000 GiB.

Netuším proč přesně tam máš parametry, které tam máš a zejména jestli jejich použití dává smysl, když zohledníš skutečnost že to posíláš přes pv a pak do gzipu. Já používám následující poměrně jednoduchý příkaz a zatím jsem s ním neměl žádný problém.

Kód: [Vybrat]
pv /dev/nvme0n1 | pzstd -o mujdisk.bin.zst
Moje první doporučení je nahradit gzip. Gzip je poměrně pomalý a bude brutálně spomalovat vytváření zálohy. Je dobré si uvědomit jak rychlý disk zálohuješ a jak rychlé je medium na které zálohuješ. V mém případě dělám zálohu SSD (realistická rychlost čtení cca 1 GBps) na mechanický disk (realistická rychlost zápisu cca 150 MBps). Takže v mém případě (nejlépe) potřebuji kompresní algoritmus, který dokáže generovat výstup rychlostí 150 MBps a takových moc není. Je třeba poznamenat, že ne vždy a ne ve všech fázích komprese rychlost limituje pomalejší disk. Pokud máš na disku 200 GiB nul, tak jejich přečtení bude trvat déle než zápis jejich komprimovaného obrazu. Proto když spouštím ten příkaz pv, tak se progressbar neposouvá lineárně, ale v určitých částech roste hodně rychle a v některých zase hodně pomalu. Postupem času jsem zkoušel pigz, lz4 a nakonec skončil u pzstd (paralel zstd), který má sice taky nějaké rezervy a bottlenect v tom, že všechny I/O operace směruje přes jedno jediné vlákno, ale zatím mi výkonově vychází nejlíp a nic lepšího jsem nenašel.

Velikost zálohy, která ti takto vznikne většinou odpovídá velikosti obsazeného místa na disku, právě proto že neobsazené oblasti se dobře komprimují. Nejsem si zcela jist, jestli tomu nepomáhá i TRIM na SSD. Domnívám se, že při čtení neobsazených oblastí řadič disků vrací nuly, protože z logiky věci řadič stjeně může s buňkami manipulovat aby vyvážil jejich zatížení a zvýšil tím jejich životnost. Nicméně v takovém okamžiku je jejich obsah nevalidní a řadič disku to ví.

Jak jsem zmiňoval, tak je dobré si uvědomit jak rychlý kompresní algoritmus potřebuješ, ale je také dobré si uvědomit jak rychlý dekompresní algoritmus potřebuješ. Za určitých okolností můžeš mít jiné požadavky na dekompresi než na kompresi (jeden příklad zmíním dáleú. Taky kompresní algoritmy mohou mít jiné (zejména výkonové) vlastnosti při kompresi a jiné při dekompresi. Musíš volit kompresní algoritmus, tak aby (nejlépe co nejrychleji) splnil tvoje požadavky ve všech případech, kdy zálohu budeš potřebovat.

V diskuzi padlo několik mýtů. První mýtus:

image s particiami len tak nemountnes...

což další diskutující správně vyvrátil, ale pro jistotu přispěl druhým mýtem:

image s particiami len tak nemountnes...

mount -o loop,offset=...

Ale souhlas, je to přes koleno. Ten LBA offset se musí ručně zjistit/spočítat.

Lze namountovat libovolný oddíl, klidně i všechny a není nutné znát/parsovat z tabulky oddílů/odhadovat/počítat žádné LBA. Linux na to má mechanizmus pro všechny myslitené (a někdy i nemyslitelné) tabulky oddílů, takže s MBR ani GPT není žádný problém. Linux to udělá za tebe. Nekomprimované nebo dekomprimované zálohy tohoto typu mají velkou výhodu že je lze (minimálně v Linuxu) snadno připojit a tím například ověřit integritu zálohy.

Pro připojení této zálohy je nutné ji rozbalit. Neznám žádný zpsůob jak by šel namountovat nerozbalený soubor. Omezení vychází z toho, že do komprimovaného souboru nejde (jednoduše) dělat random access. Jakmile jej ale budeš mít rozbelný, tak si obraz disku (nebo i oddílu) můžeš namapovat na loop zařízení příkazem losetup, a pak si můžeš Y-tou partition připojit z loopXpY zařízení. Příkaz losetup si najde sám volné loop zařízení, ale pro determinističnost doporučuji specifikovat loop zařízení ručně. V takové podobě to můžeš udělat následujícím příkazem:

Kód: [Vybrat]
losetup -Pr /dev/loop123 mujdisk.bin

Soubor mujdisk.bin je dekomprimovaný soubor zálohy mujdisk.bin.zst. Zařízení loop123 je neobsazené loop zařízení. Pokud u tebe loop123 existuje, tak použij jiné libovolné číslo, které zatím neexistuje. Parametr -P znamená partscan. Příkaz tak nechá Linux prosekonvat tabulku oddílů a zaregistruje jednotlivé oddíly. parametr -r zajistí, že loop zařízení bude readonly, ale můžeš ho vynechat a pak do (rozableného) obrazu můžeš klidně zapisovat.

Jakmile budeš mít loop zařízení, tak si můžeš např. čtvrtý oddíl připojit do složky aa jednoduše pomocí:

Kód: [Vybrat]
mount -o ro /dev/loop123p4 aa

Jako velkou výhodu těchto záloh považuji, že zatímco prakticky ve všech krocích pracuješ s jedním vlekým souborem, tak finální obnovu můžeš provést na jiném PC/serveru a přenést zpět pouze soubory, které chceš obnovit. Jako další výhodu považuji, že lze velmi snadno ověřit integritu zálohy. Prostě to skusíš připojit, podívaš se jestli tam jsou soubory jaké chceš, můžeš si ověřit, že jsou nepoškozené, atd. Já osobně své zálohy nahrávám do cloudového uložiště buď AWS S3 nebo Azure Blob Storage. Vždycky po tom co zálohu nahraju do cloudu, tak si tam pronajmu server na kterém si zálohu stáhnu, zkontroluju chcekcsum a zkusím ji připojit abych se ujistil, že záloha je funkční. Pokdu funkční je, tak ji změním access tier na archive, abych za to moc neplatil (v mnohých datacenterech u obou providerů, lze takto mít ulžoené zálohy za cenu 1 USD za 1 TB za měsíc). Tady se dostávám k tomu co jsem lehce naznačil jednom z předchozích odstavců, kdy jsem popisoval důležitost volby kompresního algoritmu. Pro obnovéní souboru ze zálohy nebo ověření integrity ji potřebuješ rozbalit. Server v clodu ale má jiné vlastnosti než disk ze kterého byla prováděná záloha a disk na který byla záloha ukládana. Jakmile máš zálohu uloženou perzistentně na cloudovém uložišti, tak na samotném serveru, kde provádíš obnovu nebo verifikaci integrity, ji již nepotřebuješ perzistentně. Nabízí se tak možnost že se zálohou nebudeš pracovat na pomalém disku serveru v cloudu, ale na potřebnou krátkou dobu si pronajmeš server s velkým množtvím RAM (AWS i Azure mají i servery s 16 TiB RAM, které se pro tyto účely hodí) a se zálohou budeš pracovat v ramdisku, který je exterémně rychlý. Pokud operaci se zálohou uděláš rychle (a pak nezapomenš server zlikvidovat), tak to ani není moc drahé. V cloudu záleží na hodně faktorech, mimo jiné vedle koho běžíš, protože je to sdílená infrastruktura, ale obecně tam ramdisk dosazuje 20 - 80 GBps. Nicméně po počáteční euforii je potřeba se vrátit na začátek: Je použitý komrpesní algorimtus (který při kompresi byl dimenzován na output speed 150 MBps) dostatečně rychlý i pro dekompresi na rychlostech 20 - 80 GBps? Odpověd je u většiny algoritmů bohužel ne. Ani ten pzstd, zejména kvůli zmíněnému botlenecku, neposkytuje kdovíjak dobrý výkon. Práce se zálohou v ramdisku bude rychlá, ale ne tak rychlá jak bych např. já potřeboval. Já jsem se zálohou několikrát v ramdisku zkoušel pracovat a pocitovně mi to přišlo zhruba 4x rychlejší než když zálohu zpracovávám nad instancí s sice malou RAM, ale zase s lokálním NVME SSD (v Azure řada Ls a Lsv2, V AWS řady i3 a i3en) a to mi přijde jako malý speedup, když vezmu v potaz, že porovoz serveru s hodně RAM je mnohem dražší.

Pravděpodobně, ale mžůeš najít spoustu dalších use case pro tyto zálohy a mě se za těch několik let kdy je dělám osvědčily. mají nějaké nevýhody, jako že je nelze dělat za běhu, ale i tak mi připadají jako docela dobré a spolehlivé.

10
Hardware / Re:Samovolne zapinanie PC a notebooku
« kdy: 26. 11. 2021, 12:01:21 »
Následujícíá příkaz umí vypsat zdroj, ale nebývá to jedndouché rozpoznat.

Kód: [Vybrat]
powercfg -lastwake

Doporučuji zakázat buzení přerušením z RTC, který Windows konfiguruje aby budil PC podle událostí v plánovačí úloh.


11
Sítě / Re:VPN pro přístup do lokální sítě
« kdy: 14. 11. 2021, 16:13:43 »
:::8080 znamená že poslouchá na všech rozhraních. Jsou to v podstatě dvě dvojtečky indikující IPv6 adresu a třetí dvojtečka je oddělovač IP adresy a čísla portu. IPv6 adresy se (následující popis je velmi zjednodušem) zkracují způsobem, že blok nul lze nahradit dvěma dvojtečkama. Např adresa ABCD:0000:0000:0000:0000:0000:0000:1234 lze zapsat jako ABCD::1234. Podobně, adresu 0000:0000:0000:0000:0000:0000:0000:0000 lze zapsat jako :: adresa samých nul je ekvivalentem samých nul na IPv4.

12
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 14. 10. 2021, 19:30:17 »
nemusíš programovat ani řadič rozhraní DDR a už vůbec ne řadič rozhraní PCIe. Dokonce i kdyby jsis je fakt chtěl (a věř mi, že fakt nechtěl. DDR možná, ale PCIe fakt ne) napsat ručně, tak smůla (vysvětlím v třetím odstavci). Obecně se to dělá, že si ve vývojovém nástroji přidáš blok, který je obvykle poklikáním konfigurovatelný a v konfigurátoru si naklikáš jaké to má mít vlastnosti. Blok pak bude mít nějaké "vodiče" na které přivedeš adresy, data, transakce, .... Většinou tak implementuješ jen něco, co do těch bloků bude cpát data, což je mnohem jednodušší než implementovat ten samotný blok.

Ten konfigurovatlený blok, který si tam vložíš je speciální blok (podobně jako DSP bloky, malé RAMky, atd) ve skutečnosti není syntetizován na samotném hradlovém poli. Důvod je ten, že ta sběrnice je extrémně rychlá a není rozumně reálné implementovat obsluhu tak rychlých signálů v tak komplexní struktuře hradel. Místo toho je to tam natvrdo zadrátované v mnohem přímočarejší, ale neupravitelné struktuře.

Jen pro představu hodiny uvnitř té hradlové struktury dokáží běžet na frekvencích okolo 500 MHz. Není tedy možné zpracovat rychlejší signál než 500 MHz. Signály, které ale používají zmíněné sběrnice běžně používají hodiny na frekvencích daleko přes GHz (např. DDR běžně 1600 MHz, dnes klidně i víc). Obecně si to předdstav tak, že je to řešeno způsobem, že do toho speciálního bloku popsaného v prnvím odstavic posíláš nebo čteš z něj paralelně třeba 32 bitů na frekvenci 50 MHz (což je na většine FPGA v pohodě zvládnutelné s prstem v nose), ale na druhé straně na vodíčích ven z FPGA ten speciální natvrdo zadrátovaný blok generuje nebo čte jeden (nejčastěji diferenciální) signál na grekvenci 1600 MHz serializovaný z těch dat co jsi tam pralelně poslal.

Ten blok je ve skutečnosti složitějíš a řeší i nějaké věci ohledně protokolu, který se tam používá. K tomu tě většinou navede to co ten konfigurátor toho bloku umožňuje naklikat.

Ok a teď abych zodpověděl tvůj dotaz: Najdi si na stránkách výrobce FPGA, které používáš uživatelskou příkazu (u Xilinx se to jmenuje User Guide - UG, u jiných výrobcí většinou Application Node - AN) a měl bys najít příručky věnované PCIe i příručku věnovanou DDR. Tyto příáručky nebývají step-by-step tutorial, ani tam nebývá detailní popis toho protokolu, ale vše podstatné k základnímu zprovoznění by tam mělo být.

13
Server / Re:10Gbps VPS niekde v európe
« kdy: 16. 09. 2021, 18:23:22 »
AWSko má spoustu EC2 instancí připojených přes 10 Gbps.
A nemají nějakou úplně nesmyslnou cenu za přenesený gigabajt, takže se na 10Gbps nedoplatí? Nebo si to s něčím pletu?

Contabo má dedikáče s 10G: https://contabo.com/en/dedicated-servers/intel-10-core/?addons=1238,1387&image=debian.290&qty=1&contract=1

mají, ale jen ve směru ven. Ve eu-central-1 (frankfurt) je to aktuálně 0.09 USD za 1 GB ven a první GB je zadarmo.

Záleží jestli potřebuje 10 Gbps trvale nebo to chce kvůli vykrytí špiček, atd.

14
Díky, nějaké jiné řešení? Nechci sdílet pro všechny uživatele v síti své dokumenty.

A firewall nic?

15
Hardware / Re:Připojení k SPI 3.3V součástku s 1.8V
« kdy: 24. 04. 2021, 19:05:32 »
Flashky od Winbondu (a klony) se vyrábí i v 3.3V variantě. Nejlepší tedy patrně bude použít vhodnou součástku.

Pokud to potřebuješ jen přečíst nebo jednorázově přepsat a nemáš k dispozici žádný 1.8V systém (třeba nějakou destičku s mikrokontrolérem, atd), tak sice můžeš vyzkoušet nějaké analogové tranzistorové shiftery, ty ale nesmíš taktovat moc rychle, protože celkem významě zkreslují signál. Lepší řešení je použít něco jako https://www.laskarduino.cz/8-kanaly-obousmerny-prevodnik-logickych-urovni-5v-a-3-3v/ což je mnohem robustnější (a potenciálně spolehlivější) řešení.

Stran: [1] 2