>Worked a lot with my new bitcoin mining rig this weekend. It’s running pretty smooth and trending around 800 mhash/s. I’ve got another nice fan coming tomorrow to improve the air flow a bit inside the case which should bring down the temp a few more degrees. What’s next? It’s an Ubuntu system, but I think my next step is I need to boot into windows long enough to unlock the bios limitations. Generally this is useful for overclocking, but I’m actually looking to do the reverse. I want to underclock the memory and voltage since I’m not actually using those aspects of the video card. This will generate less heat, thereby allowing me to raise the core clock speed of the gpu. The end result? More mhash/s at the same temperature. At least that’s the goal. We’ll see how that works. Not looking forward to putting Windows on the box though.. might just borrow a hard drive with Windows on it long enough to do the unlock. Hmmm…. (BTC 14M8MSf67FvqGpXBU3QJaYjzd9enT9nKbd)
Monthly Archives: July 2011
>MooseX::POE
>Started laying some of the foundation utility modules for the current app I’m working on. Using MooseX::POE because I like the syntax over using MooseX::Declare and MooseX::POE::SweetArgs. I don’t need that much sugar to enjoy my Kool-Aid! 
So yeah, put together a simple wrapper class for getting input from a socket connection. I looked at utilizing POEx::Role::TCPClient since that’s exactly the type of thing I’ve written a simplified version of, but it does not seem to work with the current release of POE. *sigh* (The incompatibility seems to be within POEx::Role::SessionInstantiation but I got lost looking down the rabbit hole on that one, maybe I’ll take another look after a few breaths of air).
So anyhow, I got that built then put together an app controller to handle everything. Now I need to do some more thinking on my data requirements as far as what kind of backend is going to be needed. More on that once I can finally nail down a decision on this…
>Looking over Bread::Board
>Took a look at Bread::Board today. Pretty neat stuff. You can use Bread::Board to wire together your components (complete with the “without the wires” pun) into your application. I love it. I’m going to take another look at Ox to see whether I want to play around with Bread::Board directly or use Ox on top of it to make things a bit cleaner/easier.
On that note, what are people using to implement communication between components on non-event driven environments? Message Queues?
>pid locking
>So I’ve had some issues with duplicate processes running and that kind of confused me. I looked in the code and I’m using Proc::Pid::File to control the processes and exiting out if the old process is still running. I finally found some time to dig into this further late last week. It seems that the logic the module currently has you use is essentially:
if pidAlive
then exit
else
updatePid
end if
The problem here is that there is a race condition between the checking for alive and updating the pid file to take control. What is happening on our system is:
process1: is pidAlive? no.
process2: is pidAlive? no.
process1: update pidFile.
process2: update pidFile.
Now both process1 and process2 are running, the pid file reflects process2 is alive, nothing indicates that process1 is alive, so if the restart or shutdown systems are used, they talk to process2 but process1 keeps on trucking. At this point process3 can check the pid and it’s not alive so it will go ahead and start up perpetuating the problem.
What is really needed would be a single method that will eliminate the race condition:
begin getPid
create pid file if it does not exist
exclusive lock pid file
if pid and pid is running then
result is false
else
result is true
update pid file to our pid
end if
release exclusive lock
return result
end getPid
The problem with this solution? Proc::Pid::File has been around for quite a while and a lot of people are using it. We can’t just change the API like that. We need to find a way to keep the same API, but change the logic to match what I’ve proposed.
I’ll need to give this some more thought on how to work around this without changing the API. Perhaps it’s just continue to support the current API, and add a new method to do both at once but do it cleanly instead of just using it as a wrapper to call both in sequence.
>pro git
>Spent some time this weekend reading Pro Git when I had some time. I wanted to brush up on my understanding of how git works and along with that gain some more advanced git skills. I’m about half way through the book, and so far it’s been well worth the money spent. I definitely have a better understanding of git, how it works and how to use it. If you haven’t checked out git yet, please do so. It’s an amazing source control system and will change the way you work for the better.
>Is the pool open yet?
>Is the pool open yet? The short answer, no.
At the start of the pool season I was on top of things. I got an early start, got the cleaning supplies I would need, started working. The waterways blue and looking good. There was just one problem. After a few days water started leaking out of the pool pump. *sigh*
Unfortunately I was afraid this might happen. The first big freeze last fall caught me by surprise and I had to do a rush job on closing the pool. I figured something would go wrong.
Back to the spring opening, water leaking out everywhere. I called around to the local pool shops. They either only deal with in-ground pools or they were currently booked solid with openings and were not accepting new customers. Damn.
I finally found a guy using google local search. Excellent! I gave him a call, explained the situation, and later that day he came out to take a look. After taking a look the pool guy said he thought he could fix the motor, he would pick up the part he needed and come back the next day. I tried working with the guy, he seemed nice and genuine enough. At this point he has basically disappeared with the money I gave him for a new pump (after the repair did not resolve the issue), and the phone number he was using has been disconnected.
I contacted a couple other local shops again and there’s not much help to be found. *sigh* I give up. I’ll figure it out. It’s not rocket science or a complex software development issue. It’s PVC pipe, some fittings, some wrapping, and a motor. Ordered a replacement pump online (1/2 the cost of what I was taken for locally) and I’ll install the darn thing myself.
The pool WILL open.
>Reflecting back..
>An interesting week this week, working on a variety of tasks. Unfortunately not all of it Perl related. I did get a chance to spend some time working with Reflex. Overall I really like how it ties into my Moose objects, with the only downside being things were quite flaky at runtime. A quick chat on #reflex reminded me of Rocco’s words from YAPC to use the git version until he has some time to put some polish on his recent changes and push out a release to CPAN.
While this thought was reassuring that things will work better once I pull from git, it also reminded me that I probably can’t really consider using Reflex for any production destined development. This would include my current project. 
i know POE will get the job done, it’s just not as clean and integrated as Reflex so it would have been nice.
Next week I’ll get back to scoping things out using MooseX::POE and see how it holds up. I think I’m already using that in one of my recent Moose objects and things are running sharply in production so sounds good.
>friday… i mean, it’s friday. come on.
>Pushed out the code release this morning to move the refactored event code to production. Overall things went smoothly. Transitioned to the upgraded code smoothly in our facility and the other main facility. One of the international facilities had an issue, but I tracked that down and released a small upgrade to resolve that. I’ll be adding a unit test for that condition this weekend or next week.
Back on to perl specific topics, I looked more at Reflex today. I have a new project, in the early stages of design and prototyping. Pretty sure I want to use reflex to implement the necessary event modules. I’m still not entirely up to speed on how it all works together, but it’s slowly starting to click. Once I get some hands on it’ll spread like butah’ I’m sure.
>testing code updates
>Tested my recent code changes today. Things ran ok for about five minutes, then my cached data expired and I hit a few hiccups. This was a good thing, in the process of tracking down where things went wrong I cleaned up quite a bit of the way things were being handled. I’m still not thrilled with how I’m handling some of the asynchronous calls, but I just did not have time to fully rethink how things work on a fundamental level. I know how I would do it were I to do it all over again, so I learn.. and we move on. And should the current system fall over, I know how I’d like to fix it. Hopefully that won’t ever be needed.
While I was testing I went ahead and debugged a couple web services I was utilizing that did not appear to behave as expected, worked out nicely to get my interactions with those cleaned up.
Overall pretty happy with how the system is running now, testing is complete, I’ve tagged the release v2.2.0 and will be pushing it to our production environments tomorrow morning. I’d push it now, but honestly I need a good nights sleep and I’m not willing to risk it.
>ridin’ dirty!
>Ridin’ dirty this evening, writing a quick export script and slumming it without Moosey goodness in my perl. Feels wrong. :) This kind of work makes me appreciate all the work that goes into Moose and what kind of benefits that gives to me and my code.