Mennyi CPU kell egy letöltéshez...

Hát, úgy látszik hogy ez egy nagyon megterhelő feladat, letölteni pár fájlt (steam, épp töltöget).

 

CPU

CPU

( uid_6201 v | 2020. 11. 07., szo – 08:48 )

Ryzen 5 3xxx 25% ...
Belegondolva hogy ez a proci mennyivel több számítást végez akár egy szálon, sőt a mostani több szálon is ... és akkkor is le tudtunk tölteni 25%-os terheléssel.

https://www.cpubenchmark.net/compare/AMD-Ryzen-5-3600-vs-VIA-Eden-1000M…

Ha belegondoltok, kicsiben viccesnek tűnik de picit jobban utánagondolva egy általános, milliószám használt szoftvernél az hogy a számítógépek odafigyelve megírt általános szoftverei wattokkal kevesebbet fogyasztanak, az környezetvédelmi kérdést is felvet, hiszen a megújuló energián felül a többit még mindig szenes és gázturbinás erőmű állítja elő.

( uid_4263 v | 2020. 11. 07., szo – 09:10 )

Szerkesztve: 2020. 11. 07., szo – 09:11

Attól hogy a felületen azt írja hogy letöltés és te úgy gondolod nem csinál semmi mást, attól még az nem biztos hogy úgy van :)

Például a nagyobb adatokat letöltő alkalmazások rendszerint preallocatelik a helyet, hogy ne legyen töredezett a fájlrendszer (igaz ennek SSD esetén nincs értelme).

Tehát lehet hogy letölt, de közben előre nullázza neked a gb-okat a disken.

Annek idején ~17 évesen nagyon utáltam azt a jelenséget hogy a utorrent -em húsz percekre kiakasztja a gépemet, és mindenféle orvosságot kerestem rá, aztán rájöttem hogy a root problem a preallocate. Persze azok még HDD-idők voltak.

Szívesen. Ha valaki használt már Steam-et, az tudja, hogy igen, csinál ilyet, mármint hogy előre lefoglalja a helyet.

És igen, sokan vannak azon a véleményen, hogy ez már felesleges.

A különbség, hogy a torrent alkalmazásokban (már amit én használok) ezt lehetőség van a helyzetnek megfelelően akár ki is kapcsolni (nálam pl. ki van kapcsolva).

( zeller | 2020. 11. 07., szo – 10:51 )

Az iowait-et hova számolja vajon...?

Hát... nekem az tűnt fel, hogy zúg a gép mint egy hajszárító, mondom megint csak háttérbe tettem a gémet. Aztán látom, hogy nem.

Nem tudom mennyire tekerné az iowait, diskre nem nagyon kell várnia (ssd), ha meg az izzasztja meg ennyire, hogy izgatottan várja a packeteket... hát, az se jobb :(

iowait az a modern operációs rendszereknél nem while (1) { olvasáspróba(); } hanem kernelbeli read() hívás, aholis ha a kernel nem tudja kiszolgálni, akkor félreteszi a processzt. A kernel pedig ha valami hardver adja az adatot, akkor szintén altathatja a CPU-t, hiszen a hardver majd tol neki interrupt-ot akár vett adatnál, akár akkor ha már lehet írni adatot a hardver küldő pufferébe.
Szóval idle-re íródik és a CPU alszik, pillanatnyilag kisfogyasztású módba kerül.

Szóval idle-re íródik és a CPU alszik

Az rendben van, hogy a CPU nem fogyaszt, nem dolgozik, de arra azért ne vegyél mérget, hogy ezt idle-ba számolja!

Pl. nekem rendszeresen előfordult a régi NAS használatával, hogy az NFS-en felmountolt cucc soká (percekkel később) válaszolt. Ilyenkor ha elindítottam mondjuk egy ls parancsot, akkor az bekerült D állapotba, és a top 25% processzor használatot írt ki (4 magból 1 100%-on). A top-ban a 25% nem az id(le) alatt, hanem a wa(it) alatt látszott.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Bindenhez? ;)

Vajon a CPU ír-e a diszkre? A én régi gépemben még a DMA.

Vajon a diszk sebessége kisebb vagy nagyobb, mint az internet sebessége?

Helyes válasz: Windows+szar program=csak?

A terhelés időtartama a letöltéshez képest?

Le is lehetne tölteni a Process Explorert, amivel sokkal többet látnánk.

A várakozásnak nem kéne CPU-t fogyasztania.

Vajon miért kell várni a tcp-stackre? Úgy étem, ha várni kell valamire meg még valamire is, akkor a CPU változatlan, esetleg csökken. Vagy olyan gyors az internet, hogy gyorsabb, mint a cpu és a diszk?

Te talán elhiszed nekem, hogy kb. 0 idő alatt kapcsolódok egy usb eszközre, a kolléga meg 30s. És el sem hiszi, hogy gyorsabban is lehet. Én inkább a szkeptikus irányvonalat erősíteném. ;)

Az Ötvös Kinga, meg a Process Explorer megmutassa thread/dll/io/network szinten, hogy mi fogyaszt. Pl. a régi firefox (XP) 4-15% CPU, álló helyzetben, 1:4 system:user arányban. Ha ezzel töltök le, az is sokat fogyaszt. :-D

Az elejét nem nagyon értem.

A többi... az elméleti sebesség 300 megabit, ssd-re tölt, nem hiszem hogy ott lenne szűk keresztmetszet.

Én az eszetlenül megírt alkalmazásra tippelek, nagyon sok olyat látok, amit mintha csak írnának, de soha nem próbálnák használni (vagy a másik lehetőség, nem a használhatóság az elsődleges szempont).

A terhelés időtartama kb. ugyanannyi mint a letöltés, a végén, a "valódi telepítésnél" persze felszalad, de ez nyilván magyarázható.

Pontosan mit kéne látni, vagy nézni? Hasonló számokat kapok, bár épp mást töltök.

Az elején (Binden kivételével ;)) arra utaltam, hogy a DMA az nem CPU, tehát nem fogyaszthat CPU-t. Legfeljebb a memória/diszk sávszélességet csökkentheti, esetleg a CPU elől elveszi a teljesítményt. De ez sem valószínű, mert a program meghívja a diszk írást, aztán megvárja a visszatérést. Ezalatt a program (thread) áll.  A hálózatról olvasás is hasonlóképpen működik. Semmi izzadás, csak megkapsz egy buffernyi adatot, amivel utána dolgozhatsz.

A Process Explorerrel ráállhatsz a programra. A tulajdonságoknál a therad és dll terhelésből következtethetsz arra, hogy mi az, ami terhel. Úgyanúgy a processz performace adatok között látszik az user és system CPU idő. Ha a system nagy (itt nincs wait), akkor a fentiek alapján pl. meghívott a program egy diszk írást, de várakozik rá, mert a diszk lassú.

Szerintem a program írói készítették a lassúságot. ;)

Fura dolgot vettem észre. Most egy kisebb játékot kezdtem el letölteni (9G), és 3-4% CPU körül mocorog a terhelés. A méretbeli különbség mellett 140 és 1600 2200 fájl (a Steam az ellenőrzésnél azt írja, hogy 1/1) a két játék, ez is "segíthet".

Tipikusan user time amit használ (nahát).

A két esetben nincs szignifikáns különbség a threadek és http csatlakozások között, szóval tippre kb. ugyanannyi szálon tölt.

A kiírt adatmennyiség összemérhető az uplink ("az internet") sebességével, picit több, talán a tömörítés segít neki, vagy van valami overhead, majdnem mindegy.

Ugyanazok, a tier0_s.dll -ből származó threadek eszik a CPU-t mindkét esetben.

Most már végképp elvesztettem az érdeklődésemet, túl gyorsan telik a hétvége, hogy még ilyenkor is ilyesmikkel foglalkozzak :D

A System Idle process miatt is sokan nyafiznak*. Szerencsére van rá megoldás.

De ami a lényeg, már elengedtem a problémát, így is sokkal-sokkal több időt és figyelmet szenteltem rá, mint amennyit megér.

*) Mielőtt valaki azt gondolná hogy ez kamu: oké, ez a konkrét példa lehet hogy az, de saját szememmel láttam céges belsős ticketet, hogy a windows team legyen szíves valamit csinálni, mert lassú a gép, és a system idle folyamatosan terheli a gépet. Illetve átlag havonta rí valaki, hogy linux, kevés a memória (párszáz mega) az akár két terából is. Az senkit nem zavar, hogy százgigabájtok vannak az FS cache-ben, és gyakorlatilag nincs swap (paging) aktivitás.

( Fisher v | 2020. 11. 07., szo – 12:38 )

Szerkesztve: 2020. 11. 07., szo – 12:39

-

( p2pking | 2020. 11. 07., szo – 13:58 )

iowait irq es a tobbiek hálózati forgalom csunya loadot tud generálni a processzorokon.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

A "loadavg" nem okoz fogyasztást, ott csak arról van szó hogy hány kiszolgálatlan processzed van.
Amíg vár az I/O-ra, addig kiszolgálatlan, de ahogy fent írtam, a kernel amíg a hardver IRQ-ra vár, addig altatja a CPU-t.
Tehát ahogy gondolod, "loadavg" magas (külső hardverre vár a rendszer), de közben a CPU terhelés alacsony, altatva van.
 

( asch v | 2020. 11. 07., szo – 19:20 )

Szerintem integritás ellenőrzést csinál: hashel vadul. Ha egy slukkra csinálja sok gigára, az CPU igényes.

Az megvan 15-16% CPU-ból, és jól láthatóan olvasásra terheli a disket.

De amúgy lehet hogy valami ilyesmi van mögötte, minden letöltött darabkát hashel, elölről hátulra, hátulról előre, meg még középről is. De figyelembe véve hogy 300 megabit a bejövő sávszélesség, ezt se érzem elegendő magyarázatra.

( Mobulla | 2020. 11. 07., szo – 19:54 )

Nagy eséllyel a shader előtöltés dolgozik, az tekeri időnként. (Menü: Steam/beállítások/Shader előtöltés)
Nekem két szálat is leterhel néha, de csak 10-15 percig kb.

( Toma_ | 2020. 11. 08., v – 10:07 )

Nem lehet, hogy a vírusírtó is dolgozik? (nem vagyok nagy W10 user, nem használom)

(Anno, amikor a "szarul dekódolja a videót a böngésző" tesztet csináltam, akkor futottam bele ebbe (durván megnyomta a cpu terhelést a videó letöltése, ezért teszteltem inkább offline), be is kerültem a hup memebe vele. :D )