Visualizing I/O rates

Ian,

I quickly scanned your goodies for screen shots of serial communications
user interfaces, thinking I might find an answer to my current problem.
  I am looking for a simple way to keep track of how much data is being
sent (and perhaps read) per unit time.

It needs to keep track of when/how-much pairs, probably in bins, and
somehow age those bins so it can "forget".  This _has_ to be something
that is done frequently.  Any pointers to elegant implementations or
related good/bad experience?

I will gladly accept good ideas from anyone :)  Of wider interest might
be the aging of bins.  Would you use an OrderedCollection, adding at one
  end and dropping obsolete bins from the other end?  Is there an
approach  or collection type that might be more efficient?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> It needs to keep track of when/how-much pairs, probably in bins, and
> somehow age those bins so it can "forget".  This _has_ to be something
> that is done frequently.  Any pointers to elegant implementations or
> related good/bad experience?
>
> I will gladly accept good ideas from anyone :)  Of wider interest might
> be the aging of bins.  Would you use an OrderedCollection, adding at one
>   end and dropping obsolete bins from the other end?  Is there an
> approach  or collection type that might be more efficient?

I have a similar application in the "status monitor" for my JNIPort (which is
on my website if you can stand to load /lots/ of JNIport code just to look at
one small aspect of the implementation of one small part of it ;-).  I use a
RollingAccumulator (as I call the class), which is a Collection that acts
pretty much like an Array except that it also supports #add, and as items
(bins) are added to the end they are rolled off the front.  It's implemented as
a circular buffer inside.  You can find it, if you want, in the "Miscellanea"
section of my site (it's independent of JNIPort).   I probably wouldn't have
bothered with a special-purpose class for this application, except that I had
it implemented anyway, and it seemed somewhat better suited to the task than
just hacking it with an OrderedCollection.

Someday I want to split the actual graphing aspect out into a standalone
package as well.  In fact I already have done so, but I'm not happy with the
results, so it'll be a while -- if ever -- before they end up published
separately.

    -- chris

Bill Schwab wrote:
Might try a preallocated bunch of N associations,
linked in a circle on their keys, with actual bins
being their values; and a "list" of size N;
so that:

 >>currentBin
     ^currentBin value

 >>ageIt
     currentBin := currentBin key

 >>asList
     | bin |
     bin := currentBin.
     ^list collect: [:ignore| (bin := bin key) value]

Season with #critical: to taste.

Regards,

-cstb