- gerner1
- bitpork: Augusztus 2- szombat jelen állás szerint.
- sziku69: Fűzzük össze a szavakat :)
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- eBay-es kütyük kis pénzért
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Chosen: Canon 5D II - portrézás 2025-ben
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- Fogkefe: elektromos vagy manuális?
-
LOGOUT
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
-
-
bambano
titán
válasz
fatpingvin #32695 üzenetére
egyébként ha úgyis tudod, hogy az a program lesz az utolsó, miért nem úgy indítod el, hogy:
fahclient ; shutdown -
válasz
fatpingvin #32692 üzenetére
Én a script irányba mennék.
-
bambano
titán
válasz
fatpingvin #32692 üzenetére
man wait
-
válasz
fatpingvin #32692 üzenetére
szerintem a systemd-nek tudnia kellene ilyesmit, de nézz körül a manual vonatkozó oldalán
-
fatpingvin
addikt
sajnos így...
saját kérdés:
Debian. Van-e olyan kész megoldás arra a feladatra, hogy ki akarom kapcsolni a gépet, viszont fut rajta egy program (akár démonizálva) aminek viszont meg kell várni hogy befejezze az éppen aktuális taskját, elküldje hálózaton ahová jutott és csak UTÁNA álljon le a rendszer. Azért írom így mert automatizálni szeretném, ergo az nem játszik hogy manuálisan szabályos leállás, aztán ha leállt akkor poweroff.
nem tudom hogy van-e beleépítve olyan hogy simán process signallal szabályos, üzemszerű leállást tudjon produkálni, de ha démonként rohangál akkor van ilyen parancs hozzá ami ezt intézi.
valamiért az az érzésem hogy erre van valami rendszerkoherens megoldásén nem kell shutdown szkriptet írni hozzá (4 sor lenne, szval nem gond...), csak nem tudom hol kéne keresni.
FAHClientől van szó amúgy, de igazából kíváncsi lennék valami általános megoldásra ha van ilyen.
-
_NCT
addikt
válasz
fatpingvin #32690 üzenetére
Szomorú, akkor majd lehet beújítok egy RTX 3060-at, az is elég lesz pár évig. Köszi a visszajelzést
-
fatpingvin
addikt
ha célirányosan GPU computing kell, akkor akármennyire hányok én is tőle de valami NV kártya. a ROCm nagyon jó cucc, csak sokkal szűkebb a hardvertámogatása és kb egy nagyságrenddel kevesebb library van hozzá készen elérhetően mint a CUDA-hoz.
hashcat alá meg sajnos ha modern hardvert akarsz akkor nem is kérdés, CUDA fog kelleni. ROCm fronton mindenképpen előre utána kell járni hogy TÉNYLEG menni fog-e rajta. én a TensorFlow-al jártam majdnem így, az szerencsére bizonyos verzió felett támogatott.
szerk: egyetértek. úgy vártam én is ROCm-et mint éhező egy falat kenyeret, végre egy értelmes CUDA alternatíva. végülis lett, de nem ment akkorát mint reméltem, végülis megy a fejlesztgetése, de egy csomó kártyán csak experimental, a telepítése egészen kretén módon van megoldva (mi van ha NEM akarok konténerezni?) hozzá tartozó library elég kevés van, a CUDA-ROCm OTF fordító meg ahogy nézem még mindig csak koncepciószinten, kísérleti jelleggel létezik.
-
#15041568
törölt tag
22.04-nél hotspot hibába belefutott már valaki? Telepitett kernellel, majd 517-essel - megküzdve a túzfallal és wpasupplicant downgrade-del.. Szórni szórja, csak a csatlakozott eszközön nincs kapcsolat.
-
tomy_cz
senior tag
Sziasztok!
Ubuntu 22.04 LTS esetében egy USB-n csatlakoztatom az Eaton 5E szünetmentesemet, próbálom beüzemelni NUT-al, de azt vettem észre, hogy lsusb-vel nézve folyamatosan változik a Device értéke, pár másodpercenként lekérve:
root@tom:/home/kodi# lsusb | grep UPS
Bus 005 Device 019: ID 0463:ffff MGE UPS Systems UPS
root@tom:/home/kodi# lsusb | grep UPS
Bus 005 Device 020: ID 0463:ffff MGE UPS Systems UPS
root@tom:/home/kodi# lsusb | grep UPS
Bus 005 Device 021: ID 0463:ffff MGE UPS Systems UPS
root@tom:/home/kodi# lsusb | grep UPS
Bus 005 Device 022: ID 0463:ffff MGE UPS Systems UPS
root@tom:/home/kodi#Próbáltam másik kábellel is.
-
CPT.Pirk
Jómunkásember
Ha valakinek RX5600 XT videokártyája van, pls ossza meg velem a gyártó nevét és ennek a parancsnak a kimenetét:
cat /sys/class/drm/card0/device/pp_od_clk_voltage
-
_NCT
addikt
Köszi szépen, jó ezt tudni. Win alatt valamivel jobban teljesít, de pl Arch alatt volt olyan, hogy a workload-ot 4-re állítottam, lassabb lett mint nélküle, ubuntu 22.04-en szintén. Érdekes jelenség, ez is legfrissebb opencl-mesa driverrel. Azt nem is mondom, hogy csak lts kernel jöhet szóba, mert hivatalosan 5.15-ig támogatott.
Amúgy a fő felhasználási terület az ez lenne, persze nem 0-24ben, illetve játszani is szoktam néha napján pl Far Cry 6-al, ezért nem elég az IGP és a G szériás Ryzen. Jelenleg Ryzen 5 2600 cpu van a konfigban, messze nem a cpu a szűk keresztmetszet. A Gimp és Libreoffice Calc-nak is kell az opencl, ezek is anyáztak mostanában.
Szerk: szomorú git-en is látni mennyien várnak támogatásra frissebb kártyáknál is AMD vonalon. Régebben (3-4 éve) még mindenki azt mondta, hogy Linuxra csak a pirosak jöhetnek szóba.
-
vicze
félisten
Én úgy fogalmaznék, hogy hashcat+OpenCL pain in the but, megnyugtatlak Windowson is kész szenvedés.
Ha Hashcat lenne a célprogram és Linux desktop az a tolerancia szintedtől függöen két szék közé esete. CUDA lényegesen gyorsabb mint OpenCL csak le kell nyerni a zárt drivert és néhány hülyeségét, mindenképp Nvidia ha Hashcat a SW.Szerk: Hashcatnél nagyon fontos hogy mertartsd a régi verziókat is mert tudnak érdekes változtatásokat csináni, amitől egy adott driver verzióval nem működik.
-
-
-
Siriusb
veterán
Szia!
Biztos, hogy szükséged van kártyára, integrált egység nem elég? Nekem már vagy 10 éve nincs külön videokártyám, de ez persze felhasználásfüggő.
Idáig mindig intel procim volt, idén váltottam AMD-re, nos, nem bántam meg, meg vagyok elégedve az integrált GPU-val, persze nincs is, amivel különösebben terhelném. -
_NCT
addikt
Sziasztok! Előre bocsátom nem akarok hitvitát indítani, csak a száraz, nyers tapasztalatokra vagyok kíváncsi. Szóval szükségem lenne segítségre, hogy a jövőre nézve AMD vagy Nvidia kártyát érdemes vásárolni, ha az elsődleges OS Arch linux/Manjaro lenne, melyiknek jobb jelenleg a támogatottsága driver szinten? Azt olvastam, hogy az Nvidia csak zárt driverekkel operál, a nyílt meg baromi régi. Az AMD-nél van nyílt driver, viszonylag frissítik is, de az OpenCL régebbi (de talán még újabb) kártyával is pain-in-the-ass.
Az AMD-nél szíven szúrt, hogy az OpenCL támogatást kinyírták a Polaris kártyáknál (RX580 8GB-om van, nem mondanám gyengének és túl réginek sem), gyakorlatilag ROCM 4.0-tól kezdődően. Eddig elvoltam a problémával, de mostanában hashcat-et kellett volna használnom, és egyszerűen egyik driver-el sem akar szépen futni. Illetve az opencl-mesa csomaggal úgy ahogy működik, de egy-két hash-t nem tud, megfelelő opencl támogatottság jegyében. Most jönne az, hogy akkor nyergeljek át Windows-ra és ott van minden, de munka során ez inkább szívás. rocm-opencl-sdk pedig az istennek nem akar buildelni, próbáltam yaur/paru és makepkg-el is felrakni, fél napja csak áll, az elején 12 core-t használt a makepkg, egy idő után már csak egyet...
Sok helyen azt írják, hogy a CUDA a jövő és számítási feladatoknál (pl AI) jobb az Nvidia, az AMD inkább gamingre feküdt rá. Megint máshol az OpenCL előnyeit mutogatják, kontrasztban a zárt(abb) CUDA-val. Mennyire igazak ezek?
-
válasz
#56769280 #32674 üzenetére
Pont hete írtam erről egy összefoglalót
-
-
-
-
CPT.Pirk
Jómunkásember
válasz
CPT.Pirk #32654 üzenetére
Éééés úgy néz ki a 6.2-es kernellel kapunk megoldást erre a problémára... https://www.phoronix.com/news/AMDGPU-Fix-For-5.19-Bug
-
CPT.Pirk
Jómunkásember
Korábban párszor írtam a játék közben meghaló AMD driverről, mikor a gpu próbálja magát resetelni de belehal és lehet a gépet újraindítani...
Na azóta megleltem a kapcsolódó freedesktop.org gitlab oldalt ahol viszont azt látom, hogy gyakorlatilag minden Vega vagy újabb AMD hardver alatt is jelentkezik a probléma, de még akkor is elő tud fordulni, ha csak böngészel a gépen (ezt én is megerősítem). 3 hete én is csináltam itt egy hibajegyet, de sok minden nem történt. Ahogy látom, a többi hasonló hibajegyben sem.
Megpróbáltam kideríteni, hogy egyáltalán foglalkozik-e az AMD vagy bárki ezzel a problémával, de zátonyra futok. Az okótberi amd-gfx levél listát végignézve nem. Előző hónapokat nem álltam neki végigtúrni, mert ez is túl sok szöveg volt. Az sem világos, hogy mikor mi kerül be a kernelbe, a kernel.org-on a changelog az egy bazi nagy wall-of-text amivel nem tudom mit lehet kezdeni...
Abban biztos vagyok, hogy nagyjából kernelről kernelre javul a helyzet, mert tesztelgetve korábbi kerneleket jóval rosszabb volt a helyzet ezzel a gpu reset problémával, de nem tudom, hogy hol tartunk vagy merre haladunk és ez frusztráló.
Nem tudom hol lehetne még nyomozni ezekben a kérdésekben.
-
-
Hello,
Valaki tud valami bármit, amivel egy raw filerendszerű meghajtóról le lehetne nyerni mpeg stream-et?
Lenne egy HDD-s felvevő, ami saját filerendszert használ (leginkább raw, vagy a file-ok kezdeteit a saját flash-ében tartja, de amúgy rendes MPEG streambe vesz fel), após meg nem szeret újraírható lemezre felvenni műsorokat csak azért, hogy normálisan vissza tudja nézni.
Szóval valami olyan cuccra lenne szükség, amivel legalábbis egy ismeretlen filerendszert végig lehet scannelni, és rájön, hogy egy-egy adatfolyam hol kezdődik... (Hexeditor kivételével, mert ahhoz azért kevés volnék)
-
Siriusb
veterán
válasz
Dißnäëß #32647 üzenetére
Vagy a find-dal, vagy az fd-vel kellene, én kezdek átszokni ez utóbbira.
Például valami ilyesmi:
fd -e txt -x rm
.
Először mindenképpen a -x rm nélkül teszteld le!-e, --extension ext
Filter search results by file extension ext. This option can be used repeatedly to al‐
low for multiple possible file extensions.-x, --exec command
Execute command for each search result in parallel (use --threads=1 for sequential com‐
mand execution).Note that all subsequent positional arguments are considered to be arguments to the com‐
mand - not to fd. It is therefore recommended to place the -x/--exec option last. Al‐
ternatively, you can supply a ';' argument to end the argument list and continue with
more fd options. Most shells require ';' to be escaped: '\;'. This option can be spec‐
ified multiple times, in which case all commands are run for each file found, in the or‐
der they are provided. In that case, you must supply a ';' argument for all but the last
commands.The following placeholders are substituted before the command is executed:
{} path (of the current search result)
{/} basename
{//} parent directory
{.} path without file extension
{/.} basename without file extensionIf no placeholder is present, an implicit "{}" at the end is assumed.
Szerk.: de lassú voltam, amire mindent bemásoltam.
-
válasz
Dißnäëß #32647 üzenetére
rákeresel a fájlra és törlöd, ha megtalálod
find . -type f -name "*.txt" -exec rm -rf {} \;
aztán lefuttatsz egy második kört és ugyanígy törölteted az üres könyvtárakatfind . -type d -empty -exec rmdir {} \;
mit csinál az rm-nél a d kapcsoló? a man szerint nincs neki olyanja
-
Dißnäëß
nagyúr
Jó reggelt szakik !
Hogyan tudnék egy teljes könyvtárszerkezetből (sok alkönyvtár) kitörölni egy bizonyos típusú fájlt ? (És ha a könyvtárban egyedül volt, azt is törölje).
rm -rfd ./*.txt
csak ott törli azt a txt-t, ahol állok, nem megy alkönyvtárba tovább, hogy az ott lévőt is törölje.Egy egész fájlrendszert szeretnék így szelektíven kitakarítani némi sallangtól.
-
inf3rno
nagyúr
válasz
fatpingvin #32643 üzenetére
Igen az már stimmel. Mérési eredményeket hol lehet nézni erről? Kíváncsi vagyok mennyivel jobbak a szerver alkatrészek, de a google nem dob semmit.
-
-
inf3rno
nagyúr
válasz
fatpingvin #32641 üzenetére
Nekem arról az a benyomásom, hogy hardver hibát jelent, de simán kifagyhat a gép szoftver hiba miatt is, és egy újraindítás után működik újra. Mondjuk egy memory leak-es kódú gépet időnként újra kell indítani, aztán mehet minden tovább egy hétig.
-
Shyciii
veterán
válasz
fatpingvin #32635 üzenetére
Most megnéztem az itt levő routert a rackben. Tehát akkor légyszíves mutass nekem egy kb 24cm mélységű 1U-s méretű bika erős pc-t, ami mondjuk csak 5 évig kibírja a non-stop terhelést fagyás nélkül.
-
Shyciii
veterán
válasz
bambano #32634 üzenetére
Akkor most összerakom neked amit írtál, hogy lásd mennyire magadnak mondasz ellent 1-2 óra alatt:
""nem a felső házról beszéltem, ahol epyc cpukkal kell routolni, hanem az otthoni és kisvállalati szintről.""
"attól még egy kisvállalat használhat olyan mikrotiket, ami számára elég teljesítményű."
No tehát akkor pontosan ugyanott vagyunk, ahol mondtam. Rajtad kívűl irgalmatlan kevesen építenek nagy teljesítményű pc-t, hogy azt használják routolásra.
És akkor még meg sem említettem a pc-s alkatrészek megbízhatatlanságát, mert nem arra tervezik hogy non-stop menjen akár évtizedekig + az épített pc-k 0 supportolását (mert ugye kis cég nem tart külön it-s, mert minek kis cégnek). -
Shyciii
veterán
válasz
bambano #32631 üzenetére
attól még egy kisvállalat használhat olyan mikrotiket, ami számára elég teljesítményű.
Erre elfelejtettem reagálni. Szal ugye az megvan, hogy a nagyvállalatoknak, akiknek kifejezetten nagy teljesítmény kell, azok nem pc-t használnak routernek? Én utoljára a Microsoft-ot láttam legbelül jópár éve, és bizony egy fika pc nem volt routernek...
Tehát te mindennél többre tarthatod a pc-det routernek, csak sajnos rengeteg cég nem osztja ezt a nézetedet. -
bambano
titán
válasz
Shyciii #32630 üzenetére
Mit kell rajta nézni?
A rackelhető pc nem nagy durranás, millió megoldás létezik rá.
Másrészt attól, hogy egy pc-ből erősebb routert lehet összerakni, mint egy mikrotik, attól még egy kisvállalat használhat olyan mikrotiket, ami számára elég teljesítményű.Nekem itthon két rackem van... na és?
-
Shyciii
veterán
válasz
bambano #32622 üzenetére
nem a felső házról beszéltem, ahol epyc cpukkal kell routolni, hanem az otthoni és kisvállalati szintről.
Azért azt megnézem, hogy az általad számítógéppel épített routert hogyan raksz be egy kis rackszekrénybe, ahol még ezer más dolog van. Mert úgy kisvállalatot mondasz, de most épp egy kis vállalatnál ülök bent rendberakni a dolgokat, és alig vannak 15-en, de bizony egy kis rackszekrény van, és nem oda van b..zva egy számítógép a földre külön routernek, és még egy szervernek. Mert ugye ha már nagyteljesítményű routerről beszélünk, akkor nyilván az általad épített gyors pc sem csinál semmi mást, csak router-i feladatokat, ugye? Tehát maga a szerver megint egy külön gép, ami DNS, DHCP, VOIP, SAMBA stb szerver.
-
inf3rno
nagyúr
válasz
fatpingvin #32625 üzenetére
Én is erre jutottam, én Odroid XU4-el próbálkoztam valami nano szervert fellőni, aztán elég hamar elengedtem. Gondolkodtam, hogy valami integrált processzoros lapot veszek én is, de aztán rendes x64 mellett döntöttem a méret rovására. Az AM4, amit idén vettem sem győzött meg, hogy kell nekem az mITX. Lehet kiszórom a házat, aztán veszek egy uATX házat neki, vagy erősen moddolom, de nincsenek szerszámaim lemez hajlításhoz meg vágáshoz, úgyhogy talán az még többe is kerülne. Az a bajom vele, hogy akarok rátenni két hálókártyát bifurkációval, és viszonylag széles a riser, úgyhogy nem férnek el egymás mellett a jelen állás szerint. Nem is tudom mi erre a standard megoldás, hogyan lehet belemókolni akár egy ATX házba ilyen riserrel a kártyákat.
-
inf3rno
nagyúr
válasz
bambano #32624 üzenetére
Amd mindig is energia pazarlóbb volt, ha ez a fő szempont, akkor csakis Intel. Ja hát ez nem integrált, szerver CPU, Xeon E3-1230 v5 workstation lapon: MSI C236M Workstation. Ha lenne IGP, akkor még alacsonyabb lenne a fogyasztása. Volt előtte ARM, de nagyon gyenge volt a support hozzá, meg nem vagyok oda az integrált dolgokért, úgyhogy azt az ötletet elvetettem.
-
Apollyon
Korrektor
válasz
fatpingvin #32625 üzenetére
1043ND nálam 2010-ben volt, akkor a legjobb net olyan 80-100 megabit/s körül alakult, arra megfelelt. Nem csoda, hogy a többszáz megás bulit meg gigabites témákat már nem bírja.
-
fatpingvin
addikt
válasz
bambano #32624 üzenetére
én nemrég a reszicsökkentés végett visszaváltottam egy 1043ND-re az épített Via procis routeremről... maradjunk annyiban, már keresem a x8-as PCIe szalagkábelt amivel a normálisabb gépházba vissza tudom tenni és vissza tudom állítani az előző konfigurációt. ezek a SOHO routerek egyszerűen nem alkalmasak a feladatra, vagy legalábbis csak kompromisszumosan.
-
bambano
titán
válasz
inf3rno #32623 üzenetére
j5040 asrock alaplap 10 wattos tdp-jű procival van. plusz ethernet kártyával routerként szerintem kevesebb lesz, mint a hap ac^3.
én is váltottam am4-re nemrég, és most vissza 1170-re, mert az amd-s driverek minőségével tele lett a hócipőm. az energiagazdálkodás se az igazi. -
bambano
titán
debian által gyártott kernelre váltottam.
tehát nem ragaszkodnak.
a thunderbird már évek óta egy szemétdomb, és nem lett jobb.
örülök, hogy pár biztonsági hibát kijavítottak, és tettek bele sok újat.nem a felső házról beszéltem, ahol epyc cpukkal kell routolni, hanem az otthoni és kisvállalati szintről.
igen, köszönjük, parádés, hogy az intel qat akár 36 Gbps-t is titkosít/thread és van neki legalább három threadje (az eredeti intel adaatlap szerint 106 Gbps-ig megy), ezt állítsuk már szembe az 1-2.5 Gbps körüli internetes kapcsolatokkal...Egy normálisan összeválogatott, tisztán routernek szánt pc nem sokkal drágább, felét fogyasztja, és lényegesen erősebb, mint egy mikrotik router (mondjuk tetszőleges mikrotik router a ccr22xx alatt).
Én most építettem magamnak házi szervert, és az úgy fogyaszt harmadával többet, mint a 9 magos tilera (37w vs 27w), hogy van benne diszk is, meg ssd is, meg rendes proci is, meg elég ram is ahhoz képest, amennyi egy routernek kellene.
de agyalok, hogy építek még egy gépet, ahol jobban priorizálom a fogyasztást, és megnézem, mit tud.
-
inf3rno
nagyúr
Annak írom, aki képes felfogni.
Ja én csak saját tapasztalatból indulok ki. Sima x64-es gépnél a video kártya driverrel szívtam, de azt is sikerült megoldani. A 10Gbps hálókártya meglepő, de ment out of the box. Azért mégse egy Linux életérzés, desktopra nagyon nem ajánlom, szervernek talán elmegy. Bányászatra vagy MI-re nem jó, nincs CUDA, valszeg soha nem is lesz és a ROCm-et sem akarják támogatni. Ennyi a tapasztalatom velük. A szerverrel kapcsolatban annyi aggályom van, hogy pl. node.js-nél 3 hónap elmaradásban vannak, aztán ha biztonsági frissítés ennyit késik, akkor simán feltörik a szervert annyi idő alatt. Inkább akkor Alpine. Valószínűleg a pfSense terén frissebb minden, és arra koncentrálnak, illetve elvileg az OpenBSD - OPNsense is jó routerre, talán jobb is, mint a pfSense.
-
vicze
félisten
válasz
inf3rno #32619 üzenetére
Ne nekem írd.
"driver támogatásuk is nagyon jó"
Hát ööö ebben azért nem adnák igazat, a AMD oldali támogatás elég foghíjas sokéves termékekre is. RAID, HBA, NIC-nél is nagyon oda kell figyelni mit vesz az ember, és minding csekkolni az adott verzió HW comp listáját. Ez tök érthető a közösség mérete miatt ahogy írtad, de tényleg minding meg kell nézni.
Pár éve sikerült pont elnézzek egy számot egy NetXtreme II-nél, hát jó pár óra volt mire rájöttem, hogy el***sztam. -
inf3rno
nagyúr
BSD-nél a legtöbb Linux szoftver működik minimális módosítással. FreeBSD-re simán felment az xorg és az XFCE vagy KDE is. Nyilván portolni kell rá, de állítólag nem egy nagy munka, és a legtöbb portolva van, ahogy a DPDK is. [link] A driver támogatásuk is nagyon jó, régi eszközöknél talán jobb is, mint a Linuxnak, újaknál vannak elmaradások, mert kicsi a közösség, és nem győzik.
-
vicze
félisten
válasz
bambano #32607 üzenetére
"láthatóan nem ragaszkodik,"
Te magad váltottál testing kernelre nem ez az alap beállítás. És még egyszer így már nem lesz stabil rendszered és több inkompatibilitás is eredményez az alap repoval.Thunderbird azért lett kényszerből frissítve mert az utóbbi hónapokban nagyon sok high és kritikus sebezhetőséget találtak benne.
De még egyszer, nem hitvitát szeretnék, mindenki úgy és azt használ ahogy szeretne, a leírtak az én személyes véleményem, és teljesen elfogadom, hogy valaki másképp vélekedik erről.
"ahol a mikrotik is versenyez, a pc egyértelműen mindig gyorsabb routernek"
Akár igaz is lehet ez az állítás, csak a ár többszörös lesz egy cél HW-hoz képest, nem említve a fogyasztást és egyéb apróságokat. Egy Intel QAT kártya 30W-ből oldja meg az amit egy Epyc 200-ból...
Cél HW vs. általános compute: -
vicze
félisten
Nagyon fárasztó bocs...
"A pfSense nem használhat DPDK-t, mert az Linux only szoftver."
LOL, legalább egy Goole keresést megejthetnél. Ahogy ezzel úgy a többivel is elég nagy tévedésben élsz. A Linux onlyság konkrétan ott szerepel a DPDK tévhitek listájában...
Aha... A kernel a full nevet használja helyesen, te meg rosszul rövidíted még minding...
x86 a 32bit-et jelöli, amit már szinte senki se használ. -
inf3rno
nagyúr
válasz
lionhearted #32613 üzenetére
Kösz!
-
bambano
titán
válasz
lionhearted #32613 üzenetére
azért amikor a hw offloaded ktls-t tudó spéci netflixnek fejlesztett hálózati kártyához ért a ppt, akkor úgy éreztem, vicze1 kolléga szeme felcsillan...
-
inf3rno
nagyúr
válasz
lionhearted #32611 üzenetére
Be tudnád linkelni?
-
-
bambano
titán
és tényleg nem értesz egy dolgot, hogy nem az árról beszéltem, hanem a teljesítményről. A fogyasztásról nem is beszélve, fajlagos teljesítmény alapon azok a mikrotik cuccok, amiket én néztem, sehol sincsenek egy pc-s routerhez képest.
több 100G-s routert nemigen csinálnak pc-ből, mivel nem bírja a busz. az igazán brutál routerek jó eséllyel l3 switchek.
A mikrotiknek, akikről én beszélek, nincsenek több 100 gigás routerei. Az első switche is, amelyikben van 100 gigás interfész, pár hónapos történet, a routereiben meg 25 gigás interfészek vannak.
-
Nem akarom DOS-olni magam, így konkrétat nem mondok. De minden gyártó 5G eszközei DPDK-val mennek. A reklám anyag a valóságban még jobban kihúzható. Egy AMD szerver proci ma már brutál erős, olyan FPGA-t nem tudsz csinálni ami akár azt megközelíti. Nincs HW gyorsítás, a HW maga a proci. Még a hardware checksumming-ot is kikapcsolja a DPDK. Közvetlenül a hálókártyáról pollolja a real time futó thread (övé a mag, nincs preemptive scheduling) a packeteket. A pfSense nem használhat DPDK-t, mert az Linux only szoftver.
Mond Linusnak, ugyanis a kernel architektúra továbbra is x86 maradt
(#32607) bambano Nem értek egyet, azokban a szegmensekben pont a mips/arm gyorsabb adott áron és fogyasztás mellett. Az igazán brutál routerek (több 100G vagy akár több T) azok viszont PC alapúak.
(#32603) Lenry Viszonylag friss, támogatott LTS kernel. Problem?
-
bambano
titán
a debian konzervativizmusához még annyit: a mostani stable-ben főverziót léptek a thunderbirddel, amit egyébként nem szoktak. csak az új tb bugos, viszont átírja a konfigjaidat, ezért nem lehet downgradelni.
milyen jó (nem), hogy a debian megszegte a saját elveit... a régi tbird működött, csak pár idiótának megint fontos volt nyüzsögni, így felraktak újabbat. az meg bugos.
ráadásul a debian egy disztró. miért baj, hogy van egy disztró, ami ezt gondolja? ha neked nem tetszik, választasz másikat.
-
bambano
titán
azt mondtad, hogy a debian ragaszkodik a régi kernelhez.
láthatóan nem ragaszkodik, hiszen itt van egy 5-6 napos kernel, gyári debian, felrakhatod.nem tudom, miért használnak bsd-t tűzfalnak, de mint írtam, nem mostanában néztem.
"Nem azt írtam, hogy nem végezheti, hanem az, hogy rohadt lassú lesz egy HW gyorsítotthoz képest.": valójában akkor lesz lassú, ha egyébként a feladat kisámfázza a cpu-t. illetve ott van még az a téves általánosítás is, hogy nem választod szét a kategóriákat. Azokban a szegmensekben, ahol a mikrotik is versenyez, a pc egyértelműen mindig gyorsabb routernek.
-
vicze
félisten
válasz
bambano #32602 üzenetére
Írták, hogy az nem a Debian stable, az 5.10 és marad jó ideig
A 6.0-kal egy csomó kompatibilitási problémát behozol, ha csak nem testingen vagy.Igen BSD-t tök poénból használják tűzfalnak, hogy minél lassabb legyen. Egy router OS-en nem éppen a stock kernel rohangál.
"pc-kből épített routerekben a linux és az x86 végzi a routingot."
Nem azt írtam, hogy nem végezheti, hanem az, hogy rohadt lassú lesz egy HW gyorsítotthoz képest. Amit konkrétan az előbb meg is erősítettél. -
vicze
félisten
Értem, hogy elolvastad a DPDK marketinganyagot nagyszerű. Értem a flexibilitását és a használhatóságát, de egy HW gyorsított rendszer elég nyilván valóan 10x-100x sebesség növekedés, ezt nem értem miért nem lehet megérteni.
Dedikált HW minding gyorsabb lesz és a DPDK is használ gyorsítókat, akár GPU-t is.
pfSense is DPDK használ 7éve, semmi extrát nem nyújt, csak state of the art teljesítményt ennyi.Mutatnál egy darab switchet/routert, ami Linux HW gyorsítás nélkül?
x86_64 ha nagyon akarod, de semmiképp se x86, mert az már nem létezik vagy 10éve(mióta nincs 32bites Atom), általánosan x64-nek van rövidítve.
-
válasz
bambano #32601 üzenetére
azért a teljesség kedvéért azt tegyük hozzá, hogy nem ez a stable kernel, amit ma Debianéktól megkapsz, hanem ez:
lenry@Echo-Five:~$ cat /proc/version
Linux version 5.10.0-18-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.140-1 (2022-09-02)illetve ez a múlt havi, mert azóta nem indítottam újra, de az aktuális se sokkal újabb
-
bambano
titán
"BSD szintekkel gyorsabb routing és fűzfalban": amikor utoljára néztem a bsd-t (nem mostanában volt), akkor volt benne egy nagy kernel lock meg egy single threaded tűzfal. úgy nagyjából 12-15 évvel volt lemaradva a linux kerneltől hálózati szempontból.
ezt behozták már?
"Nem a Linux végzi és nem az x64 végzi a routingot semmilyen formában": de, mikrotiken (ami a thread kezdő állítás volt) és pc-kből épített routerekben a linux és az x86 végzi a routingot.
-
bambano
titán
ez a desktopom, amin most írok:
cat /proc/version
Linux version 6.0.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-7) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.3-1 (2022-10-21)én azért ezt a kernelt nem nevezném visszatartásnak.
az meg, hogy a linux lassan vagy gyorsan fejlődik, egyéni vélemény. szerintem folyton kapkodnak.<írtam egy hosszabb hsz-t, de inkább kimoderáltam magam>
Új hozzászólás Aktív témák
Hirdetés
- Beszámítás! Apple iPad 11 2025 128GB WiFi tablet garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- Xiaomi Redmi Note 13 Pro+ 512GB, Kártyafüggetlen, 1 Év Garanciával
- LG 48GQ900-B - 48" OLED - 4K 3840x2160 - 138Hz & 0.1ms - G-Sync - FreeSync - HDMI 2.1
- Telefon felvásárlás!! iPhone 13 Mini/iPhone 13/iPhone 13 Pro/iPhone 13 Pro Max
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest