Příspěvky

826

Hardware / Re:Ochrana proti zkratu 12V/2A

« kdy: 16. 10. 2021, 19:23:42 »

tak vypne při 4 In.

Co je to za tu jednotku In? Půvidnějsem   myslel že je to logaritmus, ale pismenko je i.
 Tipuji Nějaký proud I s označením n, něco jako normální proud.

NOMINALNI, hodnota, na kterou je ochrana navrzena. V jinem kontextu se to oznacuje (nom) nebo (typ).

827

Hardware / Re:Ochrana proti zkratu 12V/2A

« kdy: 16. 10. 2021, 19:22:34 »

protoze plati P=I*I*R

A víš, jak je tento vzorec odvozený?
Je to z ohmova zákona, protože U = I x R
Tedy základní vzorec P = U x I vezmu, provedu substituci (nahradím U) a získám P = (I x R) x I
Možná ti to z toho není zřejmé, ale správně poukazuješ na to, že mám pravdu.
Proto se ti jistič na 230V nebude na 12V nebo 0.5V při proudu 100A nebude chovat stejně.

Jak uz bylo zmineno v nekterem z predchozich komentaru, jistic je zapojen v SERII a o existenci provozniho napeti nema nejmensi tuseni. To provozni napeti o kterem se bavis tady je 230V nebo 12V, je napeti mezi svorkou jistice a referencni zemi - ktera ale k jistici neni pripojena.

Znova: P v tom vzorci byl vykon potrebny na aktivaci rozepnuti jistice - a ten souvisi jen s proudem skrz jistic na druhou, krat vnitrni odpor jistice. Takove to U=I.R je ubytek napeti na jistici, a o tuto hodnotu je ponizeno napajeci napeti spotrebice za jisticem.

Doporucuji si nejaky jistic promerit, at mas hrubou predstavu o radech, ve kterych se veskere parametry nachazi.

828

Hardware / Re:Ochrana proti zkratu 12V/2A

« kdy: 16. 10. 2021, 13:24:12 »

Sila je zavisla len na prude ktory vodicom elektromagnetu preteka.

Do výkonného procesoru (TDP 95W) teče 100A - klidně i víc. Do magnetu na smeťáku (a kabely jsou silné jako můj prst), takového toho na zdvihání aut, teče taky 100A. Takže když k CPU přidám cívku, budu tím moc zvedat auta?  ...když myslíš.

V pripade pojistky, procesoru i magnetu je akcnim elementem neco co ma svuj vlastni odpor ktery je rekneme konstantni (zjednodusme to, a ignorujme kapacitni, induktivni a dynamicke vlastnosti).

Proto staci, aby vnejsim zasahem bylo zaruceno aby skrze tento "blackbox" pretekal urcity proud - a ukon, ktery vyzaduje definovanou energii bude pak uspesne proveden.

A ted si uvedom, ze onen odpor u vsech trech prikladu je drasticky jinej - takze 1A ve vysledku vykona zcela jinou praci.

(vidis ze jsem napeti ani nemusel zminit, aby veci fungovali ... protoze plati P=I*I*R)

829

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 15. 10. 2021, 22:45:23 »

Toz nevim, zda absolutni ignorace architektury bude fungovat i v tomto pripade, kdyz vidim programatory co netusi jak pocitac funguje tak to je velky spatny

830

Studium a uplatnění / Re:Pokračovať v štúdiu po bc. alebo ísť pracovať?

« kdy: 15. 10. 2021, 14:16:13 »

A jak tu nekdo psal ze Bc vypovida o tom ze nedokaze ten clovek nic dokoncit, tak ja si myslim ze dulezitejsi vlastnost je se na neco vykaslat

Jo, po někom takovém Google nebo NASA hned skočí

Haha, tak ano - Google je expert na sluzby s kratkym polocasem rozpadu. A NASA uz taky outsourcuje jak o zivot

831

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 15. 10. 2021, 11:41:32 »

...je potřeba, aby FPGA ten 32MB "balík" vidělo naráz? Jako že data uvnitř toho bloku spolu souvisí a jsou potřeba ke zpracování? Protože pro efektivní PCI-e DMA přenos by stačil mnohem menší blok, střelím od boku třeba 1 kB...

BTW OT: ten expanzní konektor na kartách, to je FMC bus? Jako tady? Jasně, pro Vaše potřeby irelevantní...

PCIe je efektivni uz pri naplneni Max Payload - tj. 128B pri desktop, 256B pri server zeleze (nyni to ma amd i v desktopu).

Ale z pohledu OS a aplikace, je optimalni velikost bloku "nekonecna" (tedy prakticky omnoho vyssi nez hw optimum) - protoze je nutno provest preklad na fyzicke adresy, zajistit ze se data neodswapuji a jine pausalni ukony v OS, per blok. Delat to po vlastni ose prinese jiste vykon, ale pro laiky je snazsi pouzit neco klikaciho a hotoveho, i za ztratu deset - dvacet procent vykonu.

Jo, vypada to jako FMC, ale neni jiste ktera varianta (LPC,HPC) a kolik a jak rychlych seriovych linek to ma.

832

Windows a jiné systémy / Re:Apple M1 - unzip = kernel panic

« kdy: 15. 10. 2021, 00:05:37 »

Hm, když výstup pošlu do /dev/null, tak to celé proběhne bez pádu, takže na RAMku to nevypadá.

Jestli to zalezi na power/thermals, tak bych to zkusil porovnat mezi napajenim z baterky vs AC adapter.. minimalne to udela rozdil v power profile (jestli jsi to do toho nerejpal uz..)

Ale kdyby to melo padat pri vetsi zatezi, tak bys to videl i jinde, nez jen u unzipu. Apropo.. komprese zipem vzdy je ok?

833

Hardware / Re:Ochrana proti zkratu 12V/2A

« kdy: 14. 10. 2021, 23:52:20 »

Na tyhle maly veci jsem v poslednim zarizeni pouzil eFuse od TI. Jde to pomerne dobre konfigurovat co se tyce limitu casu, opakovani a tak.. ale chce to mit zdroj ktery dokaze dodat alespon chvili ten nadlimitni proud, aby to davalo smysl. Jako cenove to je nekde jinde.. ale je to solid-state reseni, ktere necmoudi a je resetovatelne (nevolatilni.. takze staci vypnout/zapnout :)

834

Studium a uplatnění / Re:Pokračovať v štúdiu po bc. alebo ísť pracovať?

« kdy: 14. 10. 2021, 23:48:25 »

Jsem asi stara skola, ale lidi s Bc only pusobi jako predcasny vystrik. Je to celkem spolehlivy indikator toho, ze ten clovek nema naturu cokoliv dokoncit - a bude to jenom dalsi sberatel zarezu na linkedin. Takove tu nechceme

835

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 14. 10. 2021, 19:13:33 »

Ke vsemu existuji generatory od vyrobcu, pripadne 3rd party IP jadra. Neni to uber-optimalni, ale pokud nejsi narocny tak to staci.

Vetsina "API" je asynchronni, neco tam cpes jednim koncem a o nahodnou casovou prodlevu ti pada vysledek druhym koncem. Pak zalezi zda dane jadro umi zpracovat vicero veci naraz, nebo ne. Vetsinou ano.

Se podivej do dokumentace prece, ma to jen par tisic stran k tomu co potrebujes :-)

836

Vývoj / Re:FPGA s Verilog na PCIe kartě

« kdy: 14. 10. 2021, 16:09:39 »

Ve FPGA nebyva 32MiB pameti (ram), takze to nemas vlatne KAM prenest. A pokud to bude externi DDR, tak to bejva 32bit, nekdy 64... jako single channel ddr3/ddr4. PC je na tom s pameti lepe :-)

837

Windows a jiné systémy / Re:Apple M1 - unzip = kernel panic

« kdy: 13. 10. 2021, 22:26:41 »

Vzal bych onen soubor do nejake vykladni skrine applistu, zda bys to mohl zkusit na jinem kusu M1.

Jestli to padne, tak mas minimalne PoC exploit na nejaky error. V tom pripade bych doporucoval ten archiv projet nejakym zip analyzerem, zda neobsahuje bitovou chybu (ktera by treba rozhodila hw rozbalovac v M1). Jestli je archiv opravdu neposkozeny, tak jsi nasel zajimavy bug

838

Server / Re:Jak co nejjednodušeji udělat záložní MX server?

« kdy: 12. 10. 2021, 04:22:22 »

Pokud vám z nějakých analýz vyšla potřeba mít MX server zálohovaný, zvažte i méně typický scénář. Dva servery se shodnou MX prioritou, ve shodné konfiguraci. Krom jiného tím i vzniká prostor pro snazší nasazení nějaké konfigurační automatizace (ansible apod.). No a díky shodným MX prioritám se ham i spam provoz tak nějak přirozeně rozloží mezi oba servery a různé statistické nástroje antispamu budou stále přibližně stejně naučeny na aktuální mailový provoz. Považuji to za lepší, než aby záložní server v případě nějakého výpadku převzal provoz bez naučeného antispamu, nebo naučeného jen na spam.

To je zajímavá úvaha, ale pokud jsou dané servery „koncové“, jak zajistím integritu e-mailových schránek? Vždyť budu mít půlku pošty na jednom a druhou půlku na druhém... Nebo mi něco uniká?

Muzete mit prece sdilene uloziste - na tretim pocitaci, nebo nejakou variantu distributed block device a clusterovaciho FS :) Prakticke nasazeni spis vyzaduje 3 nody, kde muze jeden byt restartovan / umrit, protoze se snaz resi kdo ma pravdu (dva prehlasuji jednoho).

Osobne jsem nemel potrebu resit zalozni MX - ze zkusenosti vim, ze klasicka posta se zkousi dorucit cca 2 dny (pak se odesilajici server rozhodne to vzdat a prijde notifikace o nedorucitelnosti), takze pokud jsem schopen resit problemy okamzite (at uz sw update fail.. protoze mam schranky podle DB, nebo stavkujici hw.. ), tak se nic nedeje.

To co se nedorucuje opakovane jsou jednak spamy, a pak ruzne automaticky generovane verifikace typu - tady mate PIN, nebo kliknete na tento odkaz (password reset). Protoze provozuji krutoprisny MX check a vlastni variaci na graylist, tak vidim ze tyhle veci se nikdy nezopakuji - nekdy nezbyva nic jineho nez whitelistovat urcite "cloudove" odesilatele, co neumi retry a pokud umi, tak to zkusi zcela jinej nod.. to pak ani nejobycejnejsi graylist nedava :)

839

Odkladiště / Re:Přívod 230 V do racku

« kdy: 11. 10. 2021, 22:06:55 »

Jen tak zbytečně tam mít DIN lištu kde bude 1x zásuvka a v ní teprve strčená ta prodlužka mi přijde jako blbost.

Me prijde blbost to montovat napevno. Mam 37U a zpod racku trci konec prodluzky do racku (nemusi byt vse za UPS), pro mensi systemy z racku trcel jen IEC napajeci kabel vedouci do UPS.

Na zdi bych pak doporucoval 2 zasuvky, v jedne budes mit rack, a v druhe prinesenej monitor pro reseni problemu, nebo vysavac pro uklid bordelu co veci v racku nasali (nejvic bordelu se me hromadu pod rackem.. jesteze ma vysoke nozicky)

840

Hardware / Re:Je tento USB-C kabel v něčem lepší(jiný)?

« kdy: 11. 10. 2021, 20:05:01 »

Co se vlastní kvality kabelu tyče, je tu i závislost na způsobu provozu na dif. párech. Třeba u DP existuje training phase, kdy se analyzuje charakteristika kanálu (tj. PCB + konektory + kabel) a podle toho se nastavují korekce přenosové trasy. Pokud někdo během přenosu pohybuje s nekvalitním kabelem (otřesy, doprava,...), který potom mění např. zpoždění mezi dif. páry, útlum aj., může dojít ke ztrátě dat, což se ve video streamu projeví fatálně.

Vetsina modernich rozhrani (PCIe, DP, HDMI2, atd.) specifikuje velice volnou toleranci pro inter-pair skew - rozdil spozdeni mezi pary. Presto i u relativne prisneho DP - s toleranci jenom 2UI - to vychazi pri 2.7Gb/s na 740ps = cca 11.5cm rozdilu v delkach vedeni mezi pary.