lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev [PATCH 2.8.3.dev4] More verbose transfer stats


From: Klaus Weide
Subject: Re: lynx-dev [PATCH 2.8.3.dev4] More verbose transfer stats
Date: Fri, 23 Jul 1999 07:51:31 -0500 (CDT)

On Fri, 23 Jul 1999, Ilya Zakharevich wrote:

> This patch 
>   a) makes size/transfer rate reports use format "8.3 KB" (instead
>       of "8 KB") if numbers are below 10 KB and reports are in KB;
>   b) makes transferred/expected/transfer-rate use bytes/KB independently
>      so "236 bytes of 56 KB" is possible, as is
>       "8.3 of 56 KB, 456 bytes/sec";
>   c) adds "ETA 23 sec" info if available;
>   d) adds " (stalled for 75 sec)" info if available (updated each 5
>      sec or so);
>   e) uses gettimeofday() if present (instead of current hacks) to get more
>      frequent updates.
> 
> The longest message I have seen is
> 
> Read 12 of 19 KB of data, 116 bytes/sec (stalled for 77 sec), ETA 57 sec.

Uhmm, I hope this can be made so it can be turned off.

Btw. even if you care for all this additional info: the data it's based
in is quite unreliable / arbitrary.  It doesn't count all bytes in
a HTTP message.  It is undefined where in the byte stream counting starts.
It is undefined where timing starts.  See HTTP.c, where the first
block(s) read may be handled differently.

The total length is counted differently than the current length.  To be
comparable, start of counting should be triggered (or reset) in HTMIME.c,
after the HTTP header has been parsed.

Temporarily suspend a loading-in-progress (^Z, or possibly ESC key may
do that; or try a binary type and wait a bit till you answer the 'download
or cancel prompt'), and the numbers are meaningless.

So this gives the impression of exact numbers, but it's misleading.
For my taste, it also reminds to much of Netscape...


   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]