Windows 8.1 x64 versus 6,5-7MB/s letöltés.

 ( tartyom | 2013. november 12., kedd - 17:40 )

Egy elég idegesítő problémával állok szemben. Ha nagy (kizárólaglegálisteljesenjogtiszta) torrent állományokat töltök le, akkor a használhatatlanságik befagyasztja a Windows-t a torrent letöltés. Értem ez alatt a 5Giga feletti letöltéseket. Egy 5400rpm-es HDD-m van és ez mellé párosul 6,5-7MB/s letöltési sebesség, de már 4MB/s-nél is kezd betárcsázós / IE6 lefagyós lenni minden oldal.

Először az uTorrent-re gyanakodtam (3.3.2 final), hogy a "Lemez túlterheltség 100%"-os dolog lesz a gond, de nem. Ha nagyobbra tettem a Cachet (1024MB) akkor is fennállt a hiba (Használhatatlan lett a gép, szó szerint. Egy feladatkezelőt nem lehetett megnyitni 10 perc alatt). Utána feltettem a 3.1.3 (final)-t ott szintén jelen volt ez a hiba, de annyira nem volt teljes lehalás mint 3.3.2-nél.

Most egy Halite nevű klienssel próbálkozom, ami ismét jobb mint az uTorrent, de itt is ha töltök 4MB/s környékén, akkor egy hup.hu főoldal megnyitás 15mp (holott van még szabad 3 MB/s), illetve egy egyszerű 480p-s videó nézése abból áll, hogy 10mp-es időközökkel megakad a hang 1-1mp-re. Itt is hiába rakom fel a cache méretét nagyobbra, (pl 512) 8-10 mb-nál többet nem használ a kliens. Nem megoldható, hogy automatikusan RAM-ba mentse a letöltött fájt(okat) és onnan valami nyugodt tempóval írja ki a HDD-re, a fagyásokat elkerülendő?

A HDD-m egy Toshiba MQ01ABD075 (750GB).

KIEG: Ahogy nézem, nem csak a HDD-t akasztja be, hanem a procit is 100%-os pörgeti sokszor, de miért? Egy 2 magos AMD A4-3305M van a gépben

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szia,
Első ötletként felvetném, hogy próbáld meg nem torrentel elérni ezt az IO limitet. ( a megnövekedő I/O kb. az egész OS-re kihat, így lehet, ez dobja meg a CPU használtságot is )
Ha ott nem akad meg ennyinél, akkor lehet tovább nézni, például, hogy valamivel elkezdesz perzisztens kapcsolatokat generálni (pl. ncat-el)...
Persze ezek csak ötletek a tesztelésre, és mindenezek előtt szimplán a SMART adatokat nézném meg személy szerint :)
Üdv,
LuiseX

Milyen gépről van szó? Milyen hardverek vannak benne?

Hp Probook 4535s

Régi emlékeim szerint nem a le-, hanem a feltöltés tudja igazán belassítani a netet. A diszk meg olyan, amilyen...

--

A Windows 8.1 lecserélése megoldaná a dolgot.

Mire, Win8-ra?

Használtad egyiket is huzamosabb ideig?

Nem okoskodást kértem szerintem.

A jopfának szánt, de rosszindulatúnak tűnő okoskodásnak az értelmezése a következő:
- Miközben nem használtem még ilyen rendszert, de nem is fogok.
- Abban az esetben, ha minden erőforrás egyszerre összecsinálja magát két eset lehetséges:
-- device driver hiba (kérdés, hogy melyik az amelyik a diszket, hálózatot és cput is egyzerre leterheli - ez általában az oprendszer)
-- hardver hiba - ennek a megállapítása célszerűen rendszerfüggetlen
-- pótlehetőség: a torrent program ravasz módon elszúrt beállítása, de ez kizárható másik program kipróbálásával

Megoldás:
a) Képes vagy diagnosztizálni mi eszi meg az összes erőforrást egyszerre. = megoldás
b) Nem vagy képes, vagy csak azon a rendszeren, amit használsz nem vagy képes. Ekkor másik rendszert kell használni, amin könnyedén megtalálható a hiba oka. = megoldás

Azért egy jól beállított, jól működő rendszeren nem tipikus a leírt jelenség.

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
http://www.thesycon.de/deu/latency_check.shtml

Probald ki hasonlo savszelessegu, de nem torrent forgalommal is.
Szar halokartya driver siman okozhat ilyesmit, par eve rengeteget szivtam desktop Intel kartya+2008R2 kombinacioval, hasonlo jelensegeket produkalt: nagyobb halozati forgalom mellett hasznalhatatlanna valo gep.

Nézegettem a dolgokat, és arra jutottam, hogy csak bittorrent-nél áll fenn ez a probléma. Ha valamilyen oldalról töltök le, akkor semmit sem lassít a 7MB/s körüli letöltés, szinte észre sem lehet venni.

A hálókártya drivert downgradeltem (tipp alapján), mert eddig egy WHQL verzió volt fenn, nem az úgymond "stabil", illetve Process Hacker-el csak a 2. magot engedélyeztem a Halite-nek (torrent kliens) és úgy néz ki egyre használhatóbb a dolog.

Szia!

Szerintem szimplán elérted a disk teljesítmény határát. A torrent sok apró részt mozgat és ezt a HDD-k nem tudják rendesen kiszolgálni. Egy átlag HDD 100 IOPS-t tud. Egy torrent esetén pedig lehet 5-600 kapcsolat is egyszerre, javasolnákm lecsökkenteni az egyidejű kapcsolatokat, de inkább az a jó megoldás ha rendszer SSD-n fut és a HDD-re mennek az ilyen dolgok, bár esetedben ez nem biztos hogy megoldható.

Üdv
S

Azt valahogy nem lehet elérni, hogy ne tudja 100%ban használni a HDD-t a torrent kliens? Maximum 80%-ban használhassa vagy valami hasonló, hogy ne ez kapja a legnagyobb prioritást.

Nyomd le a prioritását Task Managerben. Nem tudom hogy disc IO-ra is vonatkozik e, de simán megeshet.

Ja, és ugyancsak Task Managerben van egy olyan tab, hogy "Details". Itt jobbklikk a fejlécre, majd "Select Columns". Válaszd ki az I/O opciókat és nézegesd hogy mennyit eszik a torrent kliens.

Lightosabbá egyébként úgy is teheted, hogy meghatározod hány torrentet tartson aktívan, illetve max hány kapcsolatot engedélyezzen.

Lekorlátozod a letöltési sebességed mondjuk 2M-ra. :)

Próbáld meg a 2.0.4-es uTorrenttel (az advanced beállításokban ellenőrizd, hogy a diskio.no_zero értéke true legyen)!

A legtöbb torrent kliensben van olyan opció, hogy a letöltés megkezdésekor azonnal foglalja le a letöltéshez szükséges tárhelyet. Kapcsold be, sokat jelent, így legalább az NTFS se törik csillió kis darabra.

Attól, hogy nem tölti fel előre a fájlokat nullákkal, még nem lesz töredezett. Ha nullákkal feltölti előre, akkor is ugyan úgy azokra a helyekre tud írni, ahol van szabad szektor.
Attól tényleg meg tud halni a lemez (és a programok), ha egyszerre tele akarunk írni egy X GB-os fájlt.

Még csak nullákkal sem kell feltétlen feltölteni, pár fájlrendszer ismeri a preallocation-t (ext4, xfs, az NTFS nem tudom).

Mondjuk feltölti nullákkal. Megmondja a program az OS-nek, hogy én ki szeretnék írni egy X GB-os fájlt. Az OS I/O ütemezője keres neki egy lehetőleg teljesen összefüggő területet a lemezen, majd ahogy töltődik le a fájl, úgy írja felül a nullákat.

Ha nem foglal le magának helyet, akkor az I/O ütemező szétdobál(hat)ja a részeket, mert még / már nem tudja őket közel tenni egymáshoz vagy épp nem is tudja hogy összetartoznak. Ilyenkor még nincs is nagy baj, ott kezdődik a probléma mikor elkezd törölgetni a felhasználó. Lesz neki egy csomó de lukacsos helye. Itt pár byte, ott pár mbyte.. aztán jön a következő torrent, amiknél vagy sikerül feltölteni a helyeket, vagy nem és fragmentálja tovább a lemezt.

Arról nem is beszélve, hogy ha nagyrészt összefüggő adatterületre kell írni, akkor az adatok kiírása jó esetben pár fordulaton belül megoldható illetve elég memória mellett az I/O ütemező is mondhatja hogy egy kicsit később írja ki az adatokat, mert előtte még molyol valamit egy közelebbi szektorcsoportban.

A torrentes világtól elszakadva, egy preallocation meglepően sokat dob egy virtualizált környezet sebességén is.