Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
Pensato per il professionista sempre in movimento, HP Elitebook Ultra G1i 14 abbina una piattaforma Intel Core Ultra 7 ad una costruzione robusta, riuscendo a mantenere un peso contenuto e una facile trasportabilità. Ottime prestazioni per gli ambiti di produttività personale con un'autonomia lontano dalla presa di corrente che permette di lavorare per tutta la giornata
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Basato su piattaforma Qualcomm Snapdragon X Plus a 8 core, il nuovo Microsoft Surface Pro 12 è un notebook 2 in 1 molto compatto che punta sulla facilità di trasporto, sulla flessibilità d'uso nelle differenti configurazioni, sul funzionamento senza ventola e sull'ampia autonomia lontano dalla presa di corrente
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 03-11-2009, 20:02   #21
elevul
Senior Member
 
L'Avatar di elevul
 
Iscritto dal: Apr 2006
Città: Bassano del Grappa
Messaggi: 10431
Quote:
Originariamente inviato da II ARROWS Guarda i messaggi
Esatto Gainder, proprio quello che stavo pensando io...

Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.
__________________
"Non perdiamo di vista le vere priorità, l'economia serve a sostenere le vite, non devono essere le vite gli strumenti per sostenere l'economia." Conte Zero
Ipsa scientia potestas est
elevul è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 20:17   #22
ice_v
Senior Member
 
L'Avatar di ice_v
 
Iscritto dal: Dec 2008
Città: Oderzo
Messaggi: 2867
Quote:
Originariamente inviato da Superboy Guarda i messaggi
Cavolo la tua Adsl va più forte della mia rete locale


...ma LOL
ice_v è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 20:40   #23
Perseverance
Senior Member
 
L'Avatar di Perseverance
 
Iscritto dal: Jul 2008
Messaggi: 8155
Quote:
Originariamente inviato da elevul Guarda i messaggi
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.
Domanda. Perché implementare ipv6? Quali vantaggi darebbe?
__________________
System Failure
Perseverance è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 21:38   #24
Severnaya
Senior Member
 
L'Avatar di Severnaya
 
Iscritto dal: Apr 2005
Messaggi: 2544
da piccolo giocavo a throttling throttling cavallino
Severnaya è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 22:07   #25
fraussantin
Senior Member
 
L'Avatar di fraussantin
 
Iscritto dal: May 2009
Città: toscana
Messaggi: 50740
Quote:
Originariamente inviato da elevul Guarda i messaggi
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.
Quote:
Originariamente inviato da Perseverance Guarda i messaggi
Domanda. Perché implementare ipv6? Quali vantaggi darebbe?
quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??
__________________
MY STEAM & MY PC
"Story in a game is like story in a porn movie. It's expected to be there, but it's not that important." - John Carmack.
fraussantin è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 22:17   #26
ciccio er meglio
Senior Member
 
L'Avatar di ciccio er meglio
 
Iscritto dal: Sep 2001
Messaggi: 4832
Quote:
Originariamente inviato da fraussantin Guarda i messaggi
quoto perche ipv6?? che centra?? non serve per aumentare il numero di ip che sis sta esaurendo??
non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...
__________________
Amareggiato per la chiusura di mezzo forum Off-topic. Riapritelooo!
ciccio er meglio è offline   Rispondi citando il messaggio o parte di esso
Old 03-11-2009, 23:51   #27
nudo_conlemani_inTasca
Senior Member
 
L'Avatar di nudo_conlemani_inTasca
 
Iscritto dal: Jan 2005
Città: Gotham City
Messaggi: 1597
Quote:
Originariamente inviato da g.luca86x Guarda i messaggi
Il traffico torrent può creare problemi di occupazione della banda nel resto del pianeta ma non in Italia. Stando alle statistiche di speedtest.net siamo tra gli ultimi in europa e nel mondo civilizzato per banda disponibile in upload, 83° con 44kb/s in upload (in upload siamo 44°). Perciò ben vengano queste tecnologie che ottimizzano la congestione del traffico sulla rete, sperando ci sia la rete. E dire che ho una 8 mega che viaggia sempre, anche nel cuore della notte a 6,56 Mb/s in down ma in upload non supero i 55kb/s. E mi ritengo ultra abitando a Torino... quando sto in Calabria dai miei invece è una pena perchè tele2 (leggi vodafone) castra pesantemente il traffico torrent... Sarebbe meglio trovare un modo di offuscare completamente il protocollo...
E ti lamenti?
E io che devo navigare col cellulare.. sulla carta vanno più veloci della ADSL cablata terrestere.. nella realtà manco 1MBit/s! (se non salta direttamente in UMTS.. e ciao ciao)

Spiegatemi una cosa, visto che esistono 50 clients torrent differenti (se non di più) con diverse funzionalità, tra cui DHT;
come facciamo a sapere da quale versione e quali clients supporteranno questa nuova funzionalità del protocollo UTP???

Io uso abitualmente 3 Clients torrent (e sono quelli che ad oggi mi hanno dato maggiori soddisfazioni) su Win ovviamente.

In ordine di merito: µTorrent 2.10, BitSpirit 3.60 (che ha la patch integrata per portare le porte halfopen @256) e BitTirant (che però usa il Frame 2.0).

Come leggerezza µTorrent (200KB), consumo risorse esiguo e velocità rimane imbattibile a mio avviso,
poi nella scheda avanzate (advanced) è possibile migliorare i parametri interni del client P2P e farlo correre ancora di più (sono disponibili su youtube) basta cercare

Come si fa a sapere se i clients più utilizzati adotteranno questa nuova funzionalità?
__________________
"Il modding è una forma d'arte, assolutamente vero".
¤ ¤ Come portare Firefox oltre in muro del Suono! ¤ ¤ (Guida) //coming next //
nudo_conlemani_inTasca è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 08:10   #28
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da sna696 Guarda i messaggi
ma nel protocollo TCP/IP c'è già il controllo sulla congestione... O_O
No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.
Quote:
Originariamente inviato da marcurs Guarda i messaggi
Capito...
Mi pare che esista già qualcosa del genere rimanendo a livello di rete senza coinvolgere il protocollo bittorrent, mi pare si chiami DCCP, che integra un meccanismo di congestion control, è connection oriented come il tcp (3-way handshake per l'istaurazione e il teardown), e con header corto e semplice per essere veloce come l'UDP... ma non so quanto sia diffuso (è un protocollo abbastanza nuovo, l'rcf dice 2006) ad oggi!
Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.
Quote:
Originariamente inviato da elevul Guarda i messaggi
Mah, dal mio modestissimo punto di vista prima di mettersi ad abbassare le velocità avrebbero dovuto provare ad applicare l'idea del p4p, e cioé una geo-localizzazione dei peer e, quindi, una diminuzione della distanza e dei nodi per cui il pacchetto deve passare, riducendo appunto anche la congestione.
Quote:
Originariamente inviato da ciccio er meglio Guarda i messaggi
non solo, migliora il routing con una migliore gestione del qos. Ha anche altre funzioni per la criptazione dei dati...però neanche io ho capito che vantaggi puo avere con bittorrent. COme fa a inviare i dati in broadcast? i route interrompono il dominio di broadcast, al massimo FORSE potrebbe usare il multicast...
Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.

Ultima modifica di cionci : 04-11-2009 alle 08:14.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 08:36   #29
ATi7500
Senior Member
 
L'Avatar di ATi7500
 
Iscritto dal: Nov 2002
Città: Budapest
Messaggi: 19133
Quote:
Originariamente inviato da JackZR Guarda i messaggi
In Giappone vanno a 160Mbps a 44€ al mese...
non c'e' bisogno di andare in estremo oriente, anche qui a Budapest ci sono quelle velocita' a quei prezzi..

io ho una 15Mbit/1.5Mbit a circa 16 euro al mese (pagati pure dalla compagnia dove lavoro )
__________________
Improvise, adapt, overcome.
ATi7500 è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 08:40   #30
g.luca86x
Senior Member
 
Iscritto dal: Dec 2008
Città: Torino
Messaggi: 1854
vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...
g.luca86x è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 08:50   #31
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da g.luca86x Guarda i messaggi
vi invito davvero a visionare le statistiche di speedtest.net per avere davvero i dati di velocità su tutto il pianeta e capirete come la 7° economia mondiale possa essere 83° per velocità delle linee...
Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 09:27   #32
Stefano Villa
Senior Member
 
L'Avatar di Stefano Villa
 
Iscritto dal: May 2009
Città: Cesate
Messaggi: 443
Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!
Stefano Villa è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 09:33   #33
ciccio er meglio
Senior Member
 
L'Avatar di ciccio er meglio
 
Iscritto dal: Sep 2001
Messaggi: 4832
Quote:
Originariamente inviato da cionci Guarda i messaggi
No, il TCP ce l'ha. Per TCP/IP si intendono tutti i protocolli che si appoggiano ad IP, quindi si intende tutto lo stack di internet.

Ma non serve, nel senso che probabilmente in BitTorrent non volevano aggiungere un altro livello di incapsulamento, volevano solo modificare il proprio protocollo, i cui pacchetti vengono incapsulati in UDP.


Il problema principale in questo caso è la congestione causata sul provider congestionato dalla quantità di pacchetti inviata dal client in upload. Il client BitTorrent tentava di saturare la connessione in upload. Questa saturazione provoca però necessità di scartare pacchetti sul router.
I buffer dei router si basano sul concetto di leaky bucket. Immaginiamoci il buffer come un secchio forato sul fondo, il flusso che esce dal fondo sono i dati che il router riesce a gestire.
Se il secchio si piena i dati cominciano a venire scartati tutti, se il secchio si sta pienando si usano algoritmi di congestion avoidance per scartare intelligentemente i pacchetti in modo da indurre i client ad abbassare il rate di invio dei pacchetti.
Il TCP supporta il congestion control e quindi reagisce in modo prevedibile, il traffico UDP può invece non reagire in modo prevedibile se nel protocollo incapsulato su UDP non c'è il controllo di congestione. Questi client continueranno quindi ad inviare pacchetti al rate massimo dell'upload, andando a peggiorare la situazione del buffer del router, ma, non solo, andranno anche ad interagire su tutte le altre sessioni TCP o UDP del router provocandone il throttling.
Ed è proprio per questo che i provider hanno aggiunto il traffic shaping. Limitano il traffico identificando in qualche modo il flusso dati (o direttamente il traffico UDP) ad una certa percentuale della connessione di uscita. In questo modo ogni flusso o tipologia di flusso ha un proprio leaky bucket con dimensione e rate limitati. Quindi diventa chiaro che la maggior parte del traffico che verrà scartato sarà quello del P2P.

Riguardo all'IP multicast, purtroppo la gestione delle classi multicast è troppo particolare per essere instaurata automaticamente a livello mondiale. Esistono però altri protocolli che tentano di sopperire a questa mancanza, ad esempio RTP, anche se viene più spesso usato in unicast.
visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione
__________________
Amareggiato per la chiusura di mezzo forum Off-topic. Riapritelooo!
ciccio er meglio è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 09:35   #34
ciccio er meglio
Senior Member
 
L'Avatar di ciccio er meglio
 
Iscritto dal: Sep 2001
Messaggi: 4832
Quote:
Originariamente inviato da Stefano Villa Guarda i messaggi
Ma sono io l'unico che 24\24 riesce a saturare sempre la banda in download senza alcun problema ???
Mahhhh !!! Certo che finchè la gente continua ad usare i router che danno in prestito gli ISP stiamo freschi !!!
ma quanto caxxo scarichi?

io ho gli hdd saturi
__________________
Amareggiato per la chiusura di mezzo forum Off-topic. Riapritelooo!
ciccio er meglio è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 09:43   #35
Stefano Villa
Senior Member
 
L'Avatar di Stefano Villa
 
Iscritto dal: May 2009
Città: Cesate
Messaggi: 443
Magari non 24 ore consecutive, anche se a volte è capitato.... ma a qualsiasi ora inizio ci voglio quei 5 minuti per andare a regime e poi non si scosta mai dal 90% della banda disponibile.... e fino a quando avevo il router di alice queste velocità me le potevo solo sognare !!!
Stefano Villa è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 09:56   #36
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da ciccio er meglio Guarda i messaggi
visto che udp non fa alcun controllo di flusso e va a creare questi problemi perchè non usano tcp? Se non ricordo male il problema del tcp era la maggiore lentezza a causa del fatto che prima di inviare i dati si deve instaurare una connessione tra trasmettitore e ricevitore. Inoltre il tcp usa gli acknoledgement e quindi è tendenzialmente piu lento dell'udp. Però se non ricordo male TCP tende a incrementare la finestra di trasmissione e ricezione (aumentando la finestra di trasmissione e ricezione si arriverà ad un momento in cui non ci sarà attesa per l'ack e si avrà trasmissione continua)gradualmente quindi a lungo andare si comporta come l'udp con il vantaggio di poter controllare la congestione
Perché gestire un peer che invia tanti messaggi a tanti altri peer è troppo complesso con TCP. Senza contare che, pur se l'overhead per un singola sessione TCP è piccolo, per una moltitudine di connessioni TCP è molto alto.
Le primitive messe a disposizione per UDP sono semplicissime: sendto e recvfrom e lavorano direttamente sugli indirizzi ip.
UDP permette quindi di personalizzare al massimo il protocollo, ecco perché viene usato in praticamente tutti i protocolli P2P.
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 10:00   #37
ciccio er meglio
Senior Member
 
L'Avatar di ciccio er meglio
 
Iscritto dal: Sep 2001
Messaggi: 4832
ma quindi anche il controllo di errore viene fatto a livelli piu alti?
__________________
Amareggiato per la chiusura di mezzo forum Off-topic. Riapritelooo!
ciccio er meglio è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 10:31   #38
cionci
Senior Member
 
L'Avatar di cionci
 
Iscritto dal: Apr 2000
Città: Vicino a Montecatini(Pistoia) Moto:Kawasaki Ninja ZX-9R Scudetti: 29
Messaggi: 53971
Quote:
Originariamente inviato da ciccio er meglio Guarda i messaggi
ma quindi anche il controllo di errore viene fatto a livelli piu alti?
Viene fatto il controllo di errore sul protocollo BitTorrent ?
Il controllo di errore che io sappia nel BitTorrent viene fatto a livello di chunks e non a livello di pacchetto. Quindi se una volta che il chunk viene completato il fingerprint è errato, il chunk viene eliminato e richiesto nuovamente ai peer.
Quindi nel protocollo non solo non c'è la correzione dell'errore, ma nemmeno la possibilità di verificare la presenza di un errore.

UDP ha un checksum, addirittura credo che possa venire ignorato (trasmettendo tutti 1) oppure semplicemente viene riportato un errore del checksum al ricevente. Il problema è che il ricevente, a meno che non abbia una singola sessione UDP aperta, non può affidarsi al pacchetto con checksum errato per determinare l'indirizzo ip dal quale proviene il pacchetto, infatti il checksum è calcolato sul pacchetto UDP e su parte dell'header IP (compresi gli indirizzi). Quindi anche l'indirizzo IP potrebbe essere errato

Il nuovo sistema di controllo di congestione sembra che si affidi ad un semplice timestamp per la stima del round trip time. Imho ci saranno due campi in più nel protocollo BitTorrent, un bit da mettere ad 1 che attiva uTP ed un campo opzionale in cui andare ad inserire il timestamp del mittente.
Il ricevente quando trova il campo uTP ad 1 prende il timestamp e lo invia nuovamente al peer che lo aveva generato. In questo modo si riesce a stimare il tempo che ci impiega il pacchetto per andare ad un peer e tornare indietro. Ovviamente c'è congestione se questo tempo aumenta troppo o se la risposta non ritorna (entro un opportuno timeout proporzionale al RTT stimato precedentemente).
cionci è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 12:21   #39
Perseverance
Senior Member
 
L'Avatar di Perseverance
 
Iscritto dal: Jul 2008
Messaggi: 8155
OK ho capito ma ricapitolando; la congenstione del traffico provoca la perdita dei pacchetti che devono essere inviati reiterate volte sul protocollo UDP, il quale non prevede nessun meccanismo anti-traboccamento. Il nuovo protocollo uTP permetterebbe di inviare intelligentemente i pacchetti agli utenti non saturi e limitare il reinvio agli utenti saturi.

Grazie a questo cosa migliorera?

La velocità di download dipende dalla velocità di upload dell'altro utente, quindi al massimo si scaricherà come ora. Xò il fatto di inviare i pacchetti alle persone giuste permette di incrementare le prestazioni solo nel caso di congestione. Questo protocollo infine non è per aumentare la velocità di download\upload in generale, ma specificamente nel caso in cui ci sia una congestione.

Staremo a vedere...
__________________
System Failure
Perseverance è offline   Rispondi citando il messaggio o parte di esso
Old 04-11-2009, 12:45   #40
JackZR
Senior Member
 
L'Avatar di JackZR
 
Iscritto dal: Feb 2009
Città: Forlì
Messaggi: 3688
Quote:
Originariamente inviato da II ARROWS Guarda i messaggi
Secondo me dovrebbero pensare delle idee del tipo inviare alcune parti in broadcasting... in modo che se 100 utenti devono scaricare una stessa parte, io la mando in broadcast a tutti questi spendendo solo 10kB/s in upload ma in download diventa 1 000 kB/s.
Indubbiamente andare in Multicast sarebbe molto più comodo per tutti, magari un giorno...

Quote:
Originariamente inviato da elevul Guarda i messaggi
Aka usare tutti l'IPV6. Ottima idea, Arrows!
Sono serio. Manda un'email ai tizi di utorrent, magari la mettono in pratica.
Ma penso che ci stiano già lavorando visto che presto (2011) si comincerà ad usarlo e non troppo più tardi (2025) l' IPv4 morirà...

Quote:
Originariamente inviato da cionci Guarda i messaggi
Il problema nostro non è la banda concessa dai provider. Il nostro problema è la non capillarità delle centrali e l'antiquatezza degli impianti dell'ultimo miglio. Sono tutti problemi che costringono ad usare la metà ed a volte anche un terzo della banda che concederebbe il provider.
C'è troppa gente che dista oltre 3 km dalla centrale o che pur essendo molto più vicina è costretta a non poter raggiungere la portante massima perché ci sono problemi sulla rete di distribuzione (ad esempio giunti fatti male o giunti che raccolgono i segnali AM).
Abito a neanche 500m in linea d'aria dalla centrale e godo solo di 13 mega su 20 che ne pago
__________________
In My Humble Opinion
Tutto quello che scrivo è IMHO!
JackZR è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
Recensione REDMAGIC Astra Gaming Tablet: che spettacolo di tablet! Recensione REDMAGIC Astra Gaming Tablet: che spe...
Dopo un mese, e 50 foto, cosa abbiamo capito della nuova Nintendo Switch 2 Dopo un mese, e 50 foto, cosa abbiamo capito del...
Alchimia? No, scienza: ecco come produrr...
Il CISPE chiede di annullare l'acquisizi...
La Now Bar supporterà il doppio d...
Vecchi Bitcoin, guadagno mostruoso: bale...
Nel 2018 Samsung snobbò NVIDIA: u...
Provare i vestiti senza mai uscire di ca...
SanDisk High Bandwidth Flash (HBF): un c...
Panasonic presenta Aquarea DHW, pompa di...
Il bracciale Meta leggerà i gesti...
iOS e Android sotto attacco: per l'antit...
A Verona dopo i monopattini ecco le e-bi...
Itch.io come Steam: al bando i giochi pe...
Digitalizzazione, identità e AI: ...
Kindle Colorsoft: arriva la versione da ...
Electra ottiene altri 433 milioni di eur...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 16:50.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Served by www3v
1