Příspěvky

31

Sítě / Nefunkční routing na WAN v IPv6

« kdy: 13. 12. 2023, 09:17:19 »

Ahoj,

rad bych pozadal o pomoc s na prvni pohled s velmi jednoduchou veci, bohuzel nejsem schopen prijit na to proc to nefunguje...

situace:
server - brana (fedora) ipv4 lan/wan (nat)
klient (win10) ipv4

Pres ipv4 vse funguje/routuje.

Zridil jsem si ipv6 wireguard /48 tunel a na serveru pro nej nastavil inet6 rozhrani s adresami:
2a03:3b40:xxx:1::/64 a 2a03:3b40:200::xxx/128,
pro lan rozhrani jsem nastavil 2a03:3b40:xxx::/64 a pro radvd stejny prefix a dns.

Klient dostane ipv6 adresu, internet ipv6 krasne funguje jak na serveru i na klientu.
Nefunguje jen jedna vec: klient se nedostane na wan rozhrani serveru (ping, web...) na 2a03:3b40:xxx:1::
Nechapu proc, ip forwarding zapnut, routovani by melo byt spravne, na fw zadne omezeni neni.
Pakety od klienta jsou videt na lan rozhrani, ale na wan se nedostanou.

Kód: [Vybrat]

$ip -6 r
unreachable ::/96 dev lo metric 1024 pref medium
unreachable ::ffff:0.0.0.0/96 dev lo metric 1024 pref medium
unreachable 2002:a00::/24 dev lo metric 1024 pref medium
unreachable 2002:7f00::/24 dev lo metric 1024 pref medium
unreachable 2002:a9fe::/32 dev lo metric 1024 pref medium
unreachable 2002:ac10::/28 dev lo metric 1024 pref medium
unreachable 2002:c0a8::/32 dev lo metric 1024 pref medium
unreachable 2002:e000::/19 dev lo metric 1024 pref medium
2a03:3b40:200::xxx dev inet6 proto kernel metric 256 pref medium
2a03:3b40:xxx::/64 dev lan proto kernel metric 256 pref medium
2a03:3b40:xxx:1::/64 dev inet6 proto kernel metric 256 pref medium
unreachable 3ffe:ffff::/32 dev lo metric 1024 pref medium
fe80::/64 dev inet proto kernel metric 256 pref medium
fe80::/64 dev lan proto kernel metric 256 pref medium
fe80::/64 dev tap0 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev tun1 proto kernel metric 256 pref medium

Predem dekuji za pomoc.

32

Software / Re:Klon disku s Fedorou nebootuje

« kdy: 14. 04. 2021, 07:53:30 »

A to selže nebo to po timeoutu nabootuje? Pro příště doporučuji dávat do fstabu ke všemu flag nofail.

Timeout mel nolimit nebo tak nejak, proste to cekalo a cekalo a nepokracovalo.

33

Software / Re:Klon disku s Fedorou nebootuje

« kdy: 13. 04. 2021, 10:09:51 »

Ano, bylo to tak, po zmene uuid vse funguje. Diky!

34

Software / Re:Klon disku s Fedorou nebootuje

« kdy: 13. 04. 2021, 08:49:50 »

Pravdepodobne sa ti zmenil uuid jednej z particii. Odporúčam boot z iného média (live cd/liveusb) a skontrolovať či particie v /etc/fstab  majú rovnaké uuid ako tie, ktoré vypíše príkaz blkid

To by mohlo byt ono, ted jsem si uvedomil, ze jsem swap asi vytvarel jako novou partition a jeji uuid z obrazku sedi na fstab. Diky!

35

Software / Klon disku s Fedorou nebootuje

« kdy: 13. 04. 2021, 08:29:37 »

Ahoj,

naklonoval jsem disk s Fedorou 33 pomoci prikazu dd, pote zvetsil systemovou partition (sda3), posunul a zvetsil datovou (sda4) a swap (sda5) pomoci gparted. Offsety sda1-sda3 zustaly stejne.

Po bootovani se objevi hlaska z prilohy.
Ma nekdo tuseni o co se jedna?

Diky.

36

Software / Re:ffmpeg na kernelu ≥ 5.9

« kdy: 10. 02. 2021, 14:09:18 »

Vypada to, ze zahada je objasnena, kdyz zmenim governer pomoci:
`cpupower frequency-set -g ondemand`
tak vytizeni cpu na kernelu 5.10 odpovida tomu co bylo na 5.8 

37

Software / Re:ffmpeg na kernelu ≥ 5.9

« kdy: 10. 02. 2021, 13:58:43 »

Jeste mi napadlo, kdyz jsem kontroloval nastaveni cpu, kernel 5.9+ nove pouziva regulator shedutil, narozdil od 5.8 kde bylo ondemand. A vypada to, ze na 5.9+ se drzi prumerna frekvence niz nez u 5.8. Nemuze to byt zpusobeno timhle? V tom se moc nevyznam, ale laicky receno 5.9+ provozuje cpu na nizsi frekvenci, ale tim padem ho vyuziva z vice procent?
Pripojuju jeste dalsi logy a mereni bylo provedeno znova presne na 500 zpracovanych snimku pomoci ffmpeg.

38

Software / Re:ffmpeg na kernelu ≥ 5.9

« kdy: 10. 02. 2021, 12:51:30 »

Mam overeno, ze ffmpeg spotrebovava na kernelu 5.9+ cca 2x vice cpu.

Takže když nabootujete do staršího kernelu, výkon se zvedne? Máte to ověřeno?

39

Software / Re:ffmpeg na kernelu ≥ 5.9

« kdy: 10. 02. 2021, 12:48:05 »

Diky za tipy, bohuzel z tich vystupu nejsem schopen moc vycist. Pokud by chtel nekdo nahlednout, tak prikladam logy.

• Porovnat výpisy (jestli neříká třeba jaké vektorové instrukce používá).
• Pomocí programu perf změřit, kde se tráví nejvíc času.
• Kouknout/porovnat strace (nedělá to třeba nesmyslně mnoho syscallů?)
• Pokusit se to izolovat na co nejmenším případě (např. přilinkovat h264 knihovnu přímo ke svému programu)
• Pokusit se provést změny uvedené v paperu Producing Wrong Data Without Doing Anything Obviously Wrong!

40

Software / ffmpeg na kernelu ≥ 5.9

« kdy: 09. 02. 2021, 11:23:19 »

Zdravim,

mam problem s kernelem 5.9 a vyse na Fedore 33.
ffmpeg pri dekodovani x264 rtsp streamu spotrebovava vyrazne vice cpu, asi tak 2x. Neni to jen otazka konkretniho cpu, dela to vsude, jak pri dekodovani na Intelu i AMD. Zajimave je, ze na bezne dekodovani souboru s x264 videem to nema zadny vliv, pouze rtsp stream. Nejvetsi vliv maji parametry "-s" a "-pix_fmt". Obecne je kernel 5.9 a vyse o chlup sviznejsi, zpomaleni jsem zaznamenal pouze v tehle konkretni situaci.
Chybu jsem reportoval, bohuzel bez odezvy... https://bugzilla.redhat.com/show_bug.cgi?id=1902818
Rad bych to rozklicoval, ale nevim co uz vyzkouset, abych prisel na to, cim to je. Aktualne se priklanim k tomu, ze to je opravdu kernelem.

Diky za rady.

41

Sítě / Re:Linux klient neakceptuje MTU z radvd

« kdy: 02. 12. 2020, 17:30:30 »

Tak jako na potvoru, ráno to nešlo, pak udělam update a v /proc/sys/net/ipv6/conf/enp7s0/mtu je najednou 1480 a stránky fungujou
Ale stejně by mě zajímalo, která část linuxu se stará o přijetí informací z radvd.

42

Sítě / Linux klient neakceptuje MTU z radvd

« kdy: 02. 12. 2020, 16:53:10 »

Ahoj,

na linuxovem serveru s Fedorou 33 mam nastaven HE ipv6 tunel s MTU 1480, v radvd pak AdvLinkMTU 1480;
Na Windows 10 klientu, se pro ipv6 rozhrani spravne nastavi MTU 1480 a weby jako dopravniinfo.cz funguji spravne.
Problem je na Linux klientu, je tam taky Fedora 33 a MTU advertisovane serverem se z nejakeho duvodu neakceptuje a je vychozich 1500.
Nevim jak tohle na strane klienta funguje, muzete prosim poradit, cim by to mohlo byt?

Predem diky!

43

Hardware / Re:Eaton 5E 1100i nepokrývá výpadky

« kdy: 23. 07. 2020, 13:52:30 »

Tak problém vyřešen. Nový zdroj pomohl, zkoušel jsem několikrát (po dobití UPS) nasimulovat výpadek a pokaždé to zdroj zvládl.
Čekal jsem nějakou závadu na starém zdroji, ale vypadá na první pohled zachovale, překvapilo mě, že ani není nafouknutý žádný kondenzátor.

44

Hardware / Re:Eaton 5E 1100i nepokrývá výpadky

« kdy: 22. 07. 2020, 15:06:23 »

Koupil jsem Be quiet! Pure power 11 400W, skvělé parametry a mám s nimi dobrou zkušenost. Podle různých kalkulaček vycházela spotřeba mé sestavy cca 110W s vytížením 400W zdroje cca 30%, což odpovídá realitě. Jelikož se na ní denně provádí nárazově různá zpracování dat, tak se může příkon vyšplhat až ke 200W, takže myslím že 400W bude více než dostatečné. 500-600W by byl už overkill. Až zdroj nainstaluju, dám vědět, ale věřím, že to pomůže.

Díky za článek, prostuduju.

Tady je celkem zajímavé povídání k tématu aktivního PFC v kombinaci s UPS: http://rayer.g6.cz/hardware/s12ii430.htm

Jinak pokud by došlo na nový zdroj, tak rozhodně ne nějakou 500-600W šílenost, ale něco přiměřeného. Jak už tu někdo napsal, tak ideální je volit výkon zdroje tak, aby byl zhruba dvounásobný oproti průměrnému příkonu serveru (nejspíš pojede většinu času nezatížený). Pochopitelně ale musí být zároveň výkon zdroje vyšší než maximální dosažitelný příkon, což tady ale asi bude triviálně splněno, navíc nízkovýkonových zdrojů není zrovna nějaká moc velká nabídka - bohužel.

45

Hardware / Re:Eaton 5E 1100i nepokrývá výpadky

« kdy: 20. 07. 2020, 21:39:23 »

Trochu jsem nastudoval problematiku UPS a napájecích zdrojů. Ten můj Eaton má mít hold-up time cca 3-8ms.
Zdroje mají tuto hodnotu:
Be quiet! Pure power - 29ms @ 100%
Fortron HYDRO PRO 500W - >17ms @ 80%
Be quiet! System power - 17ms @ 75%
u Seasonicu jsem hodnoty nenašel

Je možné, že ten 350W Seasonic už má unavené součástky (kondenzátory?) a nepokrývá tedy reakční dobu UPS.