11
Windows a jiné systémy / Re:Pomalý unzip ve Windows z NAS na SD kartu
« Poslední příspěvek od Jan Fikar kdy Dnes v 09:31:10 »SD karty mají typicky o dost horší random access než sequential access.
Poslední příspěvky
12
Sítě / Re:Pokročilé dotazy na (nexthop+) (multi)routing
« Poslední příspěvek od Foreigner kdy Dnes v 07:09:39 »Nevim o co se pokousis, ovsem dynamicka aktualizace route table je zalezitost pro routovaci protokoly. Aka BGP, OSPF, dale je zde moznost spojit BGP s ECMP. Routovacich protokolu je vice , is-is protokol se vyuziva temer vyhradne na “podvozku” ISP tier 2/3 a pak dnes temer nepouzivany (aspon ja ho nikde nevidel) RIP. Ted k Linuxu - za me snad nejlepsi aplikace bird od cznic.
Jinak dve def gw je zcela normalni v pripade mas napr. notebook pripojen k lan i wifi. Metrika urci kam pujde provoz. Metrika je jina pro wifi, metaliku a zaroven i pro routy z ospf nebo bgp. Krome metriky muzes nastavit distance.
Jinak dve def gw je zcela normalni v pripade mas napr. notebook pripojen k lan i wifi. Metrika urci kam pujde provoz. Metrika je jina pro wifi, metaliku a zaroven i pro routy z ospf nebo bgp. Krome metriky muzes nastavit distance.
13
Software / Re:Celkový součet specifických souborů v adresáři
« Poslední příspěvek od luksus kdy Dnes v 02:47:35 »No a prča teprv bude zjistit velikostSpočítat součet velikostí všech nalezených souborů taky není problém
Kód: [Vybrat]
find . -iname '*.flac' -o -iname '*.mp3' -o -iname '*.m4a' | xargs stat -c%s | paste -sd+ | bc
14
Hardware / Re:Jaký hardware na domácí Asterisk?
« Poslední příspěvek od xsouku04 kdy Dnes v 00:26:29 »Minimalistické je dát to přímo na router s openwrt. Jsou na to balíčky.
15
Hardware / Re:Jaký hardware na domácí Asterisk?
« Poslední příspěvek od CPU kdy 18. 10. 2024, 23:40:13 »(energetickým baronům).
Asterisk package pro Synology?
RasPBX – Asterisk na Raspberry Pi?
VOIP je sice dead, kdo ještě nemá mobil? Ale když to doma chce?
To máš pro dveřníka?
Ten bude možná žrát víc než ta RPI :-D
16
Windows a jiné systémy / Pomalý unzip ve Windows z NAS na SD kartu
« Poslední příspěvek od mikesznovu kdy 18. 10. 2024, 23:24:21 »2gigový archiv (inflated 2.5GB)na nasu jsem chtěl v pracovní stanici (z průzkumníku \\sh\sl\x.zip) s windows 10 rozbalit na SD kartu (70MB/s)+ (čili oboustranně nelokální) : CPU Skylake 4jádro. síť tlačí 90MB/s
Proč to jelo 6 MB/s, tedy asi na 26 minut?
Když jsem přes ssh rozbalil soubor na nasu trvalo to asi minutu (disky 240MB/s pro dokreslení a budiž polovina rychlosti když to bylo v rámci jednohodisku) - ale jaký je jas není podstatné, tam bych pomalost nehledal.
Když jsem soubor kopíroval na sdkartu (z rozbaleného umístění nasu - ze stejné složky jen zip->exe*) ,jelo to 20MB/s (nevim proč, jestli karta byla unavená nebo interní čtečka je vykopávka) , pro ověření, kopie jiného souboru na plochu jela těch 80MB/s, pro ověření kopie souboru jiného z plochy na sd kartu taky 25MB/s., pro ověření, rozbalení z nasu na plochu 60MB/s - asi na 30 sekund.
Proč je to v windows tak pomalé z nasu na kartu? trvalo by to 26 minut, 6MB/s. Když i vsoučtu rozbalení na armovém nasu trvalo pod minutu a přenos asi necelé 2minuty? I kdyby windows průzkumník nejdřív celý soubor kopíroval to $TEMP, a pak rozbaloval by to taky zabralo max 3 minuty.
Mám pocit, že jsem urobil všechny související testy v před-předchozim odstavci a vypadá to, že" celek je pomalejší než součet částí "
*defendry, crowdstrajky, nortony, kaspersky ani jiný zpomalovače nemám
**jo, teď si uvědomuju, že to není má špičková sd karta na úrovni 80% UHS-1, ale nějaká seškráblá z podlahy linuxdays, ale lowend to není, nějaký A1 nebo V30 sandisk
Proč to jelo 6 MB/s, tedy asi na 26 minut?
Když jsem přes ssh rozbalil soubor na nasu trvalo to asi minutu (disk
Když jsem soubor kopíroval na sdkartu (z rozbaleného umístění nasu - ze stejné složky jen zip->exe*) ,jelo to 20MB/s (nevim proč, jestli karta byla unavená nebo interní čtečka je vykopávka) , pro ověření, kopie jiného souboru na plochu jela těch 80MB/s, pro ověření kopie souboru jiného z plochy na sd kartu taky 25MB/s., pro ověření, rozbalení z nasu na plochu 60MB/s - asi na 30 sekund.
Proč je to v windows tak pomalé z nasu na kartu? trvalo by to 26 minut, 6MB/s. Když i vsoučtu rozbalení na armovém nasu trvalo pod minutu a přenos asi necelé 2minuty? I kdyby windows průzkumník nejdřív celý soubor kopíroval to $TEMP, a pak rozbaloval by to taky zabralo max 3 minuty.
Mám pocit, že jsem urobil všechny související testy v před-předchozim odstavci a vypadá to, že" celek je pomalejší než součet částí "
*defendry, crowdstrajky, nortony, kaspersky ani jiný zpomalovače nemám
**jo, teď si uvědomuju, že to není má špičková sd karta na úrovni 80% UHS-1, ale nějaká seškráblá z podlahy linuxdays, ale lowend to není, nějaký A1 nebo V30 sandisk
17
Sítě / Re:Pokročilé dotazy na (nexthop+) (multi)routing
« Poslední příspěvek od mikesznovu kdy 18. 10. 2024, 22:21:40 »Aha takže jsem sepsal 10bodový elaborát zbytečně, mohlo mi to dojít, že něco ten statický routing vlinuxu je definitivní a takhle těžkopádný. To už ani se nemusím ptát 11, proč když u jednoho mám link down, tak proč "nejde internet", i když vesele mám dvě default routy, ale bohužel ta linkdown má zrovna nižší metriku. čekal jsem, že linkdown routy se nějak klidí z cesty samy- a druhá věc
12 .proč když mám dvě routy na stejné destination 4.0.0.0/8, lišící se jen metrikou nebo rozhraním /teď nevím z hlavy/
, tak proč ip route delete 4.0.0.0./8 smaže jen jednu z nich, a bůhví podle jakého pravidla
Tím jsem se chtěl zeptat, ty dynamické routovací protokoly taky využívaj "jako backend" ty statické routovací tabulky ,jenom ž je právě taky nějakým bastlodémonem snaživě poctivě fortelně aktualizují?
Stejně bych nejradši znal otázky všechny odpovědi 1-12 zvlášď. kromě:
2 - to už jsem si našel, že může být jiná metric nebo jiné rozhraní
3 - nevím jak to funguje v praxi
6(ii) je asi věcí userspace syntactic sugar v novější verzi
a tý nuly, která symbolicky byla poslední
12 .proč když mám dvě routy na stejné destination 4.0.0.0/8, lišící se jen metrikou nebo rozhraním /teď nevím z hlavy/
, tak proč ip route delete 4.0.0.0./8 smaže jen jednu z nich, a bůhví podle jakého pravidla
Tím jsem se chtěl zeptat, ty dynamické routovací protokoly taky využívaj "jako backend" ty statické routovací tabulky ,jenom ž je právě taky nějakým bastlodémonem snaživě poctivě fortelně aktualizují?
Stejně bych nejradši znal otázky všechny odpovědi 1-12 zvlášď. kromě:
2 - to už jsem si našel, že může být jiná metric nebo jiné rozhraní
3 - nevím jak to funguje v praxi
6(ii) je asi věcí userspace syntactic sugar v novější verzi
a tý nuly, která symbolicky byla poslední
18
Software / Re:ČT iVysílání: nefunguje stahování s yt-dlp ani youtube-dl
« Poslední příspěvek od mikesznovu kdy 18. 10. 2024, 22:03:04 »Mně opakovaně ffmpeg hlásí spršku chyb, na windows, linux netestován, verze ffmpeg 2024-10-**
Error in the pull function.
IO error: End of file
Stream ends prematurely at 835584, should be 79x383x
The specified session has been invalidated for some reason.
keepalive request failed for 'htt
Následující není naprosto s jistotou učené:
Ale: v případě youtube-dl se stáhne úspěšně , ,bez vad. hlášky se ukazují vždy až po nějaké době od zahájení downloadu a pak ustanou, na pár bloků(4). Paradox je, že chtěl po mě argument --ffmpeg-path, který používá pod kapotou. Je pravda, že jsem použil --rate-limit
V případě ffmpeg soubor má každých x sekund (10/40) artefakt a useklý segment, takže je to nesledovatelné.
Error in the pull function.
IO error: End of file
Stream ends prematurely at 835584, should be 79x383x
The specified session has been invalidated for some reason.
keepalive request failed for 'htt
Následující není naprosto s jistotou učené:
Ale: v případě youtube-dl se stáhne úspěšně , ,bez vad. hlášky se ukazují vždy až po nějaké době od zahájení downloadu a pak ustanou, na pár bloků(4). Paradox je, že chtěl po mě argument --ffmpeg-path, který používá pod kapotou. Je pravda, že jsem použil --rate-limit
V případě ffmpeg soubor má každých x sekund (10/40) artefakt a useklý segment, takže je to nesledovatelné.
19
Software / Re:Celkový součet specifických souborů v adresáři
« Poslední příspěvek od mikesznovu kdy 18. 10. 2024, 21:46:59 »No a prča teprv bude zjistit velikost, protože du to nedá přesně ani s parametrem -apparent-size, protože do toho započítává velikost složek, které z(lidské definice) mají 0 bajtů, a jako třešnička na dortu ty složky ještě na jiném filesystému ty složky zabírají jiné místo.
možná to bude následovat vdalším kroku.Takže bych šel na to přes find -type f . prý ale existuje příkaz tree.
Palec nahoru RDa za -E místo -P v grepu, protože to může být rychlejší. I když jsem ale narazil na situaci, kdy bylo naopak -P rychlejší ,což uplně znegovalo mood z jiného vlákna, kde jsem si stěžoval na pomalo grepu -P.
možná to bude následovat vdalším kroku.Takže bych šel na to přes find -type f . prý ale existuje příkaz tree.
Palec nahoru RDa za -E místo -P v grepu, protože to může být rychlejší. I když jsem ale narazil na situaci, kdy bylo naopak -P rychlejší ,což uplně znegovalo mood z jiného vlákna, kde jsem si stěžoval na pomalo grepu -P.
20
Hardware / Re:Jaký hardware na domácí Asterisk?
« Poslední příspěvek od mikesznovu kdy 18. 10. 2024, 21:40:01 »Myslím, že spíš to myslí z druhé strany,. aby tím neprospěl druhé straně (energetickým baronům).
