Newsgroup: it.comp.macintosh
Titolo: Programma di dload con log

Ciao a tutti,
devo fare delle prove di dload con provider diversi; chi mi sa
consigliare un programma che 000generi un log di cio' che ha scaricato?
Mi servirebbe il tempo di dload e la media in Kb/sec.
Ho dato un'occhiata ad Anarchie, Monica, IE 4.5 ma non mi sembra che
tengano un log...
Suggestions?
Grazie!!!
-- 
Best regards - And(y)
http://www.dexmedia.com
remove ANTISPAM!!

On Tue, 8 Jun 1999 13:15:40 +0200, ama...@ANTISPAMdexmedia.com
(And(y)) wrote:
| Ciao a tutti,
| 
| devo fare delle prove di dload con provider diversi; chi mi sa
| consigliare un programma che 000generi un log di cio' che ha scaricato?
| Mi servirebbe il tempo di dload e la media in Kb/sec.
| Suggestions?
ping... ma siamo OT
oha

 ping... ma siamo OT
;-))
pingare pingo, ma avrei bisogno altri riscontri...
Ciao e grazie!


 tengano un log...
Mi pare che Anarchie tenga un log ("transcript"), da cui puoi ricavare
la velocita` media. 
Altrimenti si puo` fare qualcosa con Applescript: in "idle" ogni secondo
chiede a Fetch (o chi altro) quale file si sta scaricando; se e` diverso
da quello del secondo prima, si inizia un nuovo conteggio. 
-- 
Ciao,        \+----------+  "La risposta e ` dentro di te...
   Vittorio --| : )    o |      ...MA E` SBAGLIATA!!!"
             /+----------+
+-----------------------------------------------------------+
| Votate per creare    il gruppo it.comp.os.macintosh.hardware |
|     CFV: it.news.annunci --> e` un post del 12 maggio     |
+-----------------------------------------------------------+

 wrote:
| 
| > | Mi servirebbe il tempo di dload e la media in Kb/sec.
| > 
| > | Suggestions?
| > 
| > ping... ma siamo OT
| 
| ;-))
| 
| pingare pingo, ma avrei bisogno altri riscontri...
ping -s 1300
ping -s 50000 
;)
a parte gli scherzi, cosa vuoi sapere? non penso che una trasmissione
ftp sia molto significativa.
oha

 wrote:

Magari mi sbaglio ma credo che il ping misuri il tempo di risposta (o
tempo di latenza), mentre in un ftp voglio misurare l'effettivo
throughput. 
Ieri sera con Fetch e Applescript ho fatto delle prove (ancora senza
creare il log, solo leggendo il result) ma mi succede una cosa strana:
comunque la metta, il risultato di throughput che mi dice l'applescript
e` sempre inferiore di una ventina di bytes/sec. a quello che Fetch mi
dice nella finestra... cosa puo` essere? 
-ho provato a dividere sia per 1024 che per 1000 ma un certo scarto
resta sempre.
-ho provato anche a chiedere i dati in ordine differente, casomai la
diff fosse causata dal tempo intercorso fra quando ho chiesto i bytes
arrivati e quando ho chiesto il tempo trascorso. Niente. 
Qualche idea? Ecco lo script finora: 
----
tell application "Fetch 3.0.3"
set n to (count each window)
set lalista to {}
repeat with i from 1 to n
try
set l to the hostname of transfer window i
set the end of lalista to l
on error
end try
end repeat
set q to (count items of lalista)
if q < 2 then
set primoTest to true
else
set primoTest to false
display dialog "Chiudi tutti i transfer tranne uno e riprova!"
end if
--return primoTest
set w to transfer window 1
set x to the current item of w
set u to the current directory of w
set s to the hostname of w
set z to approximate item size of w
set e to elapsed transfer time of w
set t to bytes transfered of w
set spid to (t / e)
--return {s, u, x, z, t, e}
return (round ((t) / (e / 60)))
end tell
----


end tell
anche questo... poteva diventare:
set cosa to tranfer window 1
return (round((bytes transferrd of cosa)*60/ ¬
  (elapsed transfer time of cosa)))
Se poi il tutto usa idle meglio ancora, ma tu usi uno scan semplice
"one-shot" per sapere come va ora... Vediamo un po', io lo avrei
affrontato cosi':
------------------------------------------------------------------------
on run
  tell application "Fetch 3.0.3" to try
    get the hostname of transfer window 2
    -- se il comando non da errore prosegue
    display dialog "Troppi xfer!"
    tell me to quit
  on error
    try
      get the hostname of transfer window 1
      set cosa to tranfer window 1
    on error
      display dialog "Neanche un xfer!"
      tell me to quit
    end try
  end try
  -- se sono qui c'e' un solo xfer
  tell application "Fetch 3.0.3" to ¬
    round((bytes transferrd of cosa)*60/ ¬
     (elapsed transfer time of cosa))
  return the result
end run
on quit
  continue quit
end quit
------------------------------------------------------------------------
Perche' tutto cio'?
Perche' la struttura di try..on error..end try e' molto piu'
efficiente e veloce (leggi: rompe meno le scatole) di qualunque test o
calcolo di AS. Se poi consideri che le tell vanno a Fetch...
------
bale...@dada.it
 
http://zap.to/balestra
  ICQ#:14303012
" Ora mai che i baci tuoi piu' non mi sazian
  cerchero' un'altra donna dentro ai sogni di Tarzan... "

 ftp sia molto significativa.
beh, se devo convincere un provider che e' lento rispetto ad un altro e
gli faccio vedere che l'ftp in down e up di un file di 5 mega ci mette
il doppio rispetto al suo concorrente!


 da quello del secondo prima, si inizia un nuovo conteggio. 
mmm... troppo complicato ;-)))
Grazie!


 wrote:
| 
| 
| > | pingare pingo, ma avrei bisogno altri riscontri...
| > 
| > ping -s 1300
| > 
| > ping -s 50000 
| > 
| > ;)
| 
| :-)
| 
| consigliami un prg Mac... Con AGNet Tools imposto solo il numero di
| ping, il delay e il timeout :(
| 
| 
| > a parte gli scherzi, cosa vuoi sapere? non penso che una trasmissione
| > ftp sia molto significativa.
| 
| beh, se devo convincere un provider che e' lento rispetto ad un altro e
| gli faccio vedere che l'ftp in down e up di un file di 5 mega ci mette
| il doppio rispetto al suo concorrente!
tecnicamente, io fossi in te farei un traceroute sui due host.
poi un centinaio o piu' di ping (alla stessa ora) e guarderei
attentamente se e quanti pacchetti perdo.
a quel punto dovresti essere in grado di vedere il collo di bottiglia
(aiutati con altri pings, se e' il caso)
l'ftp, a rigor di logica, dovrebbe cercare di saturare la tua banda, a
meno che i link non siano cosi' schifosi da perdere piu' del 3% dei
pacchetti o ci siano tempi di risposta superiori a 400ms.
se hai bisogno di aiuto, troviamoci su ircnet o efnet cosi' ti do' una
mano in tempo reale (qui siamo sempre piu' OT)
oha

On Wed, 9 Jun 1999 11:36:56 +0200, 
br...@flashnet.it
 (Vittorio
Barabino) wrote:
| Magari mi sbaglio ma credo che il ping misuri il tempo di risposta (o
| tempo di latenza), mentre in un ftp voglio misurare l'effettivo
| throughput. 
anche il numero di pacchetti persi, e fidati quando ti dico che se
usato come si deve, (leggi bing) si arriva addirittura (con gli ICMP)
a capire la massima banda applicabile sul link senza saturarla.
cya
oha

 calcolo di AS. Se poi consideri che le tell vanno a Fetch...
E` vero, e` vero... e non e` la prima volta che sbaglio!
Stasera ci riprovo ;-)
Grazie!!


 wrote:

Non sono esperto, ma "concettualmente" ;-) tempo di risposta, throughput
e pacchetti perso mi sembrano tre concetti correlati pero` ben distinti.


E` vero, e` vero... e non e` la prima volta che sbaglio!
E' anche vero che la try e' piu' brutta a leggersi..
Ciao!


 che preferisci, anche la malefica ScrollBar scriptable ;-)).
Questo stanotte ;-)
Grazie!!


 wrote:
| 
| 
| > >Ieri sera con Fetch e Applescript ho fatto delle prove (ancora senza
| > >creare il log, solo leggendo il result) ma mi succede una cosa strana:
| > >comunque la metta, il risultato di throughput che mi dice l'applescript
| > >e` sempre inferiore di una ventina di bytes/sec. a quello che Fetch mi
| > >dice nella finestra... cosa puo` essere? 
| > 
| > L'overhead del protocollo.
| 
| No no -- io vado a leggere i "bytes transfered" di Fetch, mica quelli
| del PPP!
non puo' essere LIST ?
tutti gli ftp client fanno queste verifiche
oha

On Wed, 9 Jun 1999 14:12:32 +0200, 
br...@flashnet.it
 (Vittorio
Barabino) wrote:
| Non sono esperto, ma "concettualmente" ;-) tempo di risposta, throughput
| e pacchetti perso mi sembrano tre concetti correlati pero` ben distinti.
vedendo la differenza nei tempi di risposta fra pacchetti di diverese
dimensioni e' possibile stabilire "empiricamente" la banda massima
supportata dal link
appunto bing (che e' sperimentale) fa' quasto usando gli stessi ICMP
di ping.
oha