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 ... 76 77 [78] 79 80 ... 84
1156
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 07. 05. 2018, 22:51:10 »
František Ryšánek:
ta vaše krabička http://www.aaeon.com/en/p/fanless-embedded-computers-aec-6920/
Má procesor s TDP 34W. Takže já se v pohodě vlezu s procesorem s TDP 95W do nějaké pořádnější skřině.

No však jsem ji jako příklad použil záměrně a škodolibě :-) Zrovna tahle historická krabička (čest její památce) se navzdory své cihelné dimenzi hřála docela dost. Proto říkám: tak do 20W v těchto rozměrech, a ne že tu žebrovanou cihličku zavřete do stísněné skříňky.

Pořádnější skříň na 100W TDP by musel být zhruba tower s oběma sajtnami žebrovanými a kvalitním přenosem tepla z procesoru na ty sajtny. Teda pokud nechcete vnitřnosti provozovat při teplotách, které neprojdou mým testem (udržím na tom ruku a nesmrdí to). Takový tower jsem mimochodem nedávno zahlédl... taková fanless pornografie, a spíš jenom na oko. Vnitřnosti nebyly moc dobře tepelně přivázané, pokud si správně pamatuju. V podstatě namachrovaný case na normální ATX motherboard :-(

1157
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 07. 05. 2018, 13:49:33 »
@nobody(ten pravej) :
> https://fit-iot.com/web/products/airtop2/airtop2-specifications/

Ano! Palec nahoru za procesor z rubu motherboardu.
V patici? To jsem asi ještě neviděl, ale proč ne...
By mě zajímalo, jestli mají kromě CPU na chladič přivázáno i něco dalšího. Totiž nejen procesor topí.

@anonym:
> https://www.asrock.com/mb/Intel/X299E-ITXac/

Huf, to ke kus! No jestli tam mají ve VRM jenom těch 5 polymer-tantalů od Panasonicu, tak to nevidím na dlouhou životnost. To by ten VRM musel bejt *hodně* vychytanej aby skládal fáze hezky za sebou / minimalizoval střídavou složku...

Obecně:

Procesor nekonvertuje elektrický příkon na "výpočetní energii". Procesor konvertuje elektrický příkon na teplo. Chová se jako topné těleso. Něco přidají méně žravé součástky okolo, nějaké teplo vzniká ztrátami ve VRM (na motherboardu) a v napájecím zdroji. Všechno tohle teplo je třeba odvést, jinak se bude hromadit pouze v nevelké vlastní tepelné kapacitě součástek uvnitř = poroste *teplota*. Pasivní počítače se vyznačují tím, že všechny součástky uvnitř chladící skříně běží na vyšší teplotě, než je teplota skříně. Na rozdíl od větraného počítače, kde se chladící vzduch dostane i na teplosměnné plochy uvnitř.

Vemte si, že pasivní skříňka o téhle velikosti:
http://www.aaeon.com/en/p/fanless-embedded-computers-aec-6920/
uchladí důstojně cca 20W topného výkonu.
A teď si představte, jakou plochu by ta krabice musela mít, aby se pasivně uchladilo 100W+. 

Hlubší a hustší žebra při pasivním chlazení moc nepomohou. A hliník o tloušťce 5 mm účinně roznese teplo na vzdálenost třeba jenom na 10-15 cm. Takže vodník / heatpajpy nebo ještě tlustší řízek hliníku.

Čili jedna věc je venkovní plocha. Pominu prostorové uspořádání okolí = kolik je kolem místa a jaká je šance na volnou cirkulaci vzduchu. (Další věc je navázání zdrojů tepla uvnitř počítače na vnější žebrovanou skříň.) Dokud se nepodíváte dovnitř, je pravděpodobnější hypotéza, že to taiwanec navrhl blbě, nebo že mu to ve výrobě zoptimalizovali.

Osobně považuji za optimální uspořádání s procesorem na rubu desky. Obvykle v BGA pouzdru = přímo letovaný. Tímto je CPU na rubu desky nejvyšší součástkou, a není problém ho přisadit naplocho přímo na chladič. Žádný dlouhý / štíhlý / odfláknutý tepelný most.

Přímá tepelná vazba je kvalitnější a méně krkolomná i oproti scénáři, že byste standardní ITX motherboard umístili na dlouhé distance lícovou stranou k plochému chladiči, a teplo přenášeli hliníkovým (spíš měděným) "tepelně-distančním kvádrem". (I taková konstrukce je občas k vidění. Přibližně viz dvě přiložené fotky.)

Umístění CPU z rubové strany znamená, že se otočí pořadí signálů v paralelních sběrnicích, např. k DIMM paticím! oproti stavu "jak to pánbůh Intel zamýšlel". Tzn. navrhnout plošák bude o něco větší oříšek, než vzít referenční motherboard od Intelu a trochu dochutit.

Kromě CPU jsou v počítači další topné součástky. VRM bude trochu topit, i pokud se jeho účinnost přiblíží ideálním cca 95% (synchronní usměrnění). Takže nejlíp ho taky přivázat, nebo aspoň některé velké součástky (FETy, indukčnosti). Obecně pokud vezmu ATX motherboard, a třeba vodníkem mu ochladím jenom procesor, a ten procesor hodně žere, tak riskuju odpálení VRM (MOSFETy, kondenzátory) = je potřeba chladit i další věci kromě CPU. Občas třeba vidím, že se výrobce snaží chladit i SODIMM.

Problém je, že mechanická tolerance "výšky" SMD součástek nad rovinou plošáku je nenulová. Takže pokud potřebujeme o chladič opřít víc než jednu součástku, nepůjde to "kov na kov" s pouze minimální vrstvičkou pasty. Tolerance výrobci s oblibou řeší šedou ŽVEJKAČKOU. Problém je o to horší, že různé součástky jsou i jmenovitě různě vysoké. Jsou k vidění dosedací plochy stupňovitě frézované pro lepší přizpůsobení součástkám na motherboardu, nebo různě tlusté "distanční plíšky" - ale poslední slovo má vždycky žvejkačka. A pokud skutečně kromě CPU jsou přivázané i další součástky, tak jsem ještě neviděl, aby CPU měl pastu a jenom ostatní smetí okolo mělo žvejkačku = žvejkačku pak dostane i procesor! A vrstva žvejky mezi chladičem a čipem CPU je klidně půl milimetru. V lepším případě to jde napravit vyhozením žvejkačky na CPU (náhrada pastou) a upravením tloušťky /dávkování žvejkačky na ostatních součástkách, aby si to celé sedlo dohromady...

"Pokud na tom udržím ruku a nesmrdí to, tak to má šanci nějakou dobu fungovat" - dávná bastlířská hypotéza, o které se mnou dodnes v práci kolegové polemizují.
http://support.fccps.cz/download/adv/frr/teplo.pdf
Jako že jsem moc outlocitnej.

1158
Sítě / Re:Asi neobvyklá konfigurace VPN
« kdy: 01. 05. 2018, 22:46:17 »
> 12[IKE] received DELETE for ESP CHILD_SA with SPI 0df79ea0

Takže můžete zkusit zvednout na serveru debug level pro tuto oblast (neporadím jak) a stejně třeba nakonec nezjistíte, proč IPhone proti [vašemu IPsec serveru] tu security association típne vzápětí po navázání. Netvrdím že je to tenhle případ, ale moje dosavadní zkušenosti s IPsecem jsou přesně takové: různé implementace proti sobě navzájem se povedou málokdy. Jsou tu lidi, kteří IPsecem dýchají, a pro ně to třeba není takový problém. Taky tu zatím nikdo nezmínil, že IKE v2 je v tomhle lepší než "v1" apod.

Osobně mám lepší (použitelné) zkušenosti s OpenVPN. Je to jediný projekt (code base) a je sám se sebou slušně kompatibilní napříč mnoha releasy.

Pro tenhle scénář (cestující klienti na centrálu) doporučuji transport TCP (nikoli UDP), a pokud by nefungoval standardní port 1194, dá se to narafičit i na port 443 (který má o něco lepší šanci skrz firewally).

Autentikace klientů se dá navléknout pomocí PKI certifikátů, nebo pomocí loginu+hesla, nebo kombinací obojího. Z hlediska správy konfigurací klientů je nejjednodušší varianta, kdy jednotlivý klient potřebuje jenom svůj (jednotný) konfigurák, certifikát CA (pokud na server použijete self-signed certifikát) a samozřejmě login+heslo. Tzn. klient teoreticky nepotřebuje svůj vlastní certifikát. Je to méně bezpečné, ale jde to.

S OpenVPN (nebo s libtls?) se distribuuje pár skriptů zvaných "easy RSA", pomocí kterých lze generovat potřebné certifikáty. Na serveru je potřeba cerfikát a tuším soubor s "Diffie-Hellman" klíčem (nebo co to je).

Pro mě osobně asi nejnáročnější bylo zorientovat se v klíčích a certifikátech = naučit se základní chvaty s easy-RSA. Nějaké vzorové konfiguráky OpenVPN serveru a klienta mohu kdyžtak nabídnout.

Pokud by se mělo jednat o rozsáhlejší síť (větší počet mobilních zařízení) tak zvažte privátní APN. Odpadly by starosti s konfigurací a některými nectnostmi OpenVPN.

1159
Hardware / Re:Redukce mini-PCIe - USB
« kdy: 29. 04. 2018, 21:15:30 »
Wifiny do MiniPCI-e jsou takřka bez výjimky PCI-e zařízení. (Některé mají připečené taky BlueTooth rádio - to se ukáže na USB.) Takže pro Wifinu je ta redukce k ničemu.

GSM apod. modemy do MiniPCI-e jsou takřka bez výjimky USB zařízení.

V názvu produktu je jasně napsáno "with SIM 8 Pin Card Slot for WWAN/LTE Module" = má to do MiniPCI-e slotu připojený SIM slot a je to pro Wireless WAN moduly = GSM/GPRS/EDGE/WCDMA/HSPA/LTE. Totiž tyhle hračky měly původně sériový port, časem jim vypučelo USB rozhraní, nad kterým byl původně virtuální sériák, později virtuální síťovka. Postupně se objevilo několik "průmyslových de facto standardů" pro WWAN virtuální síťovky, počínaje Windows 7 už mají widle dokonce systémový "WWAN dialer" který chápe APN name a k němu login+heslo. Troufnu si odhadnout, že momentálně nejrozšířenějším standardem WWAN virtuálních síťovek je QMI od Qualcommu - protože prakticky všichni výrobci MiniPCI-e karet berou od Qualcommu čipset a základ firmwaru (hodně zapečený Linux, pokud se nepletu).

Matně si vybavuju, že jsem někde viděl webík nebo snad PPT z nějaké konference, srovnávající různá "standardizovaná" rozhraní pro práci s WWAN modemy... nedokážu to dohledat.

MiniPCI-e sloty na motherboardech taky nejsou všechny obojetné (PCI-e + USB), záleží kolik má čipset volných PCI-e a USB portů a kolik je na boardu místa (= jak velký je celý počítač). Některé sloty jsou taky mSATA-only. A některé jdou přepínat... USB 2.0 jde levně rozbočit přídavným hubem, PCI-e bridge jsou zřejmě dražší legrace.

1160
Já kdybych nebyl na Windows závislej pro některé oblasti své práce, tak mě z Linuxu nikdo nedostane. Přesně protože v Linuxu není antivirák, není v něm Windows Update, nefunguje v něm 99% malwaru.

Pod windows bych se bez antiviráku neodvážil fungovat natrvalo. Takže pak výkonný procesor, SSD a 8 GB RAM slouží vlastně základním životním funkcím :-(

1161
Server / Re:Jaký software na VPN „router“?
« kdy: 06. 04. 2018, 15:57:15 »
Pokud nejsou vysoké nároky na průchodnost, tak OpenVPN. Minimum nervů "proč to nejede, proč tahle konfigurace nefunguje". Flame war OpenVPN vs. IPSec jsem už párkrát absolvoval, argumenty pro IPSec znám.

Zdejší debata mě poňoukla, abych otestoval průchodnost mezi dvěma lokalitami. Bohužel je na jedné z nich ohavný rate-limit na 10 Mbps (symetrický) takže jsem nezměřil, kolik by to dalo samospádem. Takhle jsem pomocí FTP změřil 8 Mbps a oba routery se flákaly (quad-core BayTrail Celeron J1900 měl jedno jádro vytížené asi na 10%). Pravda je, že slýchám stesky, že OpenVPN ani to jedno jádro nevystropuje, že má bottleneck někde jinde...

OpenVPN je zřejmě jednovláknová. Pokud by byl zájem na centrále rozložit zátěž na víc jader, dá se ručně spustit dvě a více instancí a satelitní "klienty" mezi ně ručně rozhodit. Konfigurace a spouštění démona pak dá trochu práce navíc. Ale pokud byste začal kopírovat data proti centrálnímu storagi ve více streamech, možná by to zase zůstalo viset na random IOPS točivých disků.

Já třeba míval dvě instance OpenVPN kvůli redundantním uplinkům. A nad tím Quagga jela dynamický routing... Hezké to bylo, ale teď na optice u slušného ISP už redundanci nepotřebuju.

1162
Bazar / Re:HW RAID řadič PCIe 4xSATA a více
« kdy: 25. 03. 2018, 21:35:59 »
Osobně mám rád Arecu. Přijde mi že má nejkomfortnější ovládání. Čtyřportový model bude mít onboard Ethernet s lehkotonážním webovým GUI. Pokud klekne řadič, data z disků přečte libovolná mladší Areca. Podpora disků >2TB není problém snad ani u staršího EOL hardwaru (ARC11x0 series) pokud flashnete poslední firmware.
Anebo se vykašlat na HW RAID a postavit to v Linuxu třeba na MD RAIDu.

1163
Sítě / Re:Hardware pro linuxový router
« kdy: 23. 03. 2018, 09:26:45 »
Kup si neco PC like = s CPU id intelu nebo amd, a nemusis resit ani vykon ani problemy s tim jak tam to ci ono nainstalujes/prekompilujes/...

Trebas neco na bazi Intel NUC pokud to chces maly.
Nebo pokud to chcete rozumně chlazené, tak nějakou ITX desku s Atomem BayTrail a výš.

Já jsem před pár lety řešil několik takových strojů deskou GA-J1900N-D3V (BayTrail), která už je EOL. A dával jsem je buď do velkých ATX šasi (jako servery) nebo jednu do tohoto šasi Eurocase:
http://partis.cz/index.php?gid=3161
(v mém případě včetně měniče, protože deska měla ATX 24pin napájení. Tuším jsem na tom měniči preventivně nahradil elyty solid-poly provedením a přidal jsem velký zpomalený větrák.)

Momentálně vidím v tuzemských shopech GA-N3160TN - trochu dražší, ale patřičně vybavená, Braswell už není bleeding edge takže s Linuxem nebude problém. ATOM SoC má TDP=6W/SDP=4W tj. tak akorát. Všimněte si, že má vstup 12 V dutým konektorem. Tohle prakticky stačí přitlouct na zeď dvěma hřebíky :-)

Vidím v krámě taky GA-J3455N-D3H - tohle má bohužel ATX vstup napájení a nemá to MiniPCI-e ani M.2. TDP=10W (samotný ATOM) je taky trochu vyšší. Zato má přídavný SATA řadič, takže dohromady 4 porty SATA. Tohle bych volil spíš do malého serveru nebo HTPC. Kromě toho je to relativně čerstvý Apollo Lake, nevím jak by se na to tvářil Linux (asi jak které distro).

Přímo u GB vidím dále GA-IMBLAP3350. Apollo Lake, TDP=6W/SDP=4W, MiniPCI-e + M.2, napájení 12V dutým konektorem. U nás v krámech zatím není, ale jinak je to zjevně přímý nástupce GA-N3160TN. Mimochodem tyhle dvě desky mají větší počet sériových portů, z toho dva umí 232/422/485. Touhle deskou zjevně GB konkuruje zavedeným "průmyslovým" výrobcům. (Je to psina - žeby sériový port zažíval po letech útlaku renesanci? :-)

Pokud chcete, aby to sloužilo jako WiFi AP, tak bych zvážil použití OpenWRT. Je šance dostat kernel, ve kterém nesmrdí CRDA.

A je fakt, že pokud místo toho použijete nějaký TP-Link, máte šanci dostat se asi na poloviční až třetinovou spotřebu. Akorát to nebude PCčko, budete čekat na nový release OpenWRT aby podporoval čerstvou revizi HW apod. Na PCčku tyhle problémy nejspíš mít nebudete - ačkoli onboard síťovky v novém PC HW bývají taky často pěkný výdobytek :-)

1164
Windows a jiné systémy / Re:Sekání videa ve VLC a Windows 10
« kdy: 16. 03. 2018, 07:11:04 »
i7, 16 GB RAM a přídavná grafika od Nvidie? Ten noťas je docela dělo :-)

Zažil jsem pod windowsama sekání celého systému z různých důvodů. Historicky si vybavuju "Realtek fmapp.exe" (řešení: smazat), nověji "Intel WiDi UoIP service" (řešení: stopnout a zakázat), to bylo bez ohledu na velikost RAMky. Se 4 GB RAM se to stává dneska už dost běžně - systém prostě začne krutě swapovat.  Již zmiňovaný resmon většinou ukáže viníka (proč došla RAMka a disk seekuje jak vzteklej): Windows Update, Microsoft Malware Protection Engine, indexing engine, 3rd-party antivirák... Se 16 GB asi RAMka hned tak nedojde, ale tyhle věci prostě potřebujou šahat i na disk.

Jsou to jenom nápady. V tomhle případě je problém dost možná právě ve VLC. Mimochodem nějak jsem si tady nevšiml informace, co je to za kodek / datový tok / cbr vs vbr / rozlišení...

BTW myslím si správně, že u podobných hybridních konfigurací NVidia/Intel musí NVidia ještě kopírovat obsah výstupního framebufferu (ve své dedicated videoRAM) skrz PCI-e do okna v hostitelově sdílené paměti (pronajaté IGP) pro vlastní "řádkování" do vnějšího výstupního portu?

1165
Používám DVBSky T330 (jak z olmi.tv, tak výrazně levněji z německého Amazonu za 40€/~1050Kč https://www.amazon.de/dp/B072FP1TX4/ref=pe_3044161_185740101_TE_item), mám tři nastrkané do Raspberry-Pi a jediné, co jsem řešil, je USB hub, který byl Single TT (ať už to znamená cokoliv), ale co jsem ho vyměnil za Multi TT, tak to všechno šlape - na Single TT hubu se nedařila komunikace mezi Raspberry-Pi a kartami, nedařila se ani úplná inicializace. Provozuji karty jako headleass server, obsluhuje ho Tvheadend, koukám na TV jak přes Kodi na počítači i Raspberry-Pi (připojené k televizi přes HDMI), tak přes TVHClient na Androidu (tam to hraje přes VLC 3.0).

DVBSky T330 krmím z TV antény, umí jak DVB-T (i ČT HD), tak DVB-T2 (H.265). Používám ho běžně, maximálně mi spadlo Kodi při nějakém výpadku signálu, ale Raspberry-Pi server šlape jak hodinky.

Díky za tip :-) Pro zajímavost, koukám že je k tomu dálkové ovládání... ten dongle má IR přijímač někde na sobě? To je mi na headless serveru asi k ničemu, předpokládám že ta funkce prostě zůstane nevyužita a tatranky dám psovi na hraní...

1166
Windows a jiné systémy / Re:Sekání videa ve VLC a Windows 10
« kdy: 15. 03. 2018, 15:47:54 »
VLC je švýcarský armádní nůž, umí streamovat a spoustu dalších věcí a je hodně multiplatformní, ale domnívám se že druhou stranou mince je, že si dekódování mnoha kodeků (kompresních formátů) řeší interně softwarově. Sice třeba umí poměrně nové generace SSE/AVX, ale prostě to jede často na CPU u kodeku, který jiný přehrávač levou zadní offloadne do hardwaru grafiky. V tu chvíli je ve výhodě ten "jiný" přehrávač, zejména na trochu normálním CPU (myslím na slabším než přehnaně neskromném).

Tato moje předestřená hypotéza může být v konkrétním případě zcela mimo a pravdu má předřečník, že by možná stačilo cosi poladit (bufferování). Pro lepší informovanost bych doporučil spustit "resmon.exe" a chvíli sledovat spotřebu paměti, CPU a disk IO. Resmon umí ukázat i procesy, které hodně žerou. (Popravdě v desítkách toho dost ukáže i standardní správce procesů. Případně existuje "process explorer" od SysInternals.)

1167
K dotazu ohledně HD videa chci jenom příkývnout, že RTL2832U sice neumí přijímat multiplexy modulované DVB-T2, ale pokud naladím mux RS7 (DVB-T) tak z něj můžu na počítači přehrávat programové streamy ČT HD. Dekomprese streamu do videoRAM se děje z principu v hostitelském počítači - buď softwarově na CPU, nebo s HW akcelerací GPU, pokud je k dispozici. Nemá smysl uvažovat, že by dekomprese byla věcí nějakého USB donglu, protože skrz USB by objem dekomprimovaných video-dat prostě neprolezl. Mimochodem... pokud se nepletu, dosavadní HDčkové streamy v RS7 mají vyšší datový tok a jmenovité rozlišení než dnešní "QHD" streamy v přechodových sítích DVB-T2. A děkuji za tuto debatu, taky mi delší dobu vrtá hlavou, co bych si pořídil na občasný příjem TV na cestách. RTL2832U odvedl svoji práci a i do budoucna bude sloužit jako nouzový/polní přehledový spektrák, pro ladění antén u příbuzných bude stačit i nadále, jenom už mi T2 muxy nebude umět demodulovat.

1168
Odkladiště / Re:Jak "kryptograficky" uzavřít smlouvu?
« kdy: 15. 03. 2018, 13:52:31 »
Pokud si správně pamatuju dávné studium, non-repudiation je jednou z vlastností Vámi zmíněného podpisu svým privátním klíčem. (Není třeba zprávu=smlouvu ani šifrovat, tím sledujete jiný účel.) Leda byste později tvrdil, že Vám privátní klíč někdo ukradl a na té bázi se dopustil krádeže/podvrhu identity. Možná proto dávají certifikační autority možnost revokovat již vydaný certifikát? S tím že máte povinnost certifikát revokovat, jakožto oprávněný držitel, v momentě kdy Vám klíč někdo ukradne :-)  Pak by se dalo při podvodu uvažovat takto: revokovat certifikát, a již neplatným privátním klíčem podepsat smlouvu. Pokud by si protistrana při přijetí zprávy neověřila podpis v CRL u CA, je to její blbost...

Cintám si pentli, moc tomu nerozumím.

Ohledně časového razítka, to je taky zajímavá otázka. Vy si do textu zprávy (smlouvy) můžete jistě vložit časový údaj jaký chcete, ale těch pár čísílek jaksi sama o sobě nenesou věrohodnost, že ta časová značka je v pořádku, tzn. je Vám to k ničemu. Napadá mě, nechat si ověřenou časovou značku vystavit od nějaké důvěryhodné třetí strany (svého druhu certifikační autority) která časovou značku kryptograficky podepíše svým privátním klíčem. No ale další věc je, co s tou podepsanou časovou značkou dál. Pokud byste si ji jako smluvní strana sám přiložil do zprávy a navrch podepsal svým privátním klíčem, tak Vám nic nebrání, takto časovou značku přiložit kdykoli později = svůj podpis antidatovat směrem zpátky. Čili spíš by ta důvěryhodná třetí strana musela k Vaší zprávě přiložit svou časovou značku a celé to podepsat svým privátním klíčem. Nebo byste "časové certifikační autoritě" poslal pouze hash své zprávy (aby ona nemusela zpracovávat potenciálně objemná kompletní data zprávy a aby neznala její obsah), časová CA by tento hash zkombinovala se svým časovým razítkem a podepsala, a vy byste pak mohl tento "podepsaný datovaný hash" zpátky zkombinovat s původní zprávou, ze které byl hash pořízen - a takto poslat protistraně.

Zaznamenal jsem zmínky, že existují dodavatelé řešení / online služeb, kde jde právě o ověřování časových razítek, nebo ověřování přesného času lokální "časové ústředny" u klienta - nevím přesně. A hele - zřejmě jsem v předchozím odstavci vynalezl kolo. Tuším se o tom se mnou bavila nějaká certifikační autorita - která vystavuje běžné PKI certifikáty. Že takovou službu používá.

1169
Zní to po všech stránkách dobře. Zní to jako cesta vzhůru a kupředu. Pokud máte tohle za sebou, myslím že se neztratíte = příští zaměstnavatel nebude litovat. Držím palec ať ten flek dostanete a ať stojí za to. A s tou děvečkou pro všechno... záleží na situaci, míře a konkrétní skladbě, člověk úzce specializovaný může naopak toužit po trochu pestřejší práci. V téhle branži je pořád ještě šance dělat práci, která Vás baví. Záleží do značné míry na Vás, čeho se v zaměstnání chytíte.

1170
Hardware / Re:Mám vyměnit baterii u UPS Eaton?
« kdy: 11. 03. 2018, 22:36:13 »
Oloveny akumulator ma v priemere zivotnost 4 roky.

Pro úplnost dodávám, že toto platí pro zapouzdřené bezúdržbové akumulátory.
Staniční baterky mají životnost 15-20, v extrémním případě i přes 25 roků.
Co to je stanicni baterka? Ptal jsem se kolegu a nikdo nevi a ze se mam zeptat rail division. Nebylo by lepsi uzivat ustalene mezinarodni pojmy kdyz mame nejakou dobu spadlou zeleznou oponu?

Podle mého vzduchotěsně pouzdřené gelové baterky, co se dávají do UPS a podobných záložních zdroječků, spadají všechny do "staniční" kategorie. Tzn. režim provozu "po většinu života trvalé dobíjení maličkým udržovacím proudem na konstantní napětí při cca plném nabití, jednou za uherák ji něco vybije během půlhodiny do mrtě".

Startovací baterky v autě mají režim "musí dodat několikrát denně krátký pulz vysokého proudu, jinak většinu času živí maličkým proudem stand-by elektroniku v autě a nějakou dobu denně se taky nabíjí - pokud není dobitá na max, tak nabíjecí proud je poměrně silný, třeba 0.2c".

Pak jsou trakční baterie = v elektro vozítkách: ty se cyklují pořád dokola mezi stavy "plně nabito" a "plně vybito", nějakým relativně rozumným nabíjecím a vybíjecím proudem (ale často vyšším než 1/10c).

Staniční baterie co dlouho vydrží, pod tím si představím větší baterky nebo jednotlivé články, váhově omezené tak aby byly jedno- až dvouchlapové, které stráví svou životnost někde v baterkové kobce nebo stojanu na telefonní ústředně.
https://media.wired.com/photos/5926b847f3e2356fd800a3b1/master/w_1200,c_limit/Payne003.jpg
https://www.disasterplanning.com/media/articles/changing-high-rise-fireground-tactics-part-1?page=2
Tradičně byly konstruovány tak, aby se do nich dala dolévat destilka (která se při nabíjení rozkládá na kyslík a vodík, které v plynné podobě utíkají). Telco operátoři zaměstnávali (zaměstnávají?) baterkáře, kteří měli v popisu práce objíždět ústředny s konví destilky a pečovat o hladinu a koncentraci elektrolytu. Pokud se týče režimu, tyhle baterky jsou součástí de facto veliké "online UPS", s tím že nabíječ je dimenzován na trvalý odběr připojených spotřebičů + něco navíc pro dobití po výpadku sítě. Výstupní napětí bývalo tradičně -48V (u nás -60V) proti zemi, přímo z baterek (skrz nějaké nezbytné jištění proti nadproudu / zkratu) = spotřebiče v "telco" branži měly tradičně vstup 48 V ss. Čili režim fungování je "trvale mě trochu dobíjí měnič ze sítě, který vykryje v průměru celou spotřebu připojených spotřebičů, a jednou za čas chvíli táhnu celou ústřednu - ale to je opravdu málokdy, a protože mám kapacitu na den-dva provozu, tak mě to ani moc neobtěžuje, zejm. když tak dlouhý výpadek prakticky nemá šanci nastat".

V poslední době (tak posledních 15-20 let) tyhle DC zdroje s výstupem 48V hodně vyšly z módy. Ajtíci si staví datacentra zásadně se střídavými UPSkami. V téže době zřejmě taky urvala slušný podíl na trhu velkých UPS firma APC na úkor tradičních "baterkářských" firem (napadá mě německá firma Voigt und Haeffner, kterou před úpadkem zachránila akvizice konkurentem Eltek). Třeba takový Benning funguje dál.

Stran: 1 ... 76 77 [78] 79 80 ... 84