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 - František Ryšánek

Stran: 1 2 [3] 4 5 ... 76
31
Sítě / Re:Řízený switch na základní správu sítě
« kdy: 09. 04. 2023, 17:23:02 »
... ale co existuje CAKE (používaný v SQM), tak je to asi ve většině případů už jen zbytečná práce. Změřím běžně dosahovanou rychlost internetu v obou směrech, nastavím SQM trochu pod a je hotovo.

Koukám na cake (na konci odkázané stránky je PDF slideshow) ... to vypadá jako krok správným směrem. Automatická přednost pro "řídký provoz", SQM dělá shaping taky v uplinku...

Docela mě překvapila informace, že jsou někteří ISP schopni nafrontovat před úzkým hrdlem směrem do poslední míle klidně několik minut provozu. To je masakr. V tom případě chápu motivaci, proč cake původně vznikl.

32
Vývoj / Re:C pre-preprocesor
« kdy: 09. 04. 2023, 14:10:10 »
Rada: napiš si databázi instrukcí a podle toho vygeneruj celý disassembler.
Ano! :-) A začít je třeba symbolickým jazykem pro metapopis opcodů, operandů, multiplexovaných bitů, a jak z toho poskládat oficiální ASM zápis.

33
Sítě / Re:Řízený switch na základní správu sítě
« kdy: 09. 04. 2023, 13:53:57 »
Dobrý den,

v rámci síťovin je traffic shaping obecně jedna z nejsložitějších věcí na konfiguraci, s nevalnými vyhlídkami.
Low hanging fruit není "koupit geniální krabičku a ona to vyřeší".
Obecně pro Vás nemám dobré zprávy.

Managed switch Vám to nejspíš nevyřeší. Základní managed switche umí VLANy a třeba 802.1p (priorizace), ty lepší by možná dokázaly i IP DSCP apod. Ale traffic engineering s tím, že si rozdělíte provoz do tříd a pak jim dáte "prioritu do určité šířky pásma"... tohle bych v L2 switchi spíš nehledal. Některé lepší switche (midrange Cisco?) podle mého umí "rate limit" = omezit šířku pásma nějak definované "třídy provozu" na konkrétní hodnotu, na bázi zahazování tu a tam paketu (na což reaguje TCP) - ale toto Vám nezafunguje ve smyslu striktní priorizace.

Pokud hledáte šanci, ovlivnit priority různých tříd provozu, má to dvě nutné podmínky:

1) je třeba to řešit queueingem s dostatečnou délkou front a schopnostmi třídit druhy provozu, které jsou běžně k dispozici na routeru, běžně nikoli dostupné na switchi

2) ten queueing (s definovanými prioritami a pásmem) je třeba nasadit "směrem do úzkého hrdla". Tzn. egress do úzké linky.

Když porovnáte kapacitu LAN switche (1 Gb každým portem) s kapacitou Vaší DSL konektivity, hádejte, kde je úzké místo: na DSLAMu operátora, případně na "access koncentrátoru" někde ještě dál :-(

V situaci, kdy egress do úzkého hrdla nemáte pod vlastní kontrolou, máte ještě jednu šanci na "mizerné náhradní řešení": vyrobit si úzké hrdlo naschvál na svém konci = nastavit "agregátní třídě všeho provozu" ještě o něco užší pásmo, než je známá kapacita stávajícího úzkého hrdla, které máte typicky od operátora směrem k sobě. V tom případě řešíte především otázku, jaké procento kapacity downlinku obětovat na "uzmutí úzkého hrdla". V této úvaze hraje roli, do jaké míry se "tvarovaný" provoz skládá ze slušně vychovaného TCP, versus z jiných druhů provozu. Protože jiný traffic než zdvořilé TCP se Vám na to umělé úzké hrdlo vyprdne (i s jeho priorizací), a dál bude hltit úzké hrdlo klidně už u providera. Asi bych nepředpokládal, že se k Vám hrne větší objem UDP a dalšího connection-less trafficu. (Ačkoli, co třeba IPTV na bázi multicast UDP? Používá se to?) Spíš bych se obával provozu typu "bittorent a jeho následníci", kam patří třeba taky Windows Update = věci které rozpoutají vysoký počet TCP relací, mezi ně rozloží zátěž a snaží se tak uzmout neférové procento dostupného pásma na úzkém hrdle (které často praktikuje něco ve stylu "fair queueing", ale zřejmě k relativně "férovému" chování statisticky konverguje i prostý nerozlišený queueing bez connection trackingu).
Další problém je, že v ADSL máte sice nějaký strop na šířku pásma downlinku, ale reálně dostupná šířka pásma kolísá - v závislosti na aktivitě ostatních klientů v téže "agregaci" a v závislosti na odstupu signál/šum, což je složitá výslednice několika faktorů.

Takže: vyrobíte si umělé užší hrdlo = nasadíte na svém konci na routeru nějaký softwarový queueing. Naschvál trochu podrazíte pásmo oproti známému úzkému hrdlu (WAN spoj od ISP). Optimisticky předpokládejme, že Vám do toho nehodí vidle Bittorrent / Windows Update / nectnosti ADSL downlinku.

Z čeho to užší hrdlo vyrobit:

Nikdy jsem to nezkoumal na Mikrotiku.

Kdysi se dalo, takto konstruovat pravidla v Cisco CBWFQ (v IOSu na CPE routerech) a reálně to fungovalo. Samozřejmě to líp fungovalo směrem do skutečného úzkého hrdla na páteři ISP - což byl ale problém, protože ta věc tehdy žrala CPU.

Později jsem to zkoušel v HTB na Linuxu. Tam ale tuším nebylo k dispozici pravidlo "totální priorita, ale maximálně do objemu XY kbps". Je to už hodně let, možná proběhl nějaký vývoj.

Ať už se bavíme o Ciscu nebo o Linuxu, tuším se ten akrobatický queueing nasazoval vždycky na egressu do fyzického rozhraní. Tzn. muselo by se to nasadit "směrem do LAN". Což má smysl i ten, že pokud na CPE routeru zakončujete tunely, můžete do toho "tvarovacího frontování" sesypat i provoz, který jste zrovna vybalil z tunelu. (Čert vzal pár procent režie tunelové enkapsulace sem nebo tam.)

Celou dobu se bavím o downlinku.
Komunikace je ale obousměrná. Ztracený ACK může TCP relaci taky pěkně zadrhnout, navíc při videokonferenci je přenos obousměrný i z hlediska payloadu = jde Vám i o uplink už v principu. Štěstím v neštěstí je, že uplink představuje úzké hrdlo, od kterého držíte otěže. Špatná zpráva je, že uplink v ADSL/VDSL je jednak uzoučký (tato technologie má asymetrické pásmo), jednak oproti downlinku ještě více náchylný na problémy z důvodu sdílení více uživateli (kolísání dostupného pásma).
Zajímavou otázkou je shaping provozu baleného v tunelech. Třeba na Ciscu z dob H.323 si pamatuju možnost, značkovat kýžený provoz před zabalením, značku propisovat na vnější hlavičku po tunelové enkapsulaci, a ve finále podle této značky na egressu do uplinku priorizovat...

No a pak je tu otázka, jak se dnešní video-konferenční aplikace chovají k dostupné šířce pásma. Zda nějak hlídají, kolik dat reálně konektivitou proleze, a kolik už ne, a třeba podle toho nějak dynamicky cvičí s kvalitou přenosu. Pokud si videokonferenční aplikace jede nastaveou šířku pásma (rozlišení X komprese) a na nic se neohlíží, tak patrně nemá cenu, snažit se její pásmo omezovat v rámci queueingu na routeru, ale naopak je jediná šance, dát jí pokud možno neomezenou prioritu. Což zase znamená, že pokud videokonference vyžere všechno pásmo, tak nezabrowsíte po webu a nepošlete e-mail.

Suma sumárum:

Váš požadavek je netriviální. Existuje prostor pro ohavné přibližné náhradní řešení, kterému obětujete třeba 10-20% kapacity svého "ISP downlinku", ale to řešení ve finále stejně nebude stoprocentní, stojí na poměrně silných předpokladech, které Vám reálně můžou zhavarovat na nejméně třech různých faktorech.

Trochu spravit náladu Vám může možnost svobodně priorizovat uplink, který ale zase obecně trpí úzkou šířkou pásma a konkurencí uživatelů, prakticky napříč technologiemi pro "residential last-mile access" (relativně nejlíp je na tom PON = sdílená optika).

Celé je to ve finále o tom, že pokud nemáte dostatečnou šířku pásma pro videokonferenci + další věci, tak tam to pásmo sebedůmyslnějším shapingem nenahoníte. Snahou toto implementovat jistě odborně povyrostete, ale snadno strávíte několik dní času studiem těch technologií a laborováním - načež nad tím ve finále možná stejně zlomíte hůl (myslím poté, co jste pronikl do všech detailů technologie a dokonale ji pochopil). Otázkou je, zda to budete hodnotit jako ztracený čas, nebo jako užitečnou zkušenost a získané know-how. Osobně jsem to napoprvé zhodnotil jako doplnění svého vzdělání, ale od té doby s tím zájemce posílám do hodně nezdvořilých míst. Toto v situaci, kdy jsem měl pro sebe vyhrazené pásmo o jasně dané kapacitě = pevné číslo, symetrické ven i dovnitř.

=> Pokud chcete něco urvat penězi, a je možnost, tak je to kapacita konektivity.
Utratit hodně peněz za krabičku Vám nejspíš mnoho užitku nepřinese, spíš si do sítě zanesete netriviální chování a nutnost budoucích úprav konfigurace, pokud se podaří zvýšit kapacitu přípojky do inetu.

34
Vývoj / Re:C pre-preprocesor
« kdy: 09. 04. 2023, 11:25:52 »
Jsem jenom naivní x86 hobbík, a tak mi určitě uniká jakýsi širší kontext... nicméně téma mě zaujalo a proto mi odpusťte mimózní reakci :-)

Z nápadů typu "generovat zdrojáky v konkrétním jazyce" mívám obecně pocit, že to autor bere za špatný konec. Že by měl raději změnit návrh svého programu směrem k vyšší úrovni abstrakce - že si ve finále usnadní život. Jako chápal bych to, pokud je z nějakého důvodu striktním cílem maximálně kompaktní kód toho "preprocesovaného C" - ale třeba chápat potom chybové hlášky při kompilaci... "more rope to hang yourself with".

Už tady padl dotaz, proč čisté C. Disassembler přece nepotřebuje běžet v omezeném prostředí na nějaké pitoreskní cílové platformě. Sám jste zmínil gcc/clang/MSVC. To jsou přece implementace moderního C++. S mým omezeným rozhledem mi Vaše zadání zatím připadá jako učebnicový příklad na polymorfizmus, OOP, základní C++. Na první pohled nevím, zda by se Vám hodily šablony - spíš bych to viděl na abstraktní třídu "instrukce", z ní dědit jednotlivé typy instrukcí, těm jednotlivě vdechnout nějakého ducha atd. Jasně, objektově se dá psát nakonec i v holém C, obvykle pokud je součástí zadání "žádné C++".
Společná abstraktní třída "instrukce" by mohla mít statickou metodu "hrubý rozskok, co je zač následující instrukce". Každá "podtřída instrukce" by měla implementovánu metodu "disasm", která by dostala pointer na první bajt ve vstupním bináru a vrátila by např. pointer na první bajt následující instrukce (nebo chybu). Disassembler by vyráběl obdobu "lexikálního stromu" - akorát by to byla spíš sekvence. Případně by se v tom pak daly identifikovat "emergentní sémantické struktury" = skoky, smyčky, začátky+konce funkcí, práci s pojmenovanými proměnnými apod. Pokud má být výstupem sekvence ASM kódu (text), může mít každá "podtřída instrukce" svou vlastní metodu "print" nebo tak něco...

Chápu, že ortodoční ASM/céčkař může namítat, že všechno to C++ lešení je strašně moc datlování navíc. A ozvou se tu možná lidi, že to je úloha na *funkcionální* programování. Tak jako tak: Inu proti gustu... A ano, málo jsem toho zažil.

Už jsem nějaký disassembler držel v ruce (jako uživatel) a rozumím tomu, že třeba není vůbec sranda, najít začátky sekvencí executable instrukcí v bináru, kde je kód promíchaný s daty. Základní vodítka (třeba nějaký ten entry point, rozdělení na "segmenty"?, nedejbože seznam symbolů) může poskytnout formát binárního image (souvisí s linkerem), což asi platí spíš pro ustálené formáty vyšších OS... Vyšší jazyky mají ustálené "function call conventions", což ale neplatí pro volnou tvorbu v assembleru... Máte s tím tématem moje sympatie. Když vidím, s čím si (ne)poradí třeba IDA free... = I s ohledem na případné hledání nějakých vyšších struktur mám pocit, že "zaobjektění" by mohlo být ku prospěchu této následné další práce.

35
Hardware / Re:nahrada za supermicro s Pentiem D pro Proxmox
« kdy: 07. 04. 2023, 11:32:10 »
3000 EUR, tak to je slusna cena za embedded desku.
ta moje stala pod 11 000kc

Taky ta Vaše měla jenom 8jádro a byla už normálně dostupná, když jste ji koupil.

Cena 3000 EURO za motherboard nebo procesor je u Intelu takovým eufemistickým způsobem jak říct, "toto momentálně/zatím není dostupné". V momentě, kdy to reálně začnou vyrábět, spadne cena na mírně přátelštější hodnoty.

Jinak ty Péčkové ATOMy měly být původně "privátní" model pro nějakého výrobce mobilních BTS. Je trochu zázrak, že se k nim Supermicro dostalo.

Celá tahle kategorie CPU s 10+ jádry... mně taky úplně "embedded" nepřipadá :-) Řekl bych tomu spíš "malý server pro labužníky se specifickými potřebami". Že to letujou na desku v úchylném svém formátu, to je obchodní rozhodnutí výrobce desky...

Jestli bylo primární příčinou skutečně selhání zdroje, tak je to fakt pešek v dnešní době. Ošklivé SuperMicro / Ablecom nebo jak se ten výrobce jmenuje.

36
Hardware / Re:nahrada za supermicro s Pentiem D pro Proxmox
« kdy: 07. 04. 2023, 11:22:37 »
vrm fet odpalenej a Vcore v zkratu
:-( smutnej konec. Kvůli součástce za 2 USD odejde procík za 500 USD na desce, která je jako celek ještě dražší.

By me zajimalo co te tvoji bude :-)
To mě taky.

37
Hardware / Re:nahrada za supermicro s Pentiem D pro Proxmox
« kdy: 07. 04. 2023, 11:13:40 »
:-DDD Pentium D.  Tak nic... tzn. hledáte ultra-low-power plnotučnej Xeon s vyšším počtem jader, konkrétně nejspíš něco z rodiny Xeon D.

Váš zesnulý Xeon D-1537 je Broadwell, podle mého krásný kousek z Intelovy první 14nm generace.
Bohužel se zdá, že poslední v rodině Xeon D je momentálně Ice Lake, z nepovedené první 10nm generace. A zřejmě spadá do doby, kdy Intelu začala (opět) hořet koudel, tak se snažil kontrovat zvyšováním taktů za cenu zvýšené spotřeby :-(

Souhlasím s Vámi, že tady je asi dobrá rada drahá. Takový Xeon® D-2173IT vypadá jako možný kompromis. 14 core, 70W, 14nm Skylake.

Pokud byste upustil od požadavku na plnotučný procesor, tak Intel dělá taky ULP procesory s větším počtem ATOMových jader a podporou ECC. Třeba takový ATOM P5362 = jádro Tremont (dnes předposlední), rodina/řada procesoru Snow Ridge. Supermicro s tím má desku. Následníkem má být před-oznámená rodina/řada Sierra Forest (s jádry Gracemont, která známe z CPU Alder Lake). Zatím neproběhl launch, takže na ark.intel.com to není.
Údajně má být Sierra Forest konkurencí AMD Bergamo s jádry Zen 4c. Což je taky dobrej masakr, ale spotřebou nejspíš někde jinde.

Tyhle procesory jsou všechny BGAčkové = letované onboard. Takže do patice smolík. A najdete to nejspíš v motherboardech nějakého proprietary formátu. Google ukazuje na nějaké Supermicro...

Koukám Supermicro umí i AMD (A+ series) ale všude samý EPYC = stovky Wattů. Jinak ECC a větší počty jader by uměl od AMD taky Threadripper, což je taková workstation řada mezi Ryzenem a EPYCem. Obecně s AMD nemám zkušenosti, možná někdo poradí. Ve srovnání AMD/Intel mám stále ještě pocit, že Intel má veřejně k dispozici podrobnější dokumentaci.

Co se týče spotřeby... vídám občas v BIOSech všelijaká nastavení, třeba taky nastavit profile spotřeby / omezení TDP. Toto hlavně u posledních generací procesorů. U předchozích generací (řekněme Haswell...Skylake) aspoň na Intelu by mělo být možno, ladit "performance profile" - buď v BIOSu nebo v OS, nebo v krajním případě snad i přímým pošťuchováním hardwaru (je to pár MSR registrů, s trochou štěstí nebudou zamčené). Osobně bych větší svobodu hledal v Linuxu, spíš než pod Windows. Pohrát si s P-states / C-states, případně nastavit natvrdo T-state. Vyladit si kompromis žravost / latence / hrubý výkon podle svého. Pokud peníze nejsou až takový problém, vzít třeba nějaký procík s větším počtem jader, a trochu ho přiškrtit směrem k nízkým taktům.

38
Hardware / Re:Jak se bezpečně zbavit telefonu?
« kdy: 06. 04. 2023, 14:20:08 »
Ony ty dnešní matlafouny nakonec pořád ještě jdou rozebrat.
Akorát bývá zadní kryt v jednom kusu s "rámečkem" a po obvodu přllepený tavným lepidlem (hot snot).
Viděl jsem pár filmečků, kde montér pofoukal telefon dokola termostatovaným fénem při demontáži, aby se rozlepil, a opět při skládání, aby se zase slepil. Teď to nedokážu najít, ale tumáte příklad jak se to rozloupne (zde bez tepla). Pokud jde o to, telefon sešrotovat, tak nepotřebujete fén s termostatem, stačí neregulovaná opalovací pistole nebo plynová letlampa nebo hořák na sporáku nebo tak něco. Nebo naříznout rámeček na dvou-čtyřech místech napříč pilkou na železo, aby prdnul a po obvodu povolil.
Jak jste jednou uvnitř, baterku už vyloupnete, a pak jde o to, najít hlavní plošák.
Pokud tam budou k nalezení jednotliví švábi, hledal bych flash ROMky. Pokud není jasné, co z toho je hlavní NAND flashka, tak bych prostě kladivem proti tvrdé podložce praštil do každého většího švába. Případně by se to dalo nějak ohřát a velké šváby z toho oloupat...

39
Sítě / Re:Blokování spojení
« kdy: 05. 04. 2023, 23:05:14 »
Za druhé, o žádném přihlašování jménem a heslem vůbec nebyla řeč
Ajo, máte pravdu! :-O To mám z toho, že po nocích klábosím ve fórech.

Takže ohledně rate-limitu na pokusy o spojení per zdrojová IP adresa jsem taky něco našel: 1, 2. Jinak nějaké příklady na tohle zadání si pamatuju z nějakého dávného IPtables-howto.

40
Sítě / Re:Blokování spojení
« kdy: 05. 04. 2023, 22:02:12 »
Existuje, jmenuje se to fail2ban, funguje to na základě monitorování logů (takže budete potřebovat ty pokusy zapisovat do logu), a často to má větší režii, než odmítat ta spojení v cílové aplikaci.
...tady bych si dovolil vlažně polemizovat, že pokud sama aplikace neumí "třikrát a dost", ale každému příchozímu si řekne o login a heslo, tak je fai2ban přínosem v rovině bezpečnosti. Omezí hádání hesel hrubou silou. Že sám představuje nějakou zátěž na systém, o tom žádná.

41
Sítě / Re:LTE modem E3372h - uvedení do původního stavu
« kdy: 04. 04. 2023, 15:47:44 »
ten hardware je zajímavej s tím sim slotem ... takže vlastně karta je reálně s USB 2.0 rozhraním a k tomu přes nějaký piny SIM karta ... kladu si otázku, jestli by se to kamarádilo třeba s kartou, co je v mikrotiku "RBLHGR&R11e-LTE6" (? ;))

Přesně tak. V MiniPCI-e slotu tahle generace LTE karet využívá linky USB 2.0 a pár dalších signálů k SIM kartě.

Co je zač R11e-LTE6: těžko říct. O objednacím kódu R11e-4G lze dohledat, že má čipset Altair = poněkud obskurní.  Co má varianta LTE6 jsem nikde nedohledal. A myslím si, že třeba ATI3 by stejně mnoho neřekl (cca "mikrotik").

Konkrétně Quectel EC25E je můj oblíbený modem, s kompletní sadou rozhraní na USB, se kterými je použitelný pod Windows i pod Linuxem. Čipset je Qualcomm, podobně jako u některých modelů Huawei, Sierra, Telit... společný čipset ale neznamená shodné AT příkazy. Společný je jenom nějaký základ (Hayes a staré 3GPP). Trochu mi kazí radost, že EC25E tuším neumí LTE v bandu 28 (700 MHz) a samozřejmě neumí 5G (ale to bych mu nezazlíval).

O fous modernější modemy ve slotu M.2, např. Quectel EM05, už umí i LTE band 28. Stále na USB 2.0. A stále bez podpory 5G.

Ještě modernější generace (aktuální nastupující) podporuje 5G. Např. Quectel RM500 series. Umí v M.2 slotu využít USB3 nebo PCI-e.

U Quectelu bacha na EC200 (MiniPCI-e). Podle mého nemá na USB rozhraní typu "virtuální Ethernet" (WWAN/MBN/QMI), které by fungovalo pod Windows. Pod linuxem funguje standardní CDC-ECM (to E není překlep).

42
Na VLANách v principu nic složitého není. Přihřeju si polívku, tentokrát s křížkem po funuse - ohledně základních principů VLAN jsem svého času cosi sepsal...

Překvapuje mě informace, že na Ubiquiti VLAN 1 = "tento provoz není tagovaný".

Ve standardním 802.1Q platí, že VID=0 => tento paket nepatří do tagované VLAN, tag má jenom kvůli 802.1p prioritě. S tímto paketem zacházejte, jakoby byl untagged.

VLAN 1 je tradičně "default VLAN". Ve factory default settings v ní má switch managementové IP rozhraní a všechny vnější porty (untagged). Lze ji třeba ponechat jako interní/privátní síť - pokud Vám nevadí, že je ve vnitřní síti vidět management síťových prvků. Nebo si ji nechte fakt jenom na management, a porty pro užovky v LAN zavřete do jiné, dedicated VLAN. A guestům každopádně další, jejich vlastní VLAN.

Provozovat na trunkových portech mix tagovaných VLAN spolu s netagovanou default VLAN... u některých výrobců lze, v obecném Linuxu to asi taky lze, ale přide mi to trochu trapné... Je mi příjemná abstrakce, že jak jednou je nějaký port na switchi "vlan trunk", tak tam untagged paket nechci vidět (s výjimkou režijních protokolů L2 sítě, které nejsou per VLAN). Třeba IEEE1588=PTP se dřív pouštělo po trunku untagged nebo v default VLAN (a byla možná pouze jedna instance), v novějších switchích už může fungovat per VLAN (více instancí zároveň). S tím PTP už tady ale vyloženě trollím na okraj :-)

43
Jestli je to na kraji vesnice, tak bych se třeba úplně nebál jet bez šifrování... obecně jako lepší variantu vidím, udělat na tom GUEST essidu normálně WPA2 šifru a zájemcům dávat heslo. V tom případě se klienti nemohou odposlouchávat navzájem, s výjimkou broadcastového provozu. Jako na metalickém switchi.
Na otevřené síti může kdokoli v doslechu odposlouchávat hesla, která nejdou nad end-to-end šifrováním typu SSL/SSH. Tzn. klasické FTP, POP3, HTTP apod. se odposlechnout dají.

Tzn. ty sítě mohou být i tři:
1) interní LAN
2) sousedi
3) kdokoli kdo jde okolo. Heslo si klidně vylepte na vrátka.

Vykousnout guestovský ESSID+subnet lze velmi účinně v případě, že AP je zároveň NAT routerem do divokého internetu. Pokud AP jako uplink používá vnitřní LAN, je ta guestovská síť jenom zabalená do NATu, ale její traffic jede dál skrz interní LAN směrem na upstream gateway do internetu. Jak správně píšete, v tom případě je řešením, udělat pro guesty nejen ESSID, ale taky ohraničenou VLAN.

VLAN na Mikrotiku jsem potkal jednou, na switchi CRS-112 (RouterOS). Pro mě rozmazleného Ciscem a D-Linkem to bylo na Mikrotiku trochu přes koleno (každá VLAN asi na 3 kroky), ale nakonec jsem to dal. Kdyžtak prostě tady dál rozvíjejte téma.

44
Hardware / Re:Tiskové jazyku u tiskárny
« kdy: 02. 04. 2023, 22:43:44 »
Jak je to ohledně porovnání výstupu? Kde ne největší změna pokud použiju jednotlivé tiskové jazyky?
Např. u CAD aplikaci. tlouštíka čar, měřítko atd.

Tloušťka čar a měřítko by měly vyjít přesně stejně.

Teoreticky vektorové formáty (PS, PDF, ehm HPGL) by mohly kreslit jemné detaily trochu líp, ale to zjistíte spíš pod lupou. U hloupých formátů, kde do tiskárny jde už celostránková bitmapa v pevném rozlišení, máte šanci ovlivnit rozlišení té bitmapy. Takže třeba dithering šedých tenkých čar může být znát (v hrubším rozlišení). Tuším na to bývaly i nějaké testovací obrazce.

Dnešní kancelářské lasery mívají běžně 600 dpi (= pixelů na palec) ale ty obrazové body jsou černobílé tečky = barevná hloubka 1 bit. Plochy polotónů jsou emulovány buď pravidelným ditheringem nebo chybovou difuzí (Floyd-Steinberg). Rozdíl mezi 300 a 600 dpi je u jemných čar a polotónů poměrně znát.

Poňouknut Vaším dotazem, vyrobil jsem jednoduchý vektorový testovací obrazec: hvězdu z tenkých čar, rozteč 5 stupňů. Matici obrazců na A4 přikládám. V matici vodorovně tloušťka čáry 0.1/0.2/0.3 mm, svisle sytost 100/75/50/25% (černá a odstíny šedé). Zkusil jsem to na své m227 vytisknout ve třech variantách:

Výsledky jsem skenoval opět v m227 v rozlišení 1200 dpi (víc skener neumí).
Tady k příspěvku mám omezení na 4 přílohy - přikládám zipnutý původní obrazec v obou formátech a tři zajímavé výřezy ze skenů. Vynechávám nudné "bezchybné" obrazce typu 100% sytost v 600dpi nebo PS. Výše v textu jsou odkazy na kompletní A4 skeny - ve formátu PNG (= bezeztrátové), výsledné soubory mají každý asi 15 MB (surová data asi 150 MB každý obrázek).

Ve variantě "PCL5 v pevném rozlišení" bylo zajímavé, že nehrálo roli, zda v ovladači řeknu "poslat grafiku jako vektory" vs "jako bitmapy" - dithering polotónů vyšel v obojím případě přesně stejný. Zato se ve variantě PCL5 mírně lišilo moiré podle toho, zda jsem tiskl z PDF (Acrobat Reader) nebo přímo z Inkscapu (backend "vector"). Přiložené skeny jsou z PDF/Acrobatu.

Ve variantě PostScript při sytosti nižší než 100% je zajímavý "světlejší střed hvězdy" - patrně nějaké moiré ditheringu na mnoha překrytých čárách. Nedomyšlenost renderovacího enginu v tiskárně. Toto se chovalo shodně při tisku z Acrobat Readeru a z Inkscapu.

V některých ovladačích býval ke konfiguraci algoritmus ditheringu bitmap. V aktuálních ovladačích HP Universal Printing tato volba není. Takže Floyd-Steinberga leda v Irfanu v rozlišení tiskárny a výstup tisknout jako bitmapu 1bpp v měřítku 1:1. Anebo fotku prostě poslat embednutou v PostScriptu, ať si s ní tiskárna poradí. Tisk bitmap/fotek jsem netestoval.

45
Vývoj / Re:Jazyk pro ML
« kdy: 02. 04. 2023, 15:55:53 »
Strojove uceni ma smysl jen na GPU nebo jinem specializovanem HW. Nema smysl se pokouset o vlastni implementaci ML algoritmu na CPU. 99% usivatelskeho ekosystemu a tutorialu je v Pythonu. Pokud Vam nekdo radi C++ nebo Go "protoze je to rychlejsi", nema poneti, o cem mluvi.

Taktak. Třeba když vlezu na TensorFlow.org a zajímá mě reference API, dostanu se by default na variantu pro Python. Dokumentace pro C++ je hned vedle, v sousedním tabu, ale prostě první na ráně je Python. O tutorialech nemluvě.

Že ty knihovny co dělají rozhraní proti CUDA back-endu jsou kdesi vespod napsané nejspíš v C, to nehraje velkou roli.

A pokud by šlo o to, bavit se přes nějaké API třeba s natrénovaným GPT modelem, který provozuje nějaký dodavatel v cloudu, to je taky "někde jinde".

Snad mám jen trochu strach, zda doporučit ML jako směr studia člověku, který možná trochu začal programovat v nějakém procedurálním jazyku. Jednak z hlediska programátorských schopností, jednak třeba co do dostupnosti vhodných "námětů lákajících ke zpracování"...

Stran: 1 2 [3] 4 5 ... 76