Új hozzászólás Aktív témák

• #2020 chros őstag korcsi #2019

  Új Válasz 2017-04-29 18:51:36 #2020

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  chros

  őstag

  válasz korcsi #2019 üzenetére

  "Az mitől lehet, hogy nálam nincs hasznos kimenete a pidstat parancsnak?"
  rtorrent tobb sub-process indit, probald ki a tobbi PPID-et is: pl. 916. Ha van pillanatnyi feltoltesed, akkor latnod kell lemez-olvasast!

  "A beolvasott blokk (ami úgy tudom kis méretű is lehet 4KB szektorméretnél talán annyi), a torrent szeletméreténél kisebb"
  Alex is erre gondol, bar nem tudom pontosan mit ertunk blokk alatt.
  Ha minden igaz, rtorrent (libtorrent pontosabban) teljes torrent chunk-kal operal (ennek merete teljesen kulonbozo lehet, 256KB - 16MB) s nem szeletekkel. Elso korben valszeg ez a problema forrasa.
  Itt a hozzaszolas, amire fentebb hivatkoztam: [link]
  Mindez pusztan hipotezis, mindaddig, amig ez a bug ki lesz javitva (ha egyaltalan valaha ki lesz ).

  "ha az rtorrentnek nem is az operációs rendszernek illene gyorsító tárazni."
  Ezt pedig egyaltalan nem ertem Itt egy erre vonatkozo hozzaszolas: [link]

  " rTorrent is wasting insane amounts of I/O. Keep in mind rTorrent is wasting massive amounts of random i/o, not sequential, which compounds the issue as far as increasing overall disk I/O latency goes."

  "És most ugrott be, mi történik, ha a most megfigyelt érték nem a fizikai háttértár olvasásokat jelenti, hanem amikor onnan fér hozzá adathoz a program, bár az a gyorsítótár okán már a memóriában van"
  A teszt-parancsok a kernel altal szolgaltatott tenyleges lemez-olvasasi sebessegeket mutatjak.

  Es a fent emlitett 3x-4x olvasasi sebesseg csak a jeghegy csucsa, ami minden rendszernel jelentkezik, de ha pl. NFS halorol (pl NAS) seed-elsz, akkor ez az egekbe ugrik: [link] , [link] , [link]
  Igy ezt ne rtorrent-tel tegyuk!

Új hozzászólás Aktív témák