Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione Google Pixel 10a, si migliora poco ma è sempre un'ottima scelta
Recensione Google Pixel 10a, si migliora poco ma è sempre un'ottima scelta
Google ha appena rinnovato la sua celebre serie A con il Pixel 10a, lo smartphone della serie più conveniente se consideriamo il rapporto tra costo e prestazioni. Con il chip Tensor G4, un design raffinato soprattutto sul retro e l'integrazione profonda di Gemini, il colosso di Mountain View promette un'esperienza premium a un prezzo accessibile. E il retro non ha nessuno scalino
6G, da rete che trasporta dati a rete intelligente: Qualcomm accelera al MWC 2026
6G, da rete che trasporta dati a rete intelligente: Qualcomm accelera al MWC 2026
Al MWC Qualcomm annuncia una coalizione industriale per lanciare il 6G entro il 2029 e introduce agenti IA per la gestione autonoma della RAN. Ericsson, presente sul palco, conferma la direzione: le reti del futuro saranno IA-native fin dalla progettazione
CHUWI CoreBook Air alla prova: design premium, buona autonomia e qualche compromesso
CHUWI CoreBook Air alla prova: design premium, buona autonomia e qualche compromesso
CHUWI CoreBook Air è un ultraleggero da 1 kg con Ryzen 5 6600H, display 14" 16:10 e 16 GB LPDDR5. Offre buona portabilità, autonomia discreta e costruzione in alluminio, ma storage PCIe 3.0 e RAM saldata limitano l'espandibilità. A 549 euro sfida brand più noti nella stessa fascia di mercato.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 25-05-2009, 13:02   #1
ally
Bannato
 
L'Avatar di ally
 
Iscritto dal: Jan 2003
Città:
Messaggi: 4423
[Java] OutputStream limitare la banda di uscita...

...ciao...

...come da titolo avrei la necessità di imporre un limite nell'utilizzo della banda da parte di un OutputStream...la soluzione che sto usando ora è quella di aggiungere uno sleep ad ogni invio del buffer. Questo modo pero' mi crea un andamento a dente di sega ed inolte non mi permette di limitare in maniera precisa la banda utilizzata...

...idee per una possibile soluzione?...

...ciao Andrea...
ally è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:04   #2
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Potresti usare un BufferedOutputStream.
Tale classe fornisce un costruttore che ti permette di specificare la grandezza in byte del buffer interno.

Quando si inviano in scrittura dei byte a tale BufferedOutputStream, questi in realtà non vengono spediti allo stream sottostante finchè possono essere appesi al buffer interno; quando si raggiunge il limite di capacità del buffer interno, questo viene "flushato" cioè i byte che contiene vengono effettivamente inviati allo stream sottostante (il che in genere significa generare attività di sistema).

Se tu puoi stabilire la grandezza del buffer interno (usando l'apposito costruttore), puoi in pratica porre un 'tetto limite' al numero massimo di byte scritti ognivolta che parte nell'effettivo un'operazione di scrittura.

Il fatto è che per controllare il numero massimo di bytes spediti in un certo lasso di tempo dovresti estenderti BUfferedOutputStream e dotarlo di un timer o analogo che non permetta di flushare il buffer interno se non è passato un intervallo di tempo stabilito dall'ultimo flush.

Se viene invocato un flush, e l'intervallo stabilito deve ancora passare, bisognerà comunque memorizzare i dati inviati da qualche parte, per non perderli, per esempio con una riallocazione con copia del buffer di byte interno (per esempio raddoppiando le dimensioni, oppure usando un altro fattore che viene specificato al momento della creazione dello stream).

In questo caso bisogna assicurarsi che l'operazione di flush scriva sempre lo stesso quantitativo di bytes [tranne nell'ultimo flush, quello che viene fatto tipicamente all'invocazione del metodo di chiusura di uno stream], in modo che in caso di riallocazione del buffer interno comunque si scrivano nello stream sottostante sempre lo stesso numero di bytes.

Non so se in linea di massima è quello che cercavi...

Ti allego un link al codice di java.io.BufferdOutputStream, guardando il quale mi è venuta in mente la soluzione che ti ho abbozzato.

Probabilmente esistono medoti migliori, ma io non saprei.
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 26-05-2009 alle 09:08.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:29   #3
fero86
Senior Member
 
Iscritto dal: Oct 2006
Città: Roma
Messaggi: 1383
Quote:
Originariamente inviato da ally Guarda i messaggi
...ciao...

...come da titolo avrei la necessità di imporre un limite nell'utilizzo della banda da parte di un OutputStream...la soluzione che sto usando ora è quella di aggiungere uno sleep ad ogni invio del buffer. Questo modo pero' mi crea un andamento a dente di sega ed inolte non mi permette di limitare in maniera precisa la banda utilizzata...

...idee per una possibile soluzione?...

...ciao Andrea...
piazza un FilterOutputStream, conta i bytes che viaggiano e se superano il limite di bytes al secondo attendi lo scatto della prossima "finestra" di gestione temporale.

lo rispiego meglio

hai un thread a parte che scatta ogni secondo e ogni volta che scatta parte questa "finestra" di gestione della banda che dura un secondo.

poi nella tua implementazione di FilterOutputStream hai un campo intero che é un contatore che dice il numero di bytes di banda ancora disponibili per quella finestra temporale.

nel FilterOutputStream tu hai sovrascritto la versione fondamentale di write che scrive un solo byte (quella che viene richiamata da tutte le altre versioni, poi se vuoi fare un'implementazione piu efficiente sovrascrivi anche tutte le altre); il codice della tua write controlla il valore del contatore dei bytes rimasti: se é zero blocca il thread fino alla prossima finestra temporale, altrimenti lo decrementa di uno ed invia il byte.

dettagli:
1. come viene inizializzato il contatore? precisamente al valore della banda di upload che tu vuoi concedere
2. quando viene inizializzato il contatore? viene resettato al valore di banda in upload ad ogni "scatto di finestra"
3. come fare all'interno della write, quando il contatore é zero, ad attendere che arrivi una nuova finestra e che quindi il contatore ritorni al valore di banda concessa? banalmente attendi su un oggetto qualunque col metodo Object.wait; l'altro thread, quello che "da il passo", chiama Object.notify ogni volta che scatta una finestra, non prima di aver resettato il contatore naturalmente.
fero86 è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:30   #4
ally
Bannato
 
L'Avatar di ally
 
Iscritto dal: Jan 2003
Città:
Messaggi: 4423
...grazie per la risposta...ma nell'OutputStream faccio già uso di un buffer impostato da me...il problema è che periodicamente stoppare il flush del buffer con uno sleep per limitare la banda in uscita dando sulla rete un utilizzo a dente di sega : picco di invio e pausa > picco di invio e pausa > etc...cercavo un modo piu' elegante per rendere l'invio uniforme e bloccato ad una velocità specifica...

...ciao Andrea...
ally è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:34   #5
fero86
Senior Member
 
Iscritto dal: Oct 2006
Città: Roma
Messaggi: 1383
altro consiglio: per far si' che questo tuo FilterOutputStream venga effettivamente utilizzato potresti creare delle tue sottoclassi di Socket e ServerSocket i cui metodi getOutputStream restituiscono il tuo FilterOutputStream costruito al di sopra di super.getOutputStream().
potrebbe anche essere il caso di rimpiazzare la socket factory predefinita.
fero86 è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:37   #6
fero86
Senior Member
 
Iscritto dal: Oct 2006
Città: Roma
Messaggi: 1383
Quote:
Originariamente inviato da ally Guarda i messaggi
...grazie per la risposta...ma nell'OutputStream faccio già uso di un buffer impostato da me...il problema è che periodicamente stoppare il flush del buffer con uno sleep per limitare la banda in uscita dando sulla rete un utilizzo a dente di sega : picco di invio e pausa > picco di invio e pausa > etc...cercavo un modo piu' elegante per rendere l'invio uniforme e bloccato ad una velocità specifica...
l' "invio uniforme" non esiste per natura di TCP/IP: comunque sia il software alla fine raccoglie tutto e quando ha raccolto abbastanza manda un pacchetto intero.

secondo me attendere del tempo dopo ogni invio non é affatto una cattiva soluzione, peró la variante che ti ho proposto io é un po' piu elegante perché anziché attendere un tot esatto di tempo tra un invio e l'altro attendi solo il tempo che resta affinché cominci la nuova finestra temporale.
fero86 è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:41   #7
banryu79
Senior Member
 
L'Avatar di banryu79
 
Iscritto dal: Oct 2007
Città: Padova
Messaggi: 4131
Quote:
Originariamente inviato da ally Guarda i messaggi
...il problema è che periodicamente stoppare il flush del buffer con uno sleep per limitare la banda in uscita dando sulla rete un utilizzo a dente di sega : picco di invio e pausa > picco di invio e pausa > etc...
Proprio per questo motivo avevo ipotizzato l'utilizzo non del FilterOutputStream ma di un BufferedOutputStream (che poi è un'estensione di FilterOutputStream) customizzato nella gestione del flushing del buffer interno...

@EDIT:
magari non è importante ma il fatto è che, se non erro, la chiamata ai metodi write è bloccante, per quello ho preferito evitare ma in effetti non è detto che col buffer te la cavi meglio; meriterebbe una prova empirica però.
__________________

As long as you are basically literate in programming, you should be able to express any logical relationship you understand.
If you don’t understand a logical relationship, you can use the attempt to program it as a means to learn about it.
(Chris Crawford)

Ultima modifica di banryu79 : 25-05-2009 alle 17:44.
banryu79 è offline   Rispondi citando il messaggio o parte di esso
Old 25-05-2009, 17:46   #8
ally
Bannato
 
L'Avatar di ally
 
Iscritto dal: Jan 2003
Città:
Messaggi: 4423
Quote:
Originariamente inviato da banryu79 Guarda i messaggi
Proprio per questo motivo avevo ipotizzato l'utilizzo non del FilterOutputStream ma di un BufferedOutputStream (che poi è un'estensione di FilterOutputStream) customizzato nella gestione del flushing del buffer interno...
...si scusa e scusate...il caldo miete vittime...devo controllare in maniera migliore il rilascio del buffer...ora attendo il raggiungimento del valore massimo per l'unita di tempo (1s) prima di entrare entrare eventualemente nello sleep...giustamente dovrei controllare il rilascio del buffer ad ogni passaggio per evitare il picco di utilizzo di banda...analizzando così l'invio dei dati in porzioni di tempo inferiori...

...ora...si spera...mi è chiaro...

...grazie Andrea...
ally è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Recensione Google Pixel 10a, si migliora poco ma è sempre un'ottima scelta Recensione Google Pixel 10a, si migliora poco ma...
6G, da rete che trasporta dati a rete intelligente: Qualcomm accelera al MWC 2026 6G, da rete che trasporta dati a rete intelligen...
CHUWI CoreBook Air alla prova: design premium, buona autonomia e qualche compromesso CHUWI CoreBook Air alla prova: design premium, b...
Roborock Saros 20: il robot preciso e molto sottile Roborock Saros 20: il robot preciso e molto sott...
ASUS ROG Kithara: quando HIFIMAN incontra il gaming con driver planari da 100mm ASUS ROG Kithara: quando HIFIMAN incontra il gam...
Costo della memoria alle stelle? Non ave...
GPT-5.4 cambia il modo di usare ChatGPT:...
Centinaia di petabyte in una molecola: l...
Lenovo al MWC 2026: dal PC modulare all'...
Huawei presenta gli agenti di IA per le ...
Alla scoperta di GAIA, la piattaforma IA...
Crimson Desert alla ricerca dell'equilib...
Ray-Ban Meta, video privati visionati da...
Epic Games fa causa a un ex collaborator...
BYD Blade Battery di seconda generazione...
Pop Mart vs Bambu Lab: la battaglia lega...
Control Resonant entra nella fase alpha ...
1.040 Hz e tecnologia Mini LED: TCL sfid...
Smart retail: arrivano le soluzioni di H...
MOVA, guida all'acquisto per scegliere i...
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: 06:15.


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