Întrebări pe care ni le punem de mult
- Thread starter takeda
- Start date
Stai că acum am citit că e vorba de mai multe camere în mașini diferite. E același alimentator sau nu? Cel mai simplu ecranaj e din niște caserole de aluminiu de la raionul de ambalaje alimentare de unică folosință din hipermarketul preferat 
Devine foarte stealth o cameră înfășurată în aluminiu. 
burebista
Manic Miner
Vin acasa, dau drumu' la computer, lansez War Thunder si intru in joc...dupa fo' 10 minute.
Dafuq?
Ies, ma uit in Task Manager si un exe cu nume ciudat imi tine procesorul in 100% acompaniat de altele citeva plus niste servicii care nu-mi aduc aminte sa le fi vazut vreodata.
Dau drumul la o scanare cu MBAM, iese curat.
Dafuq?
Instalez 360 Total Security, full scan si iese un pomelnic plin de paduchi.
Dafuq?
Intreb consoarta si ea imi spune candida ca aseara in timp ce io ma delectam cu niste seminte la Teveu ea a deschis nu's ce atasament de la un mail de la nu stiu cine ca scria acolo ceva de oferta la Cora si era un pdf in arhiva si l-a deschis da' nu s-a intimplat nimic.
Intr-adevar aseara nu s-a intimplat nimic. Azi s-a intimplat.
De cind am calculator in casa n-am avut niciun virus dar se pare ca pentru toate e un inceput asa ca am sa las dracia asta chinezeasca sa ruleze in legea ei acolo.
Dafuq?
Ies, ma uit in Task Manager si un exe cu nume ciudat imi tine procesorul in 100% acompaniat de altele citeva plus niste servicii care nu-mi aduc aminte sa le fi vazut vreodata.
Dau drumul la o scanare cu MBAM, iese curat.
Dafuq?
Instalez 360 Total Security, full scan si iese un pomelnic plin de paduchi.
Dafuq?
Intreb consoarta si ea imi spune candida ca aseara in timp ce io ma delectam cu niste seminte la Teveu ea a deschis nu's ce atasament de la un mail de la nu stiu cine ca scria acolo ceva de oferta la Cora si era un pdf in arhiva si l-a deschis da' nu s-a intimplat nimic.
Intr-adevar aseara nu s-a intimplat nimic. Azi s-a intimplat.
De cind am calculator in casa n-am avut niciun virus dar se pare ca pentru toate e un inceput asa ca am sa las dracia asta chinezeasca sa ruleze in legea ei acolo.
Să înțeleg că tu și consoarta nu aveți conturi separate la calculator, și nici nu sunt restricționate ca user account ci rulezi totul ca Administrator? 
burebista
Manic Miner
Sigur. Foarte rar mai trece nevasta-mea pe la calculator ca in general e ocupat de domnu' cu WoT si/sau WT.
N-am AV si rulez totul ca un boss. De acu' o sa am AV da' tot pe cont de Admin.
Ideea e ca cel putin o data pe luna fac o imagine cu Macrium Reflect si mi se filfiie de virusii lor.
N-am AV si rulez totul ca un boss. De acu' o sa am AV da' tot pe cont de Admin.
Ideea e ca cel putin o data pe luna fac o imagine cu Macrium Reflect si mi se filfiie de virusii lor.
ursamajor
צָפְנַת פַּעְנֵחַ
Chiar mă întreb demult de ce utorrent downloadează uneori cu viteză de descărcare constantă și foarte bună (am atins și 20 MB/s), alteori într-o sinusoidă, cu rate variabile, până la zero chiar (pare că se oprește), apoi urcând la rate mari de ordinul MB/s. Necaz mare n-ar fi dacă sinusoida aia n-ar fi alungită în zona cu rate mici de descărcare. Care să fie explicația și rezolvarea?
Din cauză că nu ai de unde să obții detalii de la toți ceilalți cu care comunici, plus rețeaua până la ei, e aproape imposibil să spui de ce merge cum merge (bine/prost).
Download-ul se face de la zeci de surse, cu lățime de bandă, încărcare și disponibilitate a bucăților (pieces) complet diferită, e clar că nu se poate garanta viteza de download. Prin definiție (descrierea procotolului), transferul e i/o intensive, pentru că se dorește împărțirea cât mai uniformă a bucăților, astfel încât să nu depinzi o perioadă lungă de seeder (care are toate bucățile și e single point of failure, se urmărește maximizarea distributed copies). Un client care trișează la download (ex: prin setarea de priorități pe anumite bucăți/fișiere, sau download-ul în ordine - "streaming" over bittorrent) va avea încărcare i/o mai mică, pentru că poate să scrie bucățile în ordine; dar tot nu poate să facă mare lucru când face upload, pentru că restul de clienți îi vor cere bucăți random => random i/o => întârzieri din cauza stocării. Cum nu prea ai cum să faci caching în memorie la fișiere mari, nu poți scăpa de acest random i/o.
Se poate optimiza prin piece size (atunci când se creează torrent-ul), astfel încât să nu fie foarte mici bucățile (adică nu ai nevoie să faci multe random writes/secundă, ex: 20MB/s la piece size 1MB => 20 writes/sec, piece size 2MB => 10 writes/sec, dacă n-ai noroc și a pus cineva un piece size de 256k => 80 writes/sec), dar pe de altă parte, dacă download-ul nu se termină cu succes la un piece size mare, ai pierdut mult timp de pomană - deci trebuie să existe un echilibru undeva. Cu un seek time uzual pe un HDD de 10-15ms și 20 w/s, numai partea de seek durează 30% din timpul de scriere/citire. Pe urmă mai pot exista limitări de rețea prin diverse locuri (ex: router/firewall), care să nu te lase să deschizi un număr mare de conexiuni dintr-o dată, ISP-ul să facă traffic shaping după cine știe ce criterii, există și conceptul de poisoning, cu clienți care trimit intenționat pachete eronate etc. De exemplu, router-ul meu ajunge la 40MB/s în speedtest.net, dar dacă încerc multe conexiuni în paralel cu viteză mare, mai poate routa doar 30-35MB/s.
Unii clienți încearcă să maximizeze throughput prin păstrarea doar a conexiunilor care au viteză bună, dar asta înseamnă că trebuie să testeze - se conectează la altcineva, iau o bucată, dacă merge prost caută în altă parte - iar astea costă timp la negocierea conexiunilor, transmiterea hărților de pierces și apoi cererea efectivă.
Download-ul se face de la zeci de surse, cu lățime de bandă, încărcare și disponibilitate a bucăților (pieces) complet diferită, e clar că nu se poate garanta viteza de download. Prin definiție (descrierea procotolului), transferul e i/o intensive, pentru că se dorește împărțirea cât mai uniformă a bucăților, astfel încât să nu depinzi o perioadă lungă de seeder (care are toate bucățile și e single point of failure, se urmărește maximizarea distributed copies). Un client care trișează la download (ex: prin setarea de priorități pe anumite bucăți/fișiere, sau download-ul în ordine - "streaming" over bittorrent) va avea încărcare i/o mai mică, pentru că poate să scrie bucățile în ordine; dar tot nu poate să facă mare lucru când face upload, pentru că restul de clienți îi vor cere bucăți random => random i/o => întârzieri din cauza stocării. Cum nu prea ai cum să faci caching în memorie la fișiere mari, nu poți scăpa de acest random i/o.
Se poate optimiza prin piece size (atunci când se creează torrent-ul), astfel încât să nu fie foarte mici bucățile (adică nu ai nevoie să faci multe random writes/secundă, ex: 20MB/s la piece size 1MB => 20 writes/sec, piece size 2MB => 10 writes/sec, dacă n-ai noroc și a pus cineva un piece size de 256k => 80 writes/sec), dar pe de altă parte, dacă download-ul nu se termină cu succes la un piece size mare, ai pierdut mult timp de pomană - deci trebuie să existe un echilibru undeva. Cu un seek time uzual pe un HDD de 10-15ms și 20 w/s, numai partea de seek durează 30% din timpul de scriere/citire. Pe urmă mai pot exista limitări de rețea prin diverse locuri (ex: router/firewall), care să nu te lase să deschizi un număr mare de conexiuni dintr-o dată, ISP-ul să facă traffic shaping după cine știe ce criterii, există și conceptul de poisoning, cu clienți care trimit intenționat pachete eronate etc. De exemplu, router-ul meu ajunge la 40MB/s în speedtest.net, dar dacă încerc multe conexiuni în paralel cu viteză mare, mai poate routa doar 30-35MB/s.
Unii clienți încearcă să maximizeze throughput prin păstrarea doar a conexiunilor care au viteză bună, dar asta înseamnă că trebuie să testeze - se conectează la altcineva, iau o bucată, dacă merge prost caută în altă parte - iar astea costă timp la negocierea conexiunilor, transmiterea hărților de pierces și apoi cererea efectivă.
lauru'_balauru'
Membru Senior
Sau poate downloadezi in cache pana se umple dupa care iti intra discul in overload, se mai goleste un pic cache-ul si iar creste viteza pana cand s-a umplut din nou si asteapta iar dupa disc.
ursamajor
צָפְנַת פַּעְנֵחַ
Da, nu cred să fie vorba de saturare la 20 MB/s. Modem și placă Gigabit există. HDD-ul poate mult mai mult și nici nu-l folosesc decât la maximum navigat pe net când descarc cu utorrent. miahi a pus punctul pe i. Demonstrația lui pare plauzibilă. Eram contrariat doar de faptul că uneori merge constant cu rată mare, alteori după "algoritmul" prezentat. Cu atât mai mult cu cât peering fac cu zeci de useri rds (filelist), eu fiind tot rds-ist.
Multumiri!
Multumiri!
Mie îmi merge excepțional de rapid când mai prind un peer în RDS, și bagă pe țeavă cât poate. Altfel, scopul protocolului e de a diversifica totul pentru a lipsi un single point of failure, și atunci această varietate induce și o variație concurentă a mai multor factori, cu rezultate neprevizibile.