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

Bug#750546: ITP: sluice -- rate limiting data piping tool



On 04/06/14 13:23, Colin Ian King wrote:
> On 04/06/14 13:14, Henrique de Moraes Holschuh wrote:
>> On Wed, 04 Jun 2014, Colin Ian King wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Colin Ian King <colin.king@canonical.com>
>>>
>>> * Package name    : sluice
>>>   Version         : 0.01.00
>>>   Upstream Author : Colin King <colin.king@canonical.com>
>>> * URL             : http://kernel.ubuntu.com/~cking/sluice
>>> * License         : GPL-2+
>>>   Programming Lang: C
>>>   Description     : rate limiting data piping tool
>>>
>>> Sluice reads from standard input and write to standard
>>> output at a specified data rate.  This can be useful
>>> for benchmarking and exercising I/O streaming at desired
>>> throughput rates.
>>
>> We already have the "pv" package, which does all of that and more, and
>> that's in the absolutely ancient version in Debian/Ubuntu.  Does "sluice"
>> have relevant differences or advantages over "pv" ?
> 
> sluice's only difference in that respect is that it has a warning option
> to inform the user that it can't keep up with the specified data rate.


Since my original email, I have added more features and more
sophisticated rate limiting features, namely:

* constant delay time between each write (rate limiting by changing
buffer sizes)
* constant buffer sizes, (rate limiting by changing write times)
* rate limiting by changing buffer sizes and write times
* -s option to tweak rate limiting throttling

The -s option controls the damping behaviour, which can be tweaked for
different kinds of variable rate inputs. Some analysis of this can be
seen on the sluice project page:

http://kernel.ubuntu.com/~cking/sluice/

I wonder if this justifies sluice being reconsidered?

Colin

> 
> I guess we can close this bug and get pv updated, I don't think sluices
> features merit uploading to Debian considering pv is superior.
>>
>> Looks like we could use a more active maintainer for pv, though.
>>
> 


Reply to: