Příspěvky

1

Sítě / Re:Pripojenie domácich priečinkov cez sieť - pomalé spojenie

« kdy: 05. 06. 2023, 18:39:25 »

Pokud by to vázlo na IOps točivého disku (viz iostat a další) tak situaci může prospět, kromě SSD, třeba taky mirror ze dvou disků. Protože má cca dvojnásobek disponibilních IOps při čistém čtení.

A ještě tady koukám na poznámku o počtu NFS vláken. Aktuální počet a statistiku využití lze zjistit z /proc/net/rpc/nfsd . Přesněji, osobně bych asi provedl
grep ^th /proc/net/rpc/nfsd
Výstup je zajímavý především ve chvíli, kdy "to drhne". Pokud na konci výše uvedeného řádku (ve výstupu) nejsou nulové hodnoty, zřejmě by stálo za to, počet vláken zvýšit.
Na Debianu se to konfiguruje zřejmě v /etc/default/nfs-kernel-server , proměnná RPCNFSDCOUNT. Dovedu si představit, že pokud máte desítky simultánních uživatelů, defaultních osm vláken může být málo.

2

Hardware / Re:Alder Lake Latitude 9430 sekají se všechny distribuce

« kdy: 03. 06. 2023, 05:59:40 »

Mám ještě jedno (třetí) relevantní vlákno. Doporučuji číst od konce. Jsou tam zmínky typu "s kernelem >= 6.2.3 je po problému" apod. V podobném duchu končí již odkazované fedoří vlákno na community.frame.work - jenom je trochu složitější se na konec doscrollovat, všimněte si custom teploměru/posuvníku s počítadlem stránek uvnitř stránky mírně vpravo.
Ta oprava v upstream kernelu je zřejmě relativní novinka, třeba měsíc zpátky začali lidi hlásit, že už je to OK.

Jo a někdo taky hlásil, že měl navíc problém s vadnými RAMkami, že to bylo vidět i v memtest86+. Vyřešeno výměnou obou DIMMů.

3

Hardware / Re:Alder Lake Latitude 9430 sekají se všechny distribuce

« kdy: 03. 06. 2023, 00:10:00 »

Mno... na enable_psr už jste si přišel sám. Mimochodem, když se přihlásíte z dálky třeba přes SSH, tak to se chová normálně? Nebo SSH konzola taky drhne?

Z obecných příčin by to jinak mohlo vypadat na nějaký problém s doručováním interruptů. Vzhledem k tomu, že nemáte procesor vytížený po strop, tak případný interrupt od myši (přesněji USB XHCI?) jde třeba někam do kanálu, a kupodivu se nestrefuje do "cizí" obsluhy... je to ale divné, tyhle moderní periferie v čipsetu dneska všechny používají message-signaled interrupty, na tom se prakticky nemá co rozbít, nejsou tam žádné sdílené linky, žádné mapování přes X kolen skrz IO/APIC apod. Pokud bych přesto chtěl podezírat nějaké problémy z tohoto soudku, mračil bych se na ACPI DSDT, a tedy bych pátral po updatu BIOSu. Případně bych se podíval na kernel cmdline argument acpi_osi a zkusil bych říct Linuxu, ať se při interpretaci DSDT netváří jako "linux", ale jako nějaká moderní verze Windows. Konkrétně by mohlo pomoci něco jako GRUB_CMDLINE_LINUX="acpi_osi='Windows 2015'" v /etc/default/grub . Ohledně různých hodnot _OSI stringu je k dispozici aktualizovná vysvětlivka od Microsoftu.
Ohledně zvoraných interruptů je Linux jednak dost tolerantní, jednak třeba umí nahlásit do dmesg "IRQ 21: nobody cared" a daný IRQ vstup utlumí. Čímž postižená periferie sice nezačne fungovat, ale zbytek systému zůstane živý, a o problému se dozvíte právě podle té hlášky. Případně se dá zkusit cmdline argument "irqpoll", který to na legacy drátových interruptech může ještě vyžehlit (za cenu poměrně hnusné režie, protože na každý interrupt se volají postupně všechny registrované obsluhy).

Přemejšlím, jestli by se výrazným drhnutím mohly projevovat třeba nějaké hypermoderní ultra-hluboké C-stavy. Zkusil bych třeba kernel cmdline argument  intel_idle.max_cstate=1 . Jinak by se drhnutím mohly projevovat také problémy typu "PROCHOT" (ale ten by škodil i pod Windows) nebo obecně throttling (T-state) vyvolaný nějak jinak... tady je ale třeba řící, že přestože lze T-state vyvolat i na požádání softwarově, tak nevím, že by v dnešní době nějaký software tuto možnost využíval. Zrovna throttling se relativně těžko odhaluje. A "throttling jako standardní součást řešení tepla" je charakteristický spíše pro levné značky notebooků.

Alder Lake se vyznačuje tím, že jde asi o první x86 CPU (určitě první mainstreamový), který má v některých modelech kombinaci nestejně výkonných jader, tzn. big.LITTLE. Je potřeba, aby s tímto uměl pracovat scheduler. Prakticky to vyžaduje poměrně moderní jádro. Třeba v případě Debianu 11 trochu pochybuju. Do Ubuntu byla podpora Alder Lake přidána údajně během roku 2022. Tzn. to Ubuntu, co jste zkoušel... kdy to bylo, a instalační médium bylo čerstvé? Jaká je v tom systému verze kernelu? (uname -a) Je hloupé, radit čerstvý kernel, k jehož kompilaci člověk potřebuje zdravý a výkonný počítač... Ještě jedno vlákno ohledně různého přidrhávání a zahryzávání Linuxu na Alder Lake.

4

Server / Re:Linuxový souborový systém s línou deduplikací

« kdy: 02. 06. 2023, 15:29:13 »

Kód: [Vybrat]

rdfind -makehardlinks true /path/to/dir

Tohle zmiňoval už tazatel.
Potíž vidím v tom, že ty dva sloučené soubory se stanou jedním. Takže když následně jeden soubor upravíte, změní se i pod druhým jménem. Potřebujete "copy on write" = jakmile se jeden soubor změní, duplicita padá a od té chvíle hezky každej po svym prkně. Tohle může zajistit jedině FS :-/

5

Sítě / Re:Pripojenie domácich priečinkov cez sieť - pomalé spojenie

« kdy: 02. 06. 2023, 15:04:39 »

@JoseD : 200 vláken a vystropovaná 10Gb linka? to jsou hezké výsledky :-D
Jumbo frejmy používáte, nebo dokonce bez nich?

6

Hardware / Re:Neočekávané vypnutí PC

« kdy: 01. 06. 2023, 21:47:33 »

A co třeba probuzení integrované grafiky z úsporného režimu. Třeba protože starší kernel vs nový procesor. C-stavy jsou jenom podmnožina této oblasti. Grafický výstup shazuje při nečinnosti buď Window Manager (přihlášená X session) nebo tuším "display manager" (ten má pod palcem přihlašovací obrazovku).

Jak prověřit, zda je to tím: zakažte zhasínání displeje při nečinnosti. (Ještě horší problém je v některých případech "wake-up from suspend", ale to není Váš případ, pokud počítač jede dál.)

Pokud to vypadá na nějakou takovou softwarovou neplechu, zkuste upgradovat kernel. Nejdřív v rámci distra, nebo si zkompilujte svůj. V Linuxu máte možnost volby mezi několika verzemi - pokud nepotřebujete bleeding edge, volte nepatrně starší major verzi s vysokým patch-levelem.

7

Sítě / Re:Pripojenie domácich priečinkov cez sieť - pomalé spojenie

« kdy: 01. 06. 2023, 21:34:19 »

• iostat 2 ukáže vytížení disků (MBps i IOps)
• iotop ukáže konkrétní proces, který generuje hodně IO per second
• top ukáže procesy, které žerou CPU
• pak třeba existuje ještě latencytop = kde jaký proces tráví hodně času čekáním (v zablokovaném syscallu, třeba na
• přístup k disku apod).

Bohužel na dálku Vám mnoho neporadíme.

Pokud říkáte, že přihlášení někde na konzolu a "su" způsobuje vytížení systému, tak je to dobrá haluz! V památných dobách prvních soukromých serverů na Silicon Hillu zvládla 486 se 16 MB RAM nízké trojciferné počty uživatelů, kteří pracovali pravda tehdy ještě spíš v telnetu než v ssh. Chci říct, že ta korelace s "su" spíš vypdá, že si něco špatně vykládáte.

Pokud nepoužíváte mutt (starobylý mailový klient), tak se myslím nemusíte stydět, přidat opšnu -o noatime do fstabu klidně pro kořenový svazek. By default souborový systém *zapisuje* do metadat čas posledního čtení ze souboru, i když se ze souboru pouze čte. Tahle fičura je schopná srazit reálnou průchodnost na půlku nebo třetinu = zdvojnásobí nebo ztrojnásobí počet IOps generovaný čtecí aktivitou. Kromě toho zkracuje životnost flaškám (SSD).

Stejně tak zvednutí dirty_ratio a dirty_background_ratio může pomoci dost citelně. Je to hodně znát třeba při instalaci (balíčkovacím systémem apt apod.) nebo při kompilaci kernelu, na stroji s moderním výkonným procesorem a relativně pomalým točivým diskem. Máte otevřená dvě terminálová okna, v jednom třeba kompilujete kernel. Vidíte, jak rychle roluje výpis. V druhém okně provedete
echo "90" > /proc/sys/vm/dirty_ratio
echo "80" > /proc/sys/vm/dirty_background_ratio
a okamžitě si všimnete, že disk poněkud ztichnul (přestal tak zuřivě seekovat) a rolování výpisu kompilace se nápadně zrychlilo.

...zmínil jste se už, co to máte za linux? Ony se historicky vyvíjejí také diskové IO schedulery. Osobně ale nechci tvrdit, že zrovna výměna scheduleru bude mít ve Vašem případě nějaký význam. Schválně mrkněte do /sys/block/sda/queue/scheduler . Defaultní IO scheduler v moderních distrech (jednu dobu frčelo cfq, později bfq, dnes ani nevím) se obvykle snaží o co nejlepší "svižnost desktopu" = krátké latence. Ovšem navrub úhrnné sekvenční průchodnosti. Pro serverové nasazení by mohlo mít smysl, použít scheduler "deadline" nebo i "none" (noop). Aspoň to zkusit. Výsledek / vhodná varianta scheduleru záleží na konkrétním mixu zátěže.

Zda to všechno pomůže konkrétně ve Vašem případě, to je těžko říct.
Nemohu vyloučit, že se na tom lví měrou podílí zejména NFS - dost se na něj nadává :-)
Osobně používám NFS jenom pro read-only root při diskless bootu. Svazky pro užitečná data mám na Sambě, a provozuji na tom převážně sekvenční zátěž. Zato klidně desítky klientů simultánně. Jeden konkrétní můj server má nějaké staré úsporné Core2 duo. Úzkým hrdlem bývá spíš gigová síť než disky v serveru.

Jo a taky zkuste nainstalovat smartmontools a zeptat se disku pomocí "smartctl -a /dev/sda", jak se mu daří.

8

Hardware / Re:Starý zdroj pro updatované komponenty osobního PC

« kdy: 29. 05. 2023, 15:59:12 »

A mám pocit, že Intelovo TDP cca od 10. generace CPU je taková virtuální hodnota. Ve skutečnosti když dáte aktuálnímu 10nm Intelu za uši, tak si cucne výrazně víc než TDP. Některé modely o 50-100%.

Bylo by krásné kdyby Intel kecal jen on 50-100%.
Např. úsporný 35W Core i7-13700T si vezme až 106W, 65W modely si berou až 219W a tak podobně.
pěkná tabulka např. na https://diit.cz/clanek/v-tichosti-zacaly-prodeje-35w-core-13000t-raptor-lake

To mi cosi vysvětluje :-)
Možná už jsem to tady zmiňoval... na pracovišti, kde zahořujeme malé průmyslové počítače (pasivní žebrované cihličky a all-in-one paneláčky) máme centrální rozvod 24V DC. V každém odbočném kabelu je tavná autopojistka 3A. Kromě vyložených omylů nebo vadných počítačů nám ty pojistky nehoří. Asi protože počítač s běžným plnotučným "Core i5 moble" starších generací (typický pro tento mechanický formát) žere možná 50W když dostane za uši, spíš ale pod 30W.

No a přišla první vlaštovka s novým procesorem... což kluci v montáži ani moc nezkoumali. Po vybalení byl počítač normálně funkční, dalo se pohrabat v BIOSu, boot testovacího Linuxu po síti klapnul, kliknout na start stress-test a PRSK a tma.
Co to? Novou 3A pojistku, zopakovat postup... PRSK a tma. Až 5A pojistka na těch 24V vydržela. Kolik ten procík mohl mít TDP? Něco jako 25W ?

Jako než řešit analogii tohoto na procesoru Intel, který má nominální TDP = 65 W, se starým 300W zdrojem... o důvod víc, sáhnout spíš po AMD, u kterého pokud vím je na "obálku spotřeby" stále ještě relativní spoleh.

9

Hardware / Re:Starý zdroj pro updatované komponenty osobního PC

« kdy: 29. 05. 2023, 12:25:38 »

Ohledne VT-d, se prave jeste rozhoduji zda nejit spise do Intelu i3, ve stejne cenove relaci.
Protoze do ted jsem s tim procesorem nemel problem.

Heh :-)   - i3 bejvalo tradičně tak dvoujádro bez HT a bez turba. Koukám, že aktuální Alder Lake i3 je čtyřjádro bez HT s turbem. Máte pravdu, že to není marný procesor.
@Jimmyx tu zmiňoval dokonce osmijádro Ryzen 7 5700G.
Koukám na nějaký benchmark... i3-12300 vychází rychlejší ještě na čtyřech jádrech (i3-12100 nastejno jako R7 5700G), při osmijádrovém provozu vítězí R5700G o dvouciferná procenta. A to nevím, zda v tom benchmarku nějak zohlednili HT, což se hodí při velkém počtu vláken.

Na virtualizaci většího počtu instancí je vyšší počet jader jedině ku prospěchu.
A mám pocit, že Intelovo TDP cca od 10. generace CPU je taková virtuální hodnota. Ve skutečnosti když dáte aktuálnímu 10nm Intelu za uši, tak si cucne výrazně víc než TDP. Některé modely o 50-100%.
= já bych to AMDčko nezavrhoval :-)

Pokud se týče VT-d, tak závěr zmíněné debaty byl cca ten, že u Intelu právě v jednopaticové desktopové řadě jsou "IOMMU groups" v čipsetu hodně velké = granularita hodně hrubá, takže přidělovat jednotlivá on-chip zařízení různým virtuálům může být problematické. A že u AMD i tohle snad vypadá o něco líp.

Pravda je, že osobně jedu taky dodnes hlavně Intel, ale to je spíš setrvačností a konzervativismem oboru "průmyslových PC", ve kterém se pracovně pohybuji. Máte pravdu, problémů s Intelem je "minimum" (a radši už mlčím, abych to nezačal rozvádět.) Můj nový noťas na kancelářskou práci má šestijádro AMD.

10

Hardware / Re:Starý zdroj pro updatované komponenty osobního PC

« kdy: 29. 05. 2023, 11:07:35 »

Tohle už vypadá docela rozumně. Pokud se Vám vejde microATX board do té malé skříně.

Volba zda točivý disk nebo SSD je patrně věc subjektivního vkusu. Třeba u nás na pracovišti jsme ohledně toho poněkud ve při. SSDčko umí být fajnově rychlé, pokud mu nenaložíte moc - každopádně věnujte zvýšenou pozornost zálohám.

Procík má dvoukanálový řadič RAM - určitě doporučuji osadit moduly RAM po dvou, mj. i proto, že ta věc má integrovanou grafiku. Byla by škoda, omezit si průchodnost RAMky osazením pouze jednoho modulu.

Nechám na Vás, kolik těm virtuálkám chcete dávat RAMky. 16 GB mi nepřijde úplně horentně mnoho. Podle mého je v dnešní době 16 GB rozumná hodnota na Windows 10 desktop, pokud nechcete po spuštění několika dnešních rozežraných (vadných) aplikací narážet na kapacitu volné RAM. To je bez virtualizace.
Pravda taky je, že holý systém Win10 potřebuje za normálních okolností dodnes třeba 1-2 GB, a třeba linuxovému virtuálu na hraní by mohly stačit taky asi 1-2 GB, zejm pokud to nebudete přehánět s grafickým prostředím.

Ohledně virtualizace... nedávno tu proběhlo vlákno ohledně pokročilejší akrobacie s VT-d, ve finále se probírala granularita IOMMU groups, což má vliv na nezávislé mapování např. IRQ... někde v té souvislosti (možná v odkazech) se lidi bavili o konkrétních čipsetech Intel a AMD. Jsou to zřejmě věci, které se nedočtete ani v datasheetech čipsetů. Ale tohle téma Vás nejspíš trápit nebude, pokud nemáte v plánu, mapovat virtuálkám konkrétní PCI-e periferie.

11

Hardware / Re:Starý zdroj pro updatované komponenty osobního PC

« kdy: 29. 05. 2023, 09:21:09 »

...hele... sice ten procesor má 65W TDP. Pokud by v tom byla integrovaná grafika, tak by to wattáží asi i vyhovělo, pokud ten zdroj není nějak ošizený, což by nemusel. Pro takovou sestavu je tenhle zdroj určen.

Ale: ten procesor grafiku *neobsahuje*. Takže pokud do toho přijde grafika větší než úplně minimální (asi 40W), tak je poměrně pravděpodobné, že těch 300W nebude stačit té *grafice*. Mimochodem v této souvislosti vidím jako trochu problematickou "malou" skříň (není uveden model, ale soudím podle mechanického formátu zdroje = TFX). Trochu trnu ohledně toho, že deska má dva dlouhé sloty PCI-e = dumám, co přesně chcete spáchat s grafikou (grafikami). Jo kdybyste to dal do bedny s ATX zdrojem standardního mechanického formátu PS/2, tak získáte mnohem větší výběr napájecích zdrojů, a můžete si je dimenzovat podle grafiky.

Obecně doporučuji volit jmenovitou wattáž konzumního zdroje jako dvoj- až trojnásobek součtu maximální spotřeby CPU a grafiky (zbytek se dá v gamesním stroji vcelku zanedbat). Když se podívám na osazení sekundáru konzumních zdrojů kondíky, tak vcelku kroutím hlavou nad těmi jmenovitými wattážemi.

12

Sítě / Re:Pripojenie domácich priečinkov cez sieť - pomalé spojenie

« kdy: 26. 05. 2023, 21:43:19 »

Pokud správně rozumím, iotop ukazuje IO per proces.
Zajímavý údaj by byl, IO zátěž per block device = kolik toho hrne jednotlivý disk.
Doporučuji nainstalovat balík "sysstat" a poté použít
iostat 2
Bude Vám v intervalu 2s zobrazovat okamžité MBps a IOps na jednotlivé disky, zvlášť čtení a zvlášť zápis.
Jednotlivý točivý disk má strop asi 75 IOps, pokud jsou seeky skutečně náhodně rozmístěny po plotně. (Pokud nejsou seeky od sebe moc daleko, tak víc.)

Na jakém filesystému jsou ty home adresáře na serveru umístěny? (Ext4, XFS, btrfs apod.) Konkrétně btrfs v defaultním nastavení se zapnutým COW nemusí být to pravé oříškové pro všelijakou zátěž, která neustále mění stávající soubory (dnešní WWW browsery si udržují historii a další věci v DB souboru...) Máte ve fstabu pro ten svazek opšnu "noatime" ? Pokud jako emailového klienta nepoužíváte mutt, tak to ničemu nevadí a ušetří Vám to spoustu IOps.

Na serveru bych zkusil razantně zvednout dirty_ratio (90), dirty_background_ratio (80), dirty_expire_centisecs (třeba 6000). Tzn. zvětšit softwarovou write-back cache před diskem a prodloužit její trpělivost. Kolik máte v serveru RAMky a jak je využitá? Hodil by se výpis /proc/meminfo. Pokud fileserver nemá nic moc jiného na práci než servírovat disky, tak je nesmysl, aby měl spoustu volné ramky (free/available). Pokud je síťový disk subjektivně pomalý, měl byste se snažit, aby server měl co nejvíc v kolonkách "buffers", "cached" a "dirty". Zajímavý je údaj, kolik je v kolonce "writeback". Pokud je to hodně, znamená to, že disk hrubě nestíhá zápis.

NFS jede dneska by default nad TCP - doufám jste ho nepřepnul na UDP.

Co za ethernet je od serveru až na switch v učebně? Je tam aspoň gigabit? Ten řádově odpovídá sekvenční průchodnosti jednoho točivého disku.

Startuje na klientech okamžitě nějaký soft po přimountování síťového NFS svazku (home adresáře)? Třeba nějaký indexer pro rychlé vyhledávání (patrně spíš omylem)... Už tu padla zmínka o keši webových browserů - ta je taky v home adresáři... Projeví se problém ve chvíli, kdy děcka na klientech začnou browzdat? Tzn zkusit ten iotop na klientech.

Na kernel command line (do grubu) bych přidal intel_idle.max_cstate=1 (pokud CPU je intel) a pokud se nebojíte, tak ještě mitigations=off. Ale od toho už si velký výsledek neslibujte. Latence ospalých C-stavů by pod zátěží měly naopak ztratit vliv.

Co jsou zač switche v té síti? Mají management? Pokud ano, dokážete zjistit, zda mají zapnutý 802.3x flow control? Pokud je tahle věc zapnutá, zkuste ji vypnout. Totéž taky na serveru. Není to tutovka, ale mohlo by to pomoct. Jedná se o poměrně primitivní mechanismus, který ne vždy funguje správně a ku prospěchu věci. V lepším případě nevadí...

13

Sítě / Re:2.5G ETH do 10G optiky

« kdy: 16. 05. 2023, 14:54:53 »

SERDES je už hotový bitstream užitečných dat, který má svou jmenovitou rychlost. Full duplex, jeden kanál sem, druhý kanál tam. SERDES nese fakt jenom ethernetový payload, nenese žádný inband dorozumívací "režijní kanál" multiplexovaný mezi užitečnými daty. SERDES je už téměř hotová fyzická vrstva - jenom blikat laserem do optického vlákna.

Nějakou režijní inteligenci navíc (=MDIO) má MII a jeho početné potomstvo, což je původně propoj mezi MAC a PHY.

SERDES vs. SGMII/XGMII mohou být podporovány jako dva alternativní styly framingu na sdílených dvou párech (čtyřech pinech) čipů MAC a PHY.

No, ani ne, jednak záleží co se serdesem bere, ale PSC/PMA je o něco složitější. Věř mi, dal jsem si s tím už dost práce :-D

Rád věřím, respect :-)
No jasně, čistý payload se nafoukne o nějaké to 4/5 nebo 8/10 nebo 64/66 a tuším se ještě scrambluje nějakým polynomem... ale pořád je to jenom payload se vcelku pevnou obálkou navíc. Leze to už z výstupu PHY čipu na symetrickém páru. Samotný SFP transceiver je už jenom hloupý opakovač - a i pokud třeba není (protože kupodivu bridguje), tak "Ethernet na BASE-X SERDESu" nemá režijní kanál, kterým by se v takovém chytrohloupém SFP transceiveru dalo šťourat ze strany hostitele (PHY/MAC). Ne v těch podrobnostech, které řeší MII/MDIO.

Serdes sám o sobě koupíš jak IP na dané technologii (nebo jako hard IP v FPGA). Ale okolo potřebuješ spoustu logiky. Na druhé straně je teď dost populární serdes sdílet mezi aplikacemi (USB 3.0, Ethernet, PCIe, SATA)...

Ano - SERDES v obecnějším slova smyslu. Serializer-deserializer. Obsahuje ho každá sběrnice, která bajty nebo slova nepřenáší paralelně (co bit to drát). Říkat tomu posuvný registr nebo UART by bylo jednak staromódní, druhak dnešní SERDES toho umí víc, umí specifická kódování pro různé varianty sběrnic jak jste podrobně zmínil... a ano, dodává se to jako hotové bloky do FPGA, protože kdo by se s tím chtěl kodit od nuly, žejo...
Čímž jsme se poněkud vzdálili od původního tématu (SFP transceiver a PHY čip = ASIC v něm použítý).

14

Sítě / Re:2.5G ETH do 10G optiky

« kdy: 12. 05. 2023, 14:59:12 »

Jaká ale bude podpora u náhodného switche? Kdoví a v tom je právě ten problém.

Já bych tipnul, že to půjde. Pokud SFP modul v SPD EEPROM nabízí SERDES na některé z rychlostí, které switch podporuje. Nejlevnější switche od značek jako je D-Link (a mnohé noname průmyslové) nejsou nijak vybíravé na značku a model transceiveru, a v těch to nejspíš pojede. Stejně jako noname gigové optické SFP transceivery za dvě stovky.

Vemte nejlevnější noname optický gigový transceiver co máte, nebo optický 10gigový, a vražte ho do uvažovaného switche. Chodí?

Marvell 88X3310

-- koukám na něj, ten je vážně hustej.

V dostupném "data briefu" je zmíněno SGMII i SERDES pro užitečná data, a MDIO pro přístup ke konfiguraci = MII registrům. Není tam pinout ani popis registrů, takže těžko říct, jestli to umí I2C nativně. Pokud ne, dá se I2C MSA SPD "EEPROM" + relay MDIO over I2C zařídit externím maličkým MCU. Pokud by nebylo potřeba DDM, tak mohou být MSA data uložená v samostatné klasické sériové I2C NOR flashce (24C02 nebo tak něco).

Zkouším to na linux stroji (redhat 8, kernel 5.14.0). Vypadá to, že exportuje v serdes typ linky, při připojení 100M (využil jsem mikrotik mAP) to vrací SGMII. Při připojení 10G (na druhé straně je nějaká Aruba) to vrací 10GBASE-KR, interface v linuxu zobrazuje správnou rychlost. Jde si s tím také hrát přes ethtool --set-phy-tunable. Očividně linux má podporu.

Co je v tom Linuxu za síťovku? Když jsem se v tom před časem nimral, tak drivery pro Broadcom MAC (tuším tg3) pracovaly s MII PHY pomocí hezky odděleného "phy subsystému" (hrst specifických driverů pro MII PHY čipy), kdežto driver Intel "igb" (MAC) měl pouze interní podporu asi tří starých PHY čipů s MII (převážně starý 10/100/1000 metalický Marvell).

PHY čipy s MII rozhraním jsem viděl Marvell nebo Broadcom, ale asi jsou i další. Bohužel dokumentace PHY čipů na úroveň MII registrů zřejmě často není veřejně dostupná. Narazil jsem třeba na SFP s čipem Broadcom, který v té době Broadcom ani veřejně nezmiňoval.
Což je z hlediska psaní a údržby driverů dost rozdíl proti čipům "MAC+PHY all in one", ke kterým je dokumentace a leze z nich rovnou tupý SERDES nebo 10/100/1000 metalika.

Pozn.: 10GBASE-KR je podle mého prakticky holý SERDES na dvou metalických párech, jinak shodný s 10GBASE optikou.

SERDES je už hotový bitstream užitečných dat, který má svou jmenovitou rychlost. Full duplex, jeden kanál sem, druhý kanál tam. SERDES nese fakt jenom ethernetový payload, nenese žádný inband dorozumívací "režijní kanál" multiplexovaný mezi užitečnými daty. SERDES je už téměř hotová fyzická vrstva - jenom blikat laserem do optického vlákna.

Nějakou režijní inteligenci navíc (=MDIO) má MII a jeho početné potomstvo, což je původně propoj mezi MAC a PHY.

SERDES vs. SGMII/XGMII mohou být podporovány jako dva alternativní styly framingu na sdílených dvou párech (čtyřech pinech) čipů MAC a PHY.

15

Hardware / Re:Jak zmigrovat multi boot systém z HDD na SSD?

« kdy: 12. 05. 2023, 09:30:31 »

USB-C není marnej - jako náhrada čtyřpinového Micro USB. USB-C má v pinoutu 4x GND, 4x +5V, a 12 pinů pro datové signály, tzn. až 6 párů (ačkoli střední 4 piny zřejmě obvykle slouží jedinému half-duplexnímu páru USB 2.0 +/-). Má menší přechodový odpor pro napájení a je snad i mechanicky nepatrně robustnější, než Micro USB, a dá se bez rizika zasunout v obou pozicích (navzájem o 180 stupňů) - by design. A pravda je, že odolný proti vytržení zrovna není.