netdev - Re: [iproute2-next v1] devlink: display elapsed time during flash update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Sep 2020 14:55:57 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Jacob Keller <jacob.e.keller@...el.com>,
        Jakub Kicinski <kubakici@...pl>
Cc:     netdev@...r.kernel.org
Subject: Re: [iproute2-next v1] devlink: display elapsed time during flash
 update

On 9/30/20 2:43 PM, Jacob Keller wrote:
> On 9/30/2020 2:36 PM, Jakub Kicinski wrote:
>> On Wed, 30 Sep 2020 14:20:43 -0700 Jacob Keller wrote:
>>>> Thanks, Jake.  In general this seems to work pretty well.  One thing,
>>>> tho'...
>>>>
>>>> Our fw download is slow (I won't go into the reasons here) so we're
>>>> clicking through the Download x% over maybe 100+ seconds.  Since we send
>>>> an update every 3% or so, we end up seeing the ( 0m 3s ) pop up and stay
>>>> there the whole time, looking a little odd:
>>>>
>>>>       ./iproute2-5.8.0/devlink/devlink dev flash pci/0000:b5:00.0 file
>>>> ionic/dsc_fw_1.15.0-150.tar
>>>>       Preparing to flash
>>>>       Downloading  37% ( 0m 3s )
>>>>     ...
>>>>       Downloading  59% ( 0m 3s )
>>>>     ...
>>>>       Downloading  83% ( 0m 3s )
>> I'm not sure how to interpret this - are you saying that the timer
>> doesn't tick up or that the FW happens to complete the operation right
>> around the 3sec mark?
>>
>
> The elapsed time is calculated from the last status message we receive.
> In Shannon's case, the done/total % status messages come approximately
> slow enough that the elapsed time message keeps popping up. Since it's
> measuring from the last time we got a status message, it looks weird
> because it resets to 3 seconds over and over and over.
>
>>>> And at the end we see:
>>>>
>>>>       Preparing to flash
>>>>       Downloading 100% ( 0m 3s )
>>>>       Installing ( 0m 43s : 25m 0s )
>>>>       Selecting ( 0m 5s : 0m 30s )
>>>>       Flash done
>>>>
>>>> I can have the driver do updates more often in order to stay under the 3
>>>> second limit and hide this, but it looks a bit funky, especially at the
>>>> end where I know that 100% took a lot longer than 3 seconds.
>>>>    
>>> I think we have two options here:
>>>
>>> 1) never display an elapsed time when we have done/total information
>>>
>>> or
>>>
>>> 2) treat elapsed time as a measure since the last status message
>>> changed, refactoring this so that it shows the total time spent on that
>>> status message.
>>>
>>> Thoughts on this? I think I'm leaning towards (2) at the moment myself.
>>> This might lead to displaying the timing info on many % calculations
>>> though... Hmm
>> Is the time information useful after stage is complete? I'd just wipe
>> it before moving on to the next message.
>>
> My point was about changing when we calculated elapsed time from to be
> "since the status message changed" rather than "since the last time the
> driver sent any status even if the message remains the same".

This would be better, and is a bit like what I was imagining early on, 
but at this point I'm wondering if the display of the elapsed time is 
actually useful, or simply making it messier.

>
> I think clearing the timing message is a good improvement either way, so
> I'll do that too.
Yes.

sln