> between .start() and the first .update() which contains data is "dead > time", and you get misleadingly low N MB/s numbers that have to build > up to the correct value.
Yes, but this *is* part of the request processing.. If excluded, rate estimator believes that first chunk (16kB, usually) took 0 ms, and when 2nd chunk arrives, it actually reports 2x the real speed. URLGrabber updates progress meters BOTH from _retrieve() and _progress_update() callbacks. _retrieve() compensates for this (current buffer length is not included in amount read), but _progress_update() does not. > Using MultiProgress might change all this too. I've used the same "delayed" start() logic there, too. But that IF in .update() path feels ugly, and instead of copy-pasting this to .end() path too, to fix BZ 831904, I'd rather get rid of it. The "mirror profiler" uses independent timing, as we need it to work with meter=None, too :) It's done in downloader to elliminate latency of IPC, and stuff like master process running "checkfunc" callbacks, but I DO include connection setup, too (trt, IMO). _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
