Příspěvky

46

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 17:01:26 »

Ano, tohle je skoro přesně případ, o kterém jsem psal hned ve svém prvním komentáři. Akorát že 100.64.0.0/16 není privátní rozsah, je to rozsah určený právě pro NAT ISP, takže je to v pořádku. Ale hlavně – aby tohle fungovalo, musí ISP vedle DNATu veřejné IP adresy na vaši privátní také SNATovat adresy svých zákazníků za něco, co nebude zákaznický router považovat za adresu v síti svého WAN rozhraní, ale za něco z internetu, co má poslat zpátky na bránu.

Moment, tohle je nějak divné. Zákaznický router ma defaultu ven, dovnitř k zákošovi třeba jen 192.168.1.0/24, a obvykle ta síť providera nebejvá plochá, ale spíš nějaká kombinace OSPF/iBGP (neboli nexthop pro CE router je anténa na střeše, ta má zase jako nexthop nějakej PE na kostele. Aby se to doroutovalo zpátky, vůbec netřeba aby to SNATovalo za internet, stačí cokoli co se dokáže vrátit (i když za veřejku by to bylo lepší, dokážu si představit validní argumenty, proč to někdo dovnitř vlastní sítě neNATuje za veřejku, ale za privátku/nějaký privátní subnet)

BTW to jestli 100.64/10 je privátní nebo CGNAT rozsah je v našem případě irelevantní (a ve skutečnosti můj provider používá kus desítek, jen jsem nechtěl dávat přesnou identifikaci podle které by se poznal když ho tu "pomlouvám"), oboje jsou adresy, které nemají ve veřejném internetu co dělat, ale v případě připojení k síti providera na nich není nic špatného, pokud ofc nedojde ke konfliktu s adresami v LANce (i to se dá řešit, ale nekomplikujme to, tazatel kdyby to uměl řešit by se v první řadě vůbec nemusel ptát.).

Které se na WAN zákaznického routeru prostě objevovat nesmí, protože tak jsou privátní IP adresy nadefinované – mohou se používat pouze pro komunikaci uvnitř privátní sítě.

Fajn, a co s tím chcete dělat? Jednak je to slovíčkaření (veřejný internet vs. pakety od zákošů s privátními adresy providera chodí z privátního rozsahu providera....), druhá věc je čistě praktická - buď můžete být pokročilý zákazník, který když je ze strany zákoše neřešitelný problém, tak se domluvíte přímo s technikem, nebo můžete být věrozvěst-puritán, jinými slovy problémista, což stejně k absenci neveřejných adres na WANu nepovede (i malý ISP je podnikatelský subjekt, jehož smyslem existence je dle OZ tvorba zisku a kvůli dvoum lidem z několika tisíc síť předělávat nebude ani riskovat výpadek při konfigurační chybě...), zato třeba při nastavení reverze se z "kolega Vám to nastaví jak se vrátí z oběda" stane "Litujeme, ale tuto službu domácnostem neposkytujeme, pokud chcete provozovat mailserver, máme zde ceník pro business zákazníky", případně z "hmm, když Vám to občas v noci zakolísá, tak k Vám skočím a dáme tam nové pojítko v licencovaném pásmu" se stane "Podle měření Vaše připojení odpovídá smlouvě" apod.
Případně stížnostmi donutíte providera tu službu (veřejná IP) maximálně zrušit úplně, což je úplně nejhorší varianta a pár lidí z okolí Vám za to rozhodně nepoděkuje (ano, vždycky můžete zavolat na Cetin, že máte zájem o xDSL, velmi rádi Vám nacení výkop, pár metrů přes silnici to vychází kolem 150k)

47

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 15. 01. 2023, 04:14:14 »

Pokud si tazatel zablokuje přístup z neveřejných IP adres, pak ze všech, tj. i těch z vnitřní sítě ISP, což je samozřejmě špatně a není k tomu vůbec žádný důvod. A popravdě ani neznám nikoho, kdo by něco takového dělal.

Není na tom vůbec nic špatně. Dělá se to proto, aby se do vnitřní sítě nedostal provoz, který tam nemá co dělat a může jít třeba o podvržené pakety.

Ano, dělá se to na ingresu z Internetu, kde opravdu pakety z rfc1918 nemají co dělat. Nicméně tazatelem popsaný případ se ingresu z internetu moc nepodobá, spíš nějaká forma přístupu do privátní sítě ISP, a zcela zřejmé a nejjednodušší řešení je samozřejmě blokovat pouze lokální adresy, které jsou použité v jeho místní síti, a ze všech ostatních (veřejnou) službu povolit.
Optimálně podle možností routeru nějakým antispoofem, rp-filtrem apod., vypisovat do filtru interní sítě ručně je cestou do pekla a současně časovanou bombou.

O tom, že to má lokální provider zprasené by se dalo dlouze diskutovat, dost často (k jednomu takovému providerovi jsem připojený taky) to historicky vypadá tak, že nějak udělá (samozřejmě na privátkách) natovanou síť pro vesnici dvě tři, pak se mu tam objeví zákazník šťoural který chce veřejku, tak mu jí tak nějak dobastlí - v mém případě 1:1 NAT na vstupu na privátku, která na mě reálně kouká z antény. Kvůli těm pár jednotkám zákošů se mu nevyplatí to celé předělávat a u nich zase ví, že nejsou překvapení že prostě občas jim kromě z veřejek přijde něco i z 100.64/16. Jak se říká, za ty prachy to jedno leftid navíc v ipsec.conf člověk přežije ;-)

48

Distribuce / Re:Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 19. 12. 2022, 12:01:06 »

A použít přímo tu all-in-one binárku https://github.com/xinntao/Real-ESRGAN#portable-executable-files-ncnn jste zkoušel?

Dobrý hint, binárka naprosto v pohodě (v rámci možností, nemá face_enhance, každopádně vše načítá a zpracovává - nVidia, cuda a okolo jsou mimo vinu).
BTW na Ubuntu 22.04 stejný problém, tam někde něco chybí, až na to, že to žádný error nepíše. Ještě tomu dám večer čas s strace.

49

Distribuce / Re:Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 18. 12. 2022, 21:31:58 »

A jinak AI lidé typicky používají Ubuntu, ale já jsem všude nasazoval Debian a normálně to funguje.

Díky, testnu to Ubu. Jako s cuda problém nemám, ta se inicializuje i počítá dobře na první dobrou, ale s tím Pythonem a jeho závislostmi zápasím fest. + s tím, že máloco vůbec napíše, co se tomu vlastně nelíbí :-(

50

Distribuce / Vhodná distribuce pro hrátky s AI (Real-ESRGAN)

« kdy: 18. 12. 2022, 11:44:49 »

Zdravíčko vespolek,
Po třech dnech částečných neúspěchů přicházím s prosíkem o vynadání do lam a radu, jak to dělat správně.

Začal jsem si hrát s $SUBJ - https://github.com/xinntao/Real-ESRGAN . To, že to nejde na CPU jsem zjistil poměrně rychle, vyřešil jsem to přidáním 250GB SSD do herního kompu, kde mám nVidii 1650, nainstaloval čistý Debian 11, a začal si hrát, a narážím na jeden problém za druhým.
Nainstalovat cuda nebyl problém, pak jsem postupoval přesně podle zadání - Python, Miniconda, Pytorch, git clone ... podle postupu, vše OK.
Tak se těším, že pustím podle návodu, a dostavilo se dependency hell v Pythoním provedení, změna API v TorchVision 0.13., pak bylo potřeba ještě opravit načítání monochromu. To jsem po složitém kachnění nakonec odignoroval (a pak i opravil), ale stejně jsem se dostal k tomu, že polovina "upscalnutých" obrázků byla černých.

Postupně jsem prošel několika reinstalacemi, různými downgrady PyTorch, Pythona i OpenCV, pak už i komplet reinstallem, downgrade na Debian 10 (Python 3.7), pokus na Slackware 15 - v jedné konkrétní konfiguraci s dowgradnutým TorchVision mi to fungovalo na všechny vzorové obrázky, ale už jsem nedokázal zreplikovat, jak se k ní dostat. A když jsem v ní zkusil síť trénovat, tak stejně se to vyhroutilo.

Co se týče černých obrázků, došel jsem až na opencv - Obrázek se na cv2.imread() načetl správně (byly vidět v print(img) nenulové pixely i rozměr), až na to, že na cv2.imshow(img) to opět ukázalo černé okno. Dokachněno že v opencv 4.3.xxx byla podobná chyba, tak jsem zkoušel několik různých verzí, bez jakéhokoli úspěchu, všude černo.

Tak bych se rád zeptal - poradíte linuxovou distribuci, na které Vám to funguje na první dobrou? Případně setkali jste se s podobnými chybami a podařilo se vám je nějak překonat?

51

Vývoj / Re:Go - alternativa atomics pre prilezitostne zmeny?

« kdy: 14. 12. 2022, 20:58:42 »

Třeba x86 nemá ani instrukce pro atomické čtení/zápis

LOCK XCHG,
LOCK CMPXCHG
První měl už 8086 blahé paměti.

52

Vývoj / Re:Srovnání algoritmů na prvočísla

« kdy: 07. 12. 2022, 01:21:06 »

A jde o časouvou a ne pamět. Nárocnost

Můžu se zeptat, co je opravdu cílem cvičení? Obvykle v reálu jde o tradeoff mezi výpočtem a pamětí. Přesněji - co to je "velké vstupní n"? Protože mám pocit, že v tom máte zmatek a že ve skutečnosti se bavíte o nízkých desítkách bitů maximálně. (a pak nemá smysl mluvit o asymptotách). Pokud jde o velká čísla (u bezpečných šifer se bavíme řádově o kilobitech, pokud prvočíslo použijete na vytvoření eliptické křivky, tak ve stovkách bitů), pak vřele doporučuji pročíst zde https://en.wikipedia.org/wiki/Primality_test#Probabilistic_tests a optimálně ještě od Bruce Schneiera knížku Applied Cryptography.

Navíc ale ono taky záleží jaká operace, třeba násobení n-bitových čísel znamená n * (rotace + sčítání), takže tam pak máme nějaké ln(x) ke složitosti navíc.

Ktomu doplňme, že i na paměti záleží. Hustota prvočísel je x/ln(x). To znamená, že pro tabulku 64-bitových prvočísel (potřebných k faktorizaci 128bit čísel) potřebujete cca 3ExaByte, což není málo ;-)

Pokud jde o známá prvočísla, pak existuje rovnice, která s konstantní (relativně malou)

nemáte prosím odkaz? Připadá mi to příliš dobré, aby to byla (obecně) pravda (aneb, proč se třeba při genrsa používají probability testy a ne ta rovnice), tak by mě zajímalo, o co jde a jaká to má ty "ale".

53

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 30. 11. 2022, 18:53:08 »

Arduino vám klidně přeloží i něco jako tohle:
...

Tak ono to staci napsat takhle a jde to i po bitech (prelozi se to na instrukce SBI a CBI, az na rezii loopu 4MHz), to same zjevne dela i WRITE z fastio. Navic volat to takhle v loop() je nestastne, nejen kvuli call a ret (to jsme na 2MHz), i kvuli  tomu ifu (dalsi 4 cykly, takze nesymetrickych 1,3MHz). Ale to uz se šťourame v detailech, podstatnejsi je ze z Arduino knihovnama to dá na nějakých 160kHz.
Navíc je fakt hloupé, že v referenci od toho digitalWrite vůbec není v notes and warnings poznámka, že je nešťastně pomalé a pro rychlejší přístup je třeba použít přímý přístup, to mi vadí mnohem víc než ta samotná pomalost.

Kód: [Vybrat]

#define nano_pin2port(pin) ( (pin)<8 ? &PORTD : (pin)<14 ? &PORTB : &PORTC )
#define nano_pin2mask(pin) ( (pin)<8 ? 1<<(pin) : (pin)<14 ? 1<<((pin)-8) : 1<<((pin)-14) )

__inline__ void nano_digital_write(int pin, int val)
{
    volatile uint8_t *out = nano_pin2port(pin);
    if (val) {
        *out |= nano_pin2mask(pin);
    } else {
        *out &= ~nano_pin2mask(pin);
    }
}

54

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 30. 11. 2022, 05:50:35 »

I to řízení IGBT lze jednoduše v Arduinu napsat - prostě použijete jen setup() a loop() a kód napíšete v čistém céčku.

Mno, cynicky poznamenám, že když na 16MHz Arduinu samotnej digitalWrite() sežere plus mínus (nedohledával jsem časování všech instrukcí, co neznám, dostalo 1 takt) 52 taktů, tak ono ani nic jiného nezbude ;-) přitom když se to napíše normálně, tak jsou to takty přesně dva, to už se něco časovat dá. Tam se spíš bojím čistě HW kvality, že jakákoli chyba čínského výrobku, když by se náhodou zasekl s jedničkou na výstupu, může být za 3f můstkem opravdu efektní.

BTW místo setup() a loop() radši vyhodit celé core.a z linkování a rovnou můžu použít standardní main().

Ostatně i viz odkaz od Jendy u Průšy - WRITE z Firmware/fastio.h je použito na 268 řádcích, digitalWrite jen 23.

55

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 28. 11. 2022, 19:19:08 »

Obcas sa desim toho, ked vidim, ze niekto si v arduine robi ovladanie kurenia, alebo projekty, kde zlyhanie moze mat fatalne nasledky.

Tak přiznávám bez mučení, tohle se týká i mě. Ale na svojí obranu musím podotknout, že maximální představitelná škoda, kterou je to hypoteticky schopné bez obsluhy napáchat, je vyplácání asi dvou kubíků vody z vodovodu přes vychlazovací smyčku, kterou ale ovládá mechanický termostatický ventil a tedy mimo dosah nespolehlivé čínské kopie.
Z čeho naopak mám (časem) strach je řídit tím IGBT na indukční pícku, to bude asi dost často barák bez proudu ;-)

Arduino (Wiring) je od začátku určeno pro umělce, kteří chtějí rozblikat/rozhýbat svoje výtvory, aniž by se při tom museli zbytečně něco učit. To neučení je naopak jeden z explicitních cílů a dodnes je to v projektu vidět,

Díky, takhle natvrdo řečeno mi to najednou zapadá do sebe a dává to smysl.

Bohužel asi je to asi dneska trend. Když jsem začínal, tak třeba k Atari bylo dost příruček (které jsme pokoutně kopírovali kde to šlo), ale třeba pro audio to začínalo vysvětlením funkce (Pokey, 4 kanály, děličky, posuvné registry) a pak popis jednotlivých registrů a pár jednoduchých příkladů.
Dnešní ekvivalent (a bohužel i to, co se učí děti) je "připoj na tyhle kolíky v DIN repráček a napiš v BASICu příkaz SOUND 100,20,5". A pochopit, co je za tím (a že zatím je něco netriviálního, s čím je potřeba počítat, počínaje spotřebou DS1820 při samplování, přes možnosti SPI/1w/I2C, jak reálně funguje vykreslování einku, že do toho serva jde PWM, že u toho ultrazvuku počítám dobu, než se vrátí echo apod.) se moc nenosí,  a když to člověka už zajímá, musí to složitě hledat.

Jako za mě jednoznačně malé bezvýznamné plus za referenci Atmelu. Zato Waveshare by zasloužilo...

56

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 28. 11. 2022, 04:19:23 »

Tak arduino jako HW ani jako libky ci IDE jsem nikdy nepouzil.. vzdy je to vlastni deska, vlastni kod a prime programovani.

Tak to chápu. Mě zatím Arduina celkem vyhovují (začínám znovu po hodně letech bastlit a už na to tak dobře nevidím, abych desky pro SMD kreslil ručně a pak to pájel pistolkou se smyčkou ze zvonkáče jako dřív, takže hotová deska docela pomůže), nakoupenou jich mám pěknou zásobu neoriginálních od Číňana tak různě za 1-2 eura a na nějakej větší podraz jsem zatím nenarazil (nepočítaje veselé historky z natáčení jako včerejší noc příjemně strávenou studiem referenčního manuálu, Arduinových knihoven a pak i assembleru, co leze z překladače ve snaze přijít na to, proč je výstup na e-Ink přes SPI nekompatibilní s použitím USART0 na debug - nakonec důvodem bylo to, že Nano získává 3.3V z FTDI, a ten eInk když překresluje, tak žere docela velké špičky, takže to celé šlo do resetu...), až na to, že jsem tak trochu nečekal, že doba pokročila a neoptimální jsou už knihovny na osmibity, no ;-)
Ale OK, beru to, že nejsem až tak divnej a tu obsluhu si napíšu vlastní.

BTW jak to tak čtu, je tu vlastně něco sehnatelného mezi Atmelem a RPi Zero, kde se dá snadno začít si hrát? Ta malina je třeba príma třeba na časosběrnou kameru, ale na malou meteostaničku mi přijde jako kanón na vrabce (a tam ani těch 200mA spotřeby v klidu moc nepotěší). Do myčky nebo ke kotli bude Arduino asi v pohodě, ale už třeba s tím einkem je dost trouble, když se nevejde do paměti ani videoramka, které jsou potřeba navíc dvě (ne, že by to nešlo to dorenderovávat za běhu, ale je to pakárna).

57

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 26. 11. 2022, 06:22:13 »

Ja na XMEGA resil podobnou obskurnost, kde byl soubeh preruseni a potreba atomickeho cteni 5B (dva 16bit kaskadovane pocitadla a jeste bajt ze sw pocitadla), s tim ze se externi hodiny do pocitadla nesmi zastavit. Nakonec to dopadlo tak, ze sampluji 2x a hlidam monotonnost, pokud je tam vada, tak znova. Tj v bodu preteceni (na kterekoliv urovni kaskady) vznika jitter (nelze nikdy ziskat otisk ktery by byl na hrane).

Tak koukám, že těch vtipností je tam víc. Já tu honím každý takt, pak si chci dodělat výstup na displej, tak koukám, jak se inicializuje SPI (aneb nastavit MOSI a SCK na out) až jsem radší kouknul do přeloženého assembleru a jsem zděšen - to je fakt u Arduina normální, že mapování čísla PINu na port a bit (digitalPinTo*()) nejsou dělané přes nějakou magii v hlavičkách, kterou kompiler v nejběžnějším případě port# konstanta odoptimalizuje pryč, ale přes lookup tabulky v programové raměti? :-(
No jdu si dát radši panáka, a začínám mít čím dál větší úctu ke každému, kdo se tímhle musí živit....

58

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 25. 11. 2022, 10:00:55 »

hmm vypadla mi tam negace, a editnout to nejde

59

Vývoj / Re:Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 25. 11. 2022, 09:51:43 »

Jen u té vaší metody cli() sei() musíte mít jistotu,

Což u vlastního programu mám (navíc cli sei jsou 2 takty, mov r,r cli mov r,r takty tři). Ale tam ten dotaz nesměřoval, to o co se snažím je se pokud možno zákazu interruptu vyhnout úplně.

Příklad jak to dělá Arduino funkce millis (což je v podstatě tazatelův případ -- běží interrupt co každou 1ms inkrementuje čítač)

Jasný, u timeru je to celkem snadné (a stejně, konkrétně ten bych řešil radši nějak takhle, což za předpokladu, že se během 255 milisekund dostane alespoň na 10 cyklů času pro hlavní program bude fungovat)

Kód: [Vybrat]

unsigned int8_t tm_lo,tm_hi;

do {
    tm_lo = timerms_low;
    tm_hi = timerms_high;
} while (tm_lo != timerms_low);

což sice dá o jeden tik navíc, ale odpadne tam 5 cyklů ze 7mi se zakázaným interruptem.

Ale zatím mi pro obecné čtení () nejlepčí přijde konstrukce stylu

Kód: [Vybrat]

volatile int8_t data_valid;
volatile int nejaka_data;
// interrupt
nejaka_data++;
data_valid =0;

// hlavni program
int8_t mask = 1 << thread_id;
int data;
....
do {
    data_valid = mask;
    data = nejaka_data;
} while (data_valid & mask);
[/quote]
to že se to znovunačte i v případě, že mezitím dojde k běhu jiného threadu a ten bude něco číst asi vadit nebude. Jen holt jsem tak trochu doufal, že tam je něco jako LD HL,(mem) jako u Z80, které jsem si nevšiml, a která by pomohla docela hodně. :(

60

Vývoj / Atmel ATmega328 (a další z rodiny) a atomické čtení

« kdy: 24. 11. 2022, 17:34:54 »

Zdravím, rád bych se zeptal - je na Arduinu nějaká lepší možnost než zákaz interruptů, jak atomicky přečíst int16_t popř int32_t?
Konkrétní příklad

Kód: [Vybrat]

volatile int msec;

/* interrupt rutina */
msec++; if (msec > 999) msec = 0;

/* main loop */
while (1) {
    ledka(OFF);
    while (msec < 900) ;      // <---- nekonzistence
    ledka(ON);
    while (msec >= 900) ;
    Serial.printf("je cas %i\n", msec);
}

Tenhle fragment zobrazuje casy 0 0 0 768 0 0 0 768 0 768 0.
Důvod je nasnadě, prvně se načítá low byte, pak high, a když se doprostřed trefí interrupt, který (už načtený) lo změní z 255 na 0, ale ještě nenačtený high naincrementuje z 2 na 3, tak v podmínce se porovnává 1023 < 900 a projde to dál.
OK, ale co s tím? jedna možnost je samozřejmě to obalit nějakým

Kód: [Vybrat]

int my_msec;
cli();
my_msec = msec;
sei();

To samozřejmě fungovat bude, jen se mi to moc nelíbí, reálně chci používat interrupty v množství nemalém (na druhou stranu ty 2 takty navíc asi moc nebolí), ale přecejen, není nějaké čistší řešení? Konkrétně u timeru by se to ošklivě dalo řešit tak, že si ten low byte přečtu znova a porovnám, u složitějších věcí nějakým bytem navíc, kde se nastaví dirty apod.
Ale kam směřuju otázkou - neexistuje něco snadnějšího? Koukal jsem na instrukční set a nic použitelného jako load dvou registrů neobjevil, ale je možné, že jsem slepej/blbej/oboje ;-)

P.S. To výše je jenom nejjednodušší příklad na osvětlení. Že do toho while je dobré dát __asm__ __volatile__ ("sleep") vím, a že to problém omezí, ale úplně nevyřeší (když přiletí interrupt od seriáku a hned pak od timeru, tak se taky může trefit nedobře) vím taky. A že volatile v interruptu se má načíst do lokální proměnné a pak zase po inkrementaci zapsat zpět taky...