search

lukechampine / user

A CLI renter for Sia
MIT License
12 stars 2 forks source link

Idea: per-host progress bars #10

Open lukechampine opened 5 years ago

lukechampine commented 5 years ago

https://github.com/vbauerster/mpb is a neat package that would let us implement this. That way you could see in real-time which hosts were fast and which were slow.

There's a problem though, which is that 50+ progress bars is...too many. So we'd probably want to display just the 10 fastest hosts. But that means the bars would be swapping positions all the time, which isn't great either. Might be less of a problem if we colored each host differently, I dunno. Open to suggestions here.

grigzy28 commented 5 years ago

Depending on the size of the screen, you could have a couple bars per line, similar to how htop works with the cpu graphs. I could easily see this

contractid: [--------------------]         contractid: [----------------]      contractid: [-------------------]

The progress bar lines shouldn't need to be really big, maybe 10/5% per character or even maybe 3/2% for larger screens.

Showing contract id: [error] for hosts that produce errors with a more detailed explanation after the procedure has exited, with either a successful or failed download.

grigzy28 commented 5 years ago

Also, thought about this....

An overall graph showing MinShards chunk sections obtained, not obtained. with file.zip in 10 shard sections

file.zip [---x---x--]

this type of graph/bar showing that it is missing those 2 so far from the available hosts.

lukechampine commented 5 years ago

That would be pretty neat:

foo.usa                      14 MB/s, ETA 00:05
e506d7f1 (   error   )    c03f4055 [#########..]
4a6b15da [#########..]    48684b96 (   idle    )
a3661be1 [.....####..]    b5c5380c (   error   )
d46d8a9e (   idle    )    fee8b6ff [#####......]

In order to support this, we would need to make all that per-host information available through the PseudoFile or PseudoFS types. Seems tricky. I had something like this before, using a channel of generic "updates" (still used for migrations), but it never sat quite right with me.

vargrant commented 4 years ago

I think we need to have history by 3 parapmeters. 1) Contract price - here is constant for each cotract. 2) Contract full price - here must be calculated by forects variables of upload/downlad required bandwidth with full time of storage prices. This indicator can have different prices all time beucase after the contract was formed host can change price of upload or download data. 3) Stability - hove many % time this contract was accessible.