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

• #23926 MasterMark titán enginev3.0 #23925

  Új Válasz 2018-05-09 18:36:09 #23926

  Ú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

  

  MasterMark

  titán

  válasz enginev3.0 #23925 üzenetére

  Pont ezt kérdeztem én is tegnap, de nembaj.

  szerk.: Najó, nem pont ezt, de hasonlót. Egyébként egyikre sem találtam megoldást.

  [ Szerkesztve ]

  Switch Tax

• #23931 TeeJay félisten enginev3.0 #23925

  Új Válasz 2018-05-09 19:51:38 #23931

  Ú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

  

  TeeJay

  félisten

  válasz enginev3.0 #23925 üzenetére

  az olvasások és írások egyesítése legyen benyomva
  azzal nem fix 16kb chunk mérettel tölt hanem normálisan

  niner ncore-on összefoglalta szépen
  idézem

  "szóval teszteltem sorban a 3.3.16, 4.0.4, és a 4.1 klienseket. direkt késő éjjel teszteltem egy IPT-ről letöltött gyors torrenttel, ahol legalább 50 feltöltő volt és letöltő nem.

  a gép: WIN7 Pro 64 bit, I7-4790, 8 GB RAM, Seagate 2 TB 7200 rpm HDD, frissen formázott legnagyobb 64 KB-os foglalási egységgel. más torrent nem futott csak a tesztelésre használt, illetve minden más felesleges folyamatot bezártam.
  a digi sebességmérője és a speedtest ~915 Mbps-ot mért.
  a teszt torrent mérete 16,2 GB volt.

  3.3.16:
  Prefer TCP protokoll, OS cache bekapcsolva, lemez gyorsítótár 1 GB (bár nincs jelentősége), lejárati idő az alapon, 60 mp.

  letöltési sebesség:
  második helyezett.

  3 perc 30 másodperc alatt végzett. ez átlagosan 617 Mbps.
  a tempó viszonylag egyenletes volt, de ahogy máskor is tapasztaltam, bizony előjön/előjöhet, hogy az írási cache megtelik, és néhány másodpercre drasztikusan "beszakad" a letöltés.

  cpu használat:
  első helyezett.

  átlagosan 8.62% volt, a max. 12,28%.
  megjegyzem, hogy a cache betelése javított az átlag értéken, mert abban az időszakban alig volt cpu terhelés.

  4.0.4:
  Prefer TCP protokoll, OS cache bekapcsolva, lemez gyorsítótár 1 GB (bár nincs jelentősége), lejárati idő az alapon, 60 mp.

  letöltési sebesség:
  harmadik helyezett.

  3 perc 45 másodperc alatt végzett. ez átlagosan 576 Mbps.
  nem meglepő módon ez volt a leglassabb, hiszen a 4-es verzió megjelenése óta ismert hiba volt a hatalmas letöltési sebesség ingadozás.

  cpu használat:
  harmadik helyezett.

  átlagosan 13% volt, a max. 18%.

  4.1:
  Prefer TCP protokoll, OS cache bekapcsolva, lemez gyorsítótár 1 GB (bár nincs jelentősége), lejárati idő az alapon, 60 mp. Fontos! a Speciális beállításokban Az olvasások és írások egyesítése (ezzel az opcióval már nem 16 KB-os chunk méretekkel dolgozik végre) és az Okos olvasási tár be volt pipálva. csak letöltésre (write) teszteltem, de természetesen seed-elésre (reading) is hatalmas előnnyel jár ez a módosítás, sokkal-sokkal gyorsabb mindkét művelet ezáltal.-->később fullad ki a HDD.

  letöltési sebesség:
  első helyezett.

  2 perc 54 másodperc alatt végzett. ez átlagosan 744 Mbps.
  mintha sínen húznák. a 3.3.16-hoz képest még azért nagyobb tüskék vannak (mármint abban a sávban, amikor a nincs cache problémája a 3.3.16-nak), de összességében egész egyenletes. github-on utána olvasva azt találtam, hogy még mindig nem tökéletes, optimalizálva lesz még. én már a jelenlegi állapottal is nagyon-nagyon elégedett vagyok, de legyen így

  cpu használat:
  második helyezett.

  átlagosan 10,77% volt, a max. 13,96%.
  figyelembe véve, hogy sokkal gyorsabb letöltési sebességben, mint a 3.3.16 és ahogy említettem a 3.3.16-nál a cache betelése során a cpu üresben járt másodpercekig, így én közel azonosnak ítélem meg a terhelést cpu oldalról. "

  képek pedig itt : [link]

  amikor csak OS cache-t nyomtam be és okos olvasási tár nem volt benyomva akkor 60% fölé is ment a RAM használat
  ha mindkettő be van nyomva akkor csak írás esetén emelkedik ez meg utána ha befejeződött a letöltés visszaáll normális RAM használatra
  ez így nagyon pengén működik

  persze mint írtam sok helyen olvastam már hogy a win7 cache kezelése borzalmas lehet ott sosem fog jól menni
  win10 x64 1803 alatt tökéletes
  ma nekem már 789GB-os seedelt és még van 4óra a napból

  Mixgyűjteményem ---> https://www.mixcloud.com/teejayhouse/

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