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 - Hamparle

Stran: [1] 2 3 ... 21
1
O serveru Root.cz / Re:Reklama
« kdy: 01. 03. 2021, 21:41:21 »
To jako fakt???? Chapu, ze bez prijmu z reklamy to asi nepujde, ale tohle je hrozny peklo.
To by chtělo nějak rozluštit, jestli náhodou nemáš v prohlížeči nějaký malwer nebo jde o tzv. defaultní chování.

2
Chtěl jsem jednoduše otestovat throughput wifiny (běžně je RPi -3 připojené přes wifi bridge)... Což mi fungovalo, ta wifi byla bottleneck. Teď jsem to měl připojené napřímo a divil se proč místo 2x12MB/s mám 2x5 MB/s ,když ping je spuštěn na RPI vzdáleně (neboť ping na Windows je chudý příbuzný). A k překvapení, když se role  REQUEST a REPLY prohodí, tak to jde maximálkou (100BASE-TX)

Ano, na DDos botnet by mi to takovéhle zpomalení vadilo, kdyby to dávalo jen 40 Mbps. Musel bych tedy těch raspberí přikoupit víc, aby to byl DDos a né Dos, na který ses neptal. Má to jeden háček... pokud bych chtěl bych toho botneta použít  mimo svoji síť, musel bych si stejně pořídit rychlejší připojení na net než 16 Mb/s.

3
Zaskočila mě propustnost sítě na RPi  (100Mbps ) ve specifickém případě:
když ho pingám z jiného PC, dostanu se na 100 Mb/s v každém směru, ale když pingám z pi, dostanu se na 40 Mbps každým směrem. (Limit USB 2.0 je 320 Mbps řekněme) . Problém s elektrikou není. Jiný traffic na síti není a ssh je to 100kbps. Zkoušel jsem například i výstup příkazu dát do dev/null už jsem nevěděl rady. Traffic jsem nahnal přes velikost paketu (-s 50000), interval od 0.005 do 0.001. zkoušel jsem i -A(daptive)

htop si K + H (threads + kernel Threads) seřazený dle cpu ukazuje u ping 20%. pak ssh a htop s 4%  pak pod 1% zbytek. (ale celkový cpu load kolem 30%)  - nějak nevěřím v řádku ukazateli procent u procesu samotného, když ten tachometr nahoře v top ukazuje víc.


100Mbps full duplex tedy dá. Otázka je ale ping iniciovaný z pi. Proč je pomalý? Stane se to, že  interval mezi odesláním ICMP nedodrží ze zadaného parametru -i ale  se prostě zpomalí tak, že výsledný traffic právě je těch  -> 40 + <-40 Mbps. Je to krásně vidět, když velikost paketu snížím z 50KB na polovinu.

Malým paketům (do 5KB) jsem se vyhle, protoze pak nabihal packet loss  jak interval sel pod 5ms


Zde je výstup bcmstatu

Kód: [Vybrat]
Time         ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s   cpu0   cpu1   cpu2   cpu3
======== ======= ======= ======= =============== ====== =========== =========== ====== ====== ====== ======
ping na pi
3:17:29 1200Mhz  400Mhz  300Mhz 40.78C (41.32C) 15,927  12,189,926  12,246,560  47.46   0.32   0.81   1.30
3:17:31 1200Mhz  250Mhz  250Mhz 41.32C (41.32C) 16,119  12,190,296  12,326,453  46.88   1.07   1.07   2.05
3:17:33 1200Mhz  400Mhz  300Mhz 41.86C (41.86C) 15,535  12,189,783  11,905,524  47.49   0.87   0.38   1.36

ping od pi
1:20:38 1200Mhz  400Mhz  300Mhz 40.78C (41.86C)  8,156   5,223,513   5,295,228  39.94   0.07   5.98   1.05
1:20:40 1200Mhz  400Mhz  300Mhz 40.24C (41.86C)  8,012   5,138,265   5,221,482  43.64   0.52   7.87   1.50
1:20:42 1200Mhz  400Mhz  300Mhz 41.32C (41.86C)  8,280   5,319,756   5,432,741  32.39   1.04   1.53   3.00


4
Windows a jiné systémy / Re:Presli jste z Mac na PC?
« kdy: 25. 02. 2021, 13:48:29 »
- Nejvíc mě iritovalo jiné ovládání kursoru (Home / End). Na to jsem si za celou dobu nezvykl.
A ja mel zato, ze zrovna na tomhle serveru zkratky Ctrl-A/Ctrl-E nikoho nezaskoci :-/.
To funguje jen v terminále a občas v některých UI prvcích (text input). Ale jako plnohodnotná náhrada to není.

Kromě toho trampoty s tou navigací (posun o stránku)  jsou celkem k zešílení a to i bez toho, že byste to chtěli zkombinovat s označením textu. Pátý modifikátor Fn je taková pomyslná korunka.
Ono chtít posunuout stránku vyžaduje jinou klávesovou zkratku v prohlížeči, textaree aplikací, v terminálu, v terminálu s příkazem fordwardnutým do  less, v  jiném shellu  (přes ssh  ), v( jiném shellu) přes ssh s příkazem  forwardovaným do less

5
Ano, v galerii je naštěkáno asi tak rok. U některých dlouhých galeriíí (ne u všech) někdy vybafne místo obrázku  prázdný snímek.
Kromě toho někdy je tam další nepříjemnost, že přeskok v snímkách galerii po nějaké době (asi 5s) prostě přestalo  jít (bylo ta ajaxové). Řešil jsem to prasácky nějak receptem co protáhne setInterval místo precizního zásahu, kde by bylo potřeba.



Nevím teď přesně co a jak, ale mám pocit, že zdrojem problému je  *saslibs.js. Nedokážu teď dát přesné informace. Každopádně může pomoc si vypnout skripty (galerie se pak zobrazí jako dlouhá stránka) nebo nastavit mobilní prohlížeč.

6
Odkladiště / Re:Kupil jsem si TV a nefunguje
« kdy: 22. 02. 2021, 10:04:47 »
Nevím, co vymýšlýte za elaboráty, ale mě stačilo prostě druhý konec koaxiálu na pána pověsit do vzduchu odkud signál bezstarostně steče do druhého konce v telce.

7
Server / Re:Výstup ping v závislosti na -s
« kdy: 21. 02. 2021, 21:45:23 »
Koukán na Zdroják mi jde, ale je to na dlouhé večerní čtení...
Navíc i triviální funkčnost ping (z hlediska kdo to používá) je složitá naprogramovat (když linuxový ping má 30 přepínačů, obsluhuje fronty požadavků icmp atd,)

Pátral jsem po odpovědi,ale toto nesouhlasí s mým zjištěním.
Citace
he time statistic is the total time spent sending and receiving echo packets, including the delay between each packet:
-z stránky výše to odpovídá (3 pingy po sekundě ... time 1998 ms)

Ale u mě:
pingám 10 sekund po sekundě a výsledek? 14ms? <<<(33.650/41.289/52.156/6.718 ms)
nebo : sudo ping  -i 0.08   -s 9909  ....  někdy500ms někdy 800 a vůbec to nezáleží na délce pingání ...   <<< ( 9.262/17.893/32.435/5.886 ms)




Ale když už jsme u toho zdrojáku, co je tohle za  "slang"? To rozdělování jednoho floatu do dvou argumentů pro printf. Jaký to má význam ?  Když by stačilo %.3f ?
Kód: [Vybrat]
printf(_("%sipg/ewma %d.%03d/%d.%03d ms"),
       comma,

 ipg / 1000, ipg % 1000,                       # ipg celá část, ipg desetinná část
 rts->rtt / 8000, (rts->rtt / 8) % 1000    #ewma celá část, ewmadesetinná část

);
     

8
O serveru Root.cz / Re:Reklama - doplnění
« kdy: 21. 02. 2021, 21:30:19 »
co by s tím šlo udělat asi?
například kouknu a vidím
Kód: [Vybrat]
adobedtm.com
gemius.pl
navrcholu.cz
google-analytics.com
url: sasLibs.js

9
Server / Výstup ping v závislosti na -s
« kdy: 16. 02. 2021, 00:35:47 »
Všiml jsem si zvláštní korelace výstupu příkazu ping dle velikosti dat (přes wifi switch. vpřípadě 77 b se nefragmentuje, v případě 9134 na 7 paketů)

Jde o tyto hodnoty:
-real : v případě 1paketového přenosu sedí čas real (22*0.01s), a v případě 7paketového fragmentového přenosu  je delší dle očekávání a selského rozumu
- hodnota ewma v případě fermentovaného je 13ms což je skoro též ipg, zatímco v 1paketovém 1.5ms
-time v "statistics" , v případě fragmentovaného přenosu(už jsem to slovíčko trefil) je 650-865ms, a u 1paketového 200ms (víceméně stejně).  Nevím, co by to mohlo znamenat

Otázky:
- co je hodnota EWMA a proč v první případě 13ms (jako interpacketgap) a v druhém 1ms. Exponential moving average vím co znamená, ale nevím, jaké veličiny v pingu.
- je interpacket gap  je čas mezi  dvěma odesláním(nebo přijetím ,ale konzistenětně) začátku paketu (od slova inter) a nebo "jalový čas" kdy pakety se nepřenáší (od slova gap)?
-co znamená time hodnota ve vypisu?

Dál tyhle 2 věci nějak souvisí?
-v režimu flood dle manuálu se za každý odeslaný request objeví tečka a za každý přijatý reply zmizí. Takže zbylý počet by měl odpovídat packet loss( krát počet paketů).


-parametr pipe by měl odpovídat něčemu jako "zahlcení", když je neodpovězen víc než 1 paket, je to tak (maximální hodnotě během celého měření)? Ta fronta se ale taky zobrazí při -f parametru že?, ale nakonec zmizí?

Kód: [Vybrat]
time sudo ping -f    -c 220 -i 0.01   -s 9134  cíl
PING cíl (192.168.1.111) 9134(9162) bytes of data.

--- cíl ping statistics ---
220 packets transmitted, 220 received, 0% packet loss, time 865ms
rtt min/avg/max/mdev = 6.681/73.309/323.705/95.889 ms, pipe 20, ipg/ewma 13.075/13.721 ms

real    0m3,026s
user    0m0,077s
sys     0m0,133s



##----------------

time sudo ping -f    -c 220 -i 0.01   -s 77  karel-pc
PING cíl(192.168.1.111) 77(105) bytes of data.

--- cíl ping statistics ---
220 packets transmitted, 220 received, 0% packet loss, time 190ms
rtt min/avg/max/mdev = 1.283/2.233/8.255/0.959 ms, ipg/ewma 9.992/1.595 ms

real    0m2,312s
user    0m0,479s
sys     0m1,252s



10
no tak to bude trouhlehunting na 2 měsíce na plný úvazek... V tom může hrát rol všechno, samotný kód jitsi, flagy a commandline argumenty chromu... Očividně to je ale problém sousisející s velkou plochou videa k vykreslení.

Ale odpadá jeden problém: nastavení videa grafiky v macOS, neboť tam nic nastavit nejde. (a nebo jen přes příkazovou řádku)

11
Software / Re:chromium/linux - DNS over HTTPS
« kdy: 14. 02. 2021, 16:45:19 »
Když se řeší DNS over https, má nějaký smysl jako resolver na perimetru(nebo klidně i systémový) ho používat , když mohu DNS^TLS? Nebo nějakou výhodu oproti tomu

12
Hardware / Re:RPi Zero W + RetroPie problémy
« kdy: 14. 02. 2021, 16:42:33 »
zkus utilitu bcmstat.sh nebo

tento bashismus
Kód: [Vybrat]
while(true) do echo " $(vcgencmd measure_temp | grep -oP '=.+')    $(vcgencmd  measure_volts | grep -oP =.+  ) C$(vcgencmd  measure_clock arm | grep -oP =.+(?=000000)  )   G$(vcgencmd  measure_clock core | grep -oP =.+(?=000000)  )   I$(vcgencmd  measure_clock isp | grep -oP =.+(?=000000)  )  H$(vcgencmd  measure_clock h264 | grep -oP =.+(?=000000))   V$(vcgencmd  measure_clock v3d | grep -oP =.+(?=000000)) "  ;   sleep 1 ; done
případně dmesg | grep oltage

13
Nazdar, normálně používám konference pře jitsi  na mobilu (v prohlížeči chrome) a ten mobil se moc nehřeje, dokonce podle battery meteru ukazuje spotřebu 5W, to má displej FullHD (2MP). To je úžasné dílo techniky.


Ale protistrana s macbookem pro (Retina  15" 2015)  má zážitek drastický, že se větráky roztočí na maximum, ukazatel baterky lítá o 10% vedle měřením zjistil, že procesor celkem žere kolem 50W (grafika 17W, jádra 17W, package 46W, procesor celkem 49W).... Chrome má 87. ...  Nepřehlédnutelné je rozlišení displeje, kolem 5 MP narozdíl od 2MP mobilu. Když zmenší okno z fullscreenu třeba na osminu, klesne to na 30W, což je furt masakr. Je jasné, že zmenšením na třeba 16tinu nedosháne 5W, když to má spotžebu v klidu, ale 50W, což je na úrovni TDP téměř je extrémní. Vypadá to jako 100%cpu load.

Dá se s tím něco dělat? Nebo kde by mohl vězit problém? Nějaké špatné kodeky nebo bug v driverech (to znám i windows, v zrovna namátko taky v nějakém chrome něco strašně vytěžovalo procesor na úrovni kernel load, že celý systém byl pomalý, ale upgrade prohlížeče stačil,, to byla snad verze 50-60) nebo blbá optimalizace chromu nebo nějaké nastavení?

14
z jakého důvodu při odeslání formuláře nedojde z něj odstranění formulářového políčka blabla? Dokonce i poli blabla zustane původní hodnota (ano vím, že je dostupná přes blabla.value). Očekával jsem, že přepisem elements.blabla ="" nebo null dojde ke smazání. ($0.form si odmyslete, je to jen "zkratka", abych nemusel v DOM lovit tag FORM)
Kód: [Vybrat]
$0.form.elements.blabla=""Má to nějaké hlubší vysvětlení? Napadá mě, že se jen nějak bokem vytvoří FormData při renderu formuláře a pak manipulace prvku viz výše samotné hodnoty formuláře nezmění.

15
Server / Re:Docker a hosting bez námahy
« kdy: 12. 02. 2021, 20:07:32 »
...nabízí RancherOS…

Není už tenhle frenetický kontejnerisums trochu moc?

Stran: [1] 2 3 ... 21