Home of the Squeezebox™ & Transporter® network music players.
Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 42
  1. #31
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    1,509
    Wow, I'm impressed.

    Just from reading your documentation, and from my experience I think these 3 notes may be relevant:
    - very often I initialize a pipe with 1s to mean active. Scenario: wol the server, have some time to start an activity before the system acts again
    - usually I reinitialize a pipe before suspending or at wake up. Scenarii: avoid bouncing to sleep (esp. when using multiple pipes), reset drives spindown pipes at wake-up.
    - In my config files I express pipes length in minutes (secs), as it is natural to do so. I have a bit of code that creates the right amount of slots given measurement frequency (eg 30-sec runs vs. 2-min. runs, 10 minutes activity pipe -> 20 slots or 5)

    Probably less relevant:
    - my pipes are summerized as: active/idle (most of the time), ok/alert (eg case temp.), keep/change state (eg drive spin, which may stop by itself due to firmware/hdparm conf).
    - In my code I handle the signals on hardware condition with a higher degree of priority (eg shutdown on over-temperature regardless of any preference/status)
    - Ideal time resolution can vary from one item to another. For example fan sensors can be momentarily off, and come back correct just the next second. So you'd want a pipe with a lot of slots to accurately capture a 5-minute fan failure condition ("fan has died")
    Some other times the measurement process can be long/heavy so you don't want to strain the system or fill the pipe with false alarms if the test did not return a value in time; for example SB status detection when connected to mySB.com.
    - I've never used anything but push+shift. I don't know if "re-writing history" (beyond re-init) has a use
    - I'm sure of the following case (but never tested it), for player activity: (recent..old) [1 1 0 0 0 0] is a more meaningful activity hint than (recent..old) [0 0 0 0 1 1]. That's the endianness thing I was relating to.
    - I've been using a clumsy cascade of pipes with a master one starting to empty when the global system status turns idle, to add some inertia to the system. Eg AFP pipe says idle, SB pipe says idle, net pipe (still) says active (it is longer/less precise), global status voted for idle (via arbitrary weighted average), hence 5minute "last-chance pipe" starts emptying (system will stop when this one is empty)
    I think you're headed to considering the last x minutes of a larger pipe and I have the impression this is a solution to that mess.
    - I haven't made any progress on the bayesian approach to system activity prediction, but pipes turned into (long) rings and made persistent were in my grand plan for world domination… EDIT: ah yes, connecting both ends of the pipe (re examining the past to predict what's probably next) means "rewriting history". So there may be use for manipulations after all.

    I got to go. I'll be back

    HTH
    Last edited by epoch1970; 2011-01-20 at 01:49.
    4 SB 3 • iPeng (iPhone + iPad) • SqueezeLite • Squeezebox Server 7.6.2 (Debian 6.0) with plugins: CD Player, WaveInput by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • Just Covers by Tom Kalmijn • WeatherTime by Martin Rehfeld • Local Player, BBC iPlayer, SwitchPlayer by Triode • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  2. #32
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339
    Quote Originally Posted by epoch1970 View Post
    Wow, I'm impressed.

    Just from reading your documentation, and from my experience I think these 3 notes may be relevant[...]
    Ok, I've changed some of my plans based on your comments. In particular:

    bPipe::new($nPipeLength, [$nInit]); will initialize the pipe to !!$nInit, so you can initialize a "full" pipe.

    $bPipe->set([$nPosition], [$bValue]); If $nPosition is undefined, sets the entire pipe to !!$bValue, so you can re-initialize a pipe to all 1s.

    $bPipe->spin([$nDirection]); Pushes or pops the pipe according to the signedness of $nDirection, wrapping the to-be-discarded bit around to the top or bottom of the pipe. If $nDirection is positive, 0 or undefined, spins by left-shifting the pipe and moving the discarded top bit to the bottom. If $nDirection is negative, spins the pipe by right-shifting and setting the top bit to the discarded bottom bit.

    Does that address what you need out of this?

    The 1st version of the class will include:

    Pipe::new
    $bPipe->readbstr([$nPosition]);
    $bPipe->push( [$bValue] );
    $bPipe->pop( [$bValue] );
    $bPipe->set([$nPosition], [$bValue]);
    $bPipe->clear([$nPosition]);
    $bPipe->spin([$nDirection]);
    $bPipe->read([$nPosition]);
    $bPipe->IsEmpty();

    The 2nd version may include the timer support.

    The 3rd version may include some of the other functions I dreamed up.

    Do those seem like reasonable priorities?

  3. #33
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    1,509

    Thumbs up

    Quote Originally Posted by gharris999 View Post
    Does that address what you need out of this?
    Looks perfect !
    4 SB 3 • iPeng (iPhone + iPad) • SqueezeLite • Squeezebox Server 7.6.2 (Debian 6.0) with plugins: CD Player, WaveInput by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • Just Covers by Tom Kalmijn • WeatherTime by Martin Rehfeld • Local Player, BBC iPlayer, SwitchPlayer by Triode • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  4. #34
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339
    @Epoch:

    Marketing question: is "binary pipe" the best description for this sort of facility? Does "pipe" have a more usual and conflicting meaning in normal programing parlance? Would "binary queue" or some other term be a better descriptor?

  5. #35
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    1,509
    Right, it's not a pipe in the computing sense.
    It looks like wikipedia agrees with the use of "queue", see the intro of this page: http://en.wikipedia.org/wiki/Queue_(data_structure)
    Last edited by epoch1970; 2011-01-21 at 11:55.
    4 SB 3 • iPeng (iPhone + iPad) • SqueezeLite • Squeezebox Server 7.6.2 (Debian 6.0) with plugins: CD Player, WaveInput by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • Just Covers by Tom Kalmijn • WeatherTime by Martin Rehfeld • Local Player, BBC iPlayer, SwitchPlayer by Triode • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  6. #36
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339
    @Epoch:

    Another couple of questions:

    I'm not sure I'm quite getting your concerns/plans over endianness.

    The bQueue-formerly-known-as-bPipe is just a bitstring, isn't it? One pokes bits into the queue and one pops bits out of it. So aren't concerns about endianness external to the class?

    The one exception to this that I can think of is when the class attempts to return an int value of the bitstring as a whole. I'm trying to use Math::BigInt->new("0b" . $bitstring) to interpret the bit string and return a bigint. Since Math::BigInt exists on the standard perl install on OSX, I assume that OSX's Math::BigInt handles endianness correctly for that platform. I'll do some tests to check this.

    Is there something that I'm missing here?

    I suppose that one way in which I'm missing the point is that at this point, $bQueue->push() shifts left and $bQueue->pop() shifts right. Is that inherently big-endian? If so, perhaps I could test for endianness upon the loading of the class and swap the definitions of push and pop depending on the endianness.

    And I suppose another change I'll need to make is to be flexible about where to use the apply the "slack mask": big-endian should be at the left end of $bQueue->{_queue}[0], little-endian should be at the right end of $bQueue->{_queue}[last]. I think I have a little more thinking to do about this one.

    Anyway, bQueue::new, $bQueue->set() and $bQueue->read should be endian-agnostic, I believe.

    Any other way in which I'm missing the boat?

    For now, version .01 of the class will probably be big-endian-ific.

  7. #37
    Senior Member
    Join Date
    Apr 2008
    Location
    Paris, France
    Posts
    1,509
    I was not clear.
    I don't see when the direction of the flow of bits would be of importance, for any of my past uses. The way I picture it in my mind is >>|entrance .. exit|>> but it could be the other way around for sure.

    What *seems* of value is the fact that bits close to the entrance reflect recent usage and are most significant, when bits close to the exit can be 20 minutes in the past (or more), hence less significant.
    I never used this information and simply tested a queue for 0/not 0.

    I imagine that if the empty queue sums to 0 (the way I see it),
    - a full queue would value *something big*, lets say 255,
    - a queue with only the oldest possible bit set would sum to 1 >>|00000001|>>,
    - updating the most recent (significant) bit to 0 on a full queue would drop the sum from 255 to 127 >>|01111111|>>

    Now, how 64 >>|01000000|>> hints indeed to higher activity than 63 >>|00111111|>> eludes me (imagine that's a readout gitch vs. a player in pause!)... Maybe it is a bad idea to try looking for anything else than 0/not 0 ?
    Last edited by epoch1970; 2011-01-21 at 15:28.
    4 SB 3 • iPeng (iPhone + iPad) • SqueezeLite • Squeezebox Server 7.6.2 (Debian 6.0) with plugins: CD Player, WaveInput by bpa • IRBlaster by Gwendesign (Felix) • Server Power Control by Gordon Harris • Smart Mix by Michael Herger • PowerSave by Jason Holtzapple • Song Info, Song Lyrics by Erland Isaksson • Just Covers by Tom Kalmijn • WeatherTime by Martin Rehfeld • Local Player, BBC iPlayer, SwitchPlayer by Triode • Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.

  8. #38
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339
    Actually, scratch almost all of what I just said in the previous post. A binary string representation of a number is always read from right to left, no matter the what the endianness is and no matter if you're a dyslexic Arab...at least according to http://wiki.answers.com/Q/Why_do_you..._right_to_left. So the most significant bit ought to be left-most which is how I'm creating this thing.

    As to left shifting being inherently big-endian, not according to:

    http://www.velocityreviews.com/forum...ndianness.html

    -- and --

    http://cboard.cprogramming.com/tech-...-shifting.html

    I will test on OSX's perl and see if the results are as one expects.

  9. #39
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339
    Quote Originally Posted by epoch1970 View Post
    I was not clear.
    I don't see when the direction of the flow of bits would be of importance, for any of my past uses. The way I picture it in my mind is >>|entrance .. exit|>> but it could be the other way around for sure.

    What *seems* of value is the fact that bits close to the entrance reflect recent usage and are most significant, when bits close to the exit can be 20 minutes in the past (or more), hence less significant.
    I never used this information and simply tested a queue for 0/not 0.

    I imagine that if the empty queue sums to 0 (the way I see it),
    - a full queue would value *something big*, lets say 255,
    - a queue with only the oldest possible bit set would sum to 1 >>|00000001|>>,
    - updating the most recent (significant) bit to 0 on a full queue would drop the sum from 255 to 127 >>|01111111|>>
    Well, we could always add a reverse push method taking an optional argument so that you could set the topmost bit of the cue, say:

    $bQueue->rpush(1);

    This would be the same as:

    $discarded_bottom_bit = $bQueue->pop();
    $bQueue->set($bQueue->{_nQueueLength}-1, 1);

    That way, you could use a series of rpush()s to run the queue in reverse.

    Quote Originally Posted by epoch1970 View Post
    Now, how 64 >>|01000000|>> hints indeed to higher activity than 63 >>|00111111|>> eludes me (imagine that's a readout gitch vs. a player in pause!)... Maybe it is a bad idea to try looking for anything else than 0/not 0 ?
    I have yet to play around seriously with Math::BigInt, so I don't know how feasible this would be, but perhaps it could be as easy as:

    # 1s indicate the area of interest..
    $biOfInterest = Math::BigInt->new("0b0000000000111");

    $biCurrentActivity = $bQueue->read();

    if ( $biCurrentActivity & $biOfInterest ) {
    do stuff
    }

    ..or, expressed another way..

    # 1s indicate the area of the queue to ignore..
    $biActivityMask = Math::BigInt->new("0b1111111100011");
    $biCurrentActivity = $bQueue->read();

    if ( $biCurrentActivity & ~$biActivityMask ) {
    do stuff
    }
    Last edited by gharris999; 2011-01-22 at 11:14.

  10. #40
    Senior Member gharris999's Avatar
    Join Date
    Apr 2005
    Location
    Santa Fe, NM
    Posts
    3,339

    bQueue

    OK, here is version 1.01 of the bQueue binary queue class.

    Methods implemented in this version:

    Code:
    bQueue->new()
    bQueue->resize()
    bQueue->read()
    bQueue->readbstr()
    bQueue->set()
    bQueue->clear()
    bQueue->fill()
    bQueue->fillrandom()
    bQueue->empty()
    bQueue->isempty()
    bQueue->reverse()
    bQueue->invert()
    bQueue->push()
    bQueue->pop()
    bQueue->rpush()
    bQueue->spin()
    Changes:

    Support and optimizations for very large queues (>30k!).

    Added bQueue->isempty() method.

    Feedback welcome!
    Attached Files Attached Files
    Last edited by gharris999; 2011-02-02 at 22:33.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •