Re: [Bug-wget] mistakes in performance-view

[Andreas Matthus]

Hallo Tim,

many of thanks. This parameter solved my problem nearly. Now only a few
points over the theoretical maximum and all of them have a neighbor with
the same distance under the maximum - the average of both seams the
really value ;-) (see the blue points "BZW")

with regards
Andreas

Am 09.05.2016 um 11:23 schrieb Tim Ruehsen:
> Hi Andreas,
>
> please always answer to the mailing list (optionally put me on CC, but not 
> really needed).
>
> Wget outputs one line every 50k of data. On fast lines this makes many 
> "measurements" / calculations per second. A slight jitter in packet delivery 
> (e.g. CPU or IO busy for 0.1s) leads to totally unreliable values. It is just 
> a 'best guess' from wget - from what it sees right at that moment.
>
> What you want or need might be
> --progress=dot:mega
> (see man wget)
>
> That should average the calculations good enough.
>
> Tim
>
> On Sunday 08 May 2016 21:43:10 Andreas Matthus wrote:
>> Hallo Tim,
>>
>> yes, the summery is O.K., but the values in succession arn't.
>>
>> I make a wget-connection in our campus with a filesize a litle bit over
>> 1 GB. I want to see the performance over all parts of the transfer - not
>> only the summery. To preclude teh disk-speed the target is /dev/null.
>> The pakages go over a lot of switches an cables. Some of them only use
>> 100 Mb/s, but on the endpoints of the test-infrastructure are 1000
>> Mb/s-networkcards and switches. In this way the maximal flow-rate is
>> capped by 100 Mb/s - with possibility of a little variance by caching in
>> the switches. But "little" is not so big I see in the messure. Is this
>> understandable?
>>
>> With regards
>> Andreas
>>
>> Am 07.05.2016 um 19:45 schrieb Tim Rühsen:
>>> Hi Andreas,
>>>
>>> just taking the values from the your attached log:
>>>
>>> $ awk "BEGIN {print (1174405120 / 1024 / 1024 / 103)}"
>>> 10.8738
>>>
>>> Wget said:
>>> 2016-05-06 13:25:10 (10,8 MB/s) - »»/dev/null«« gespeichert
>>> [1174405120/1174405120]
>>>
>>> That seems to be perfectly fine.
>>>
>>>
>>> Is it a 100 MByte/s or MBit/s line - this seems not clear to me because
>>> you
>>> explicitely tell us about 1000baseT-FD. On the other hand you complain
>>> about seeing speeds >12MB(yte)/s...
>>>
>>> What *exactly* do you 'measure' ? Or do you just read the value from
>>> '2016-05-06 13:25:10 (10,8 MB/s) - »»/dev/null«« gespeichert
>>> [1174405120/1174405120]' ?
>>>
>>> Regards, Tim
>>>
>>>
>>> Dipl.-Phys. Andreas Matthus
>>> Netzwerkadministrator
>>>
>>> Technische Universität Dresden
>>> Fakultät Architektur
>>> 01062 Dresden
>>> Tel.: +49 (351) 463-33909
>>> Fax: +49 (351) 463-36120
>>> E-Mail: address@hidden


-- 

Dipl.-Phys. Andreas Matthus
Netzwerkadministrator

Technische Universität Dresden
Fakultät Architektur
01062 Dresden
Tel.: +49 (351) 463-33909
Fax: +49 (351) 463-36120
E-Mail: address@hidden

t0-lo-mz.jpg
Description: JPEG image

smime.p7s
Description: S/MIME Cryptographic Signature