Love the Dot

Day 20–Slip it to the right

2012-07-18T19:02:00.001-07:00

Note: Cross-posted from my roadtrip blog because the post has something remotely to do with scheduling.

	Miles	MPG	Avg. Speed
Today	398	44.1	59
Trip	6129	46.7	49

Food (today/budget)	Hotel (today/budget)	Trip Savings
$15 / $127	$100 / $100	AAA - $26 PriceLine – $945 Real $$ – $290

Today was driving. From Spokane, out of Washington, across Idaho, and then down through Montana almost to Wyoming and Yellowstone. The section of Idaho we went through was all mountains, so no potato for Aryn.

We did stop somewhere in Montana to get a huckleberry shake, which was quite good.

The plan was for three nights here, then on across South Dakota and then up to Grand Forks, but we’re behind schedule.

Much like with a software project, I had a perfectly reasonable schedule when we left Orlando. I researched the driving time between cities and how long we’d stay in each place, put it in Excel, added three days for unexpected contingencies, and figured we were set.

Then, early in the ~~project~~ drive, scope-creep wormed its way in. A night in Austin when we were supposed to push through to Carlsbad, an extra night in Albuquerque to avoid getting to Vegas on a Friday, an extra night in Vegas to see a third show – all reasonable and, hey, had that contingency time and we could probably make up a day between Vegas and San Francisco anyway.

Well, the convention in San Francisco made making up the day and arriving early not so feasible, which put us on track to arrive home on the 24th. On schedule, but with no contingency.

Then the tire problem, which ate three hours of the morning on the way out of San Francisco … three hours isn’t a problem, right? But it cascaded into us coming out of Crater Lake at dusk, which doubled the time it took to get off the mountain and forced us to stop short of Seattle (cascaded in the Cascades, get it?). There’s a day onto the right of the schedule.

The routing off of Ranier yesterday, which took us back toward Tacoma and Seattle and around the north side of the mountain was a complete cluster. I’d originally headed east out of the park, towards Yakima, which would have put us on track. But on the road down to Yakima we hit construction and it was one-laned and it’s a longer road – after coming down from Sequoia in the dark and coming down from Crater lake in the dark, I didn’t want to take a chance on a third time and winding up behind schedule.

Look how well that worked out.

So the remaining schedule looks like:

7/18/2012	Yellowstone
7/19/2012	Yellowstone
7/20/2012	Black Hills
7/21/2012	Grand Forks
7/22/2012	Grand Forks
7/23/2012	Grand Forks
7/24/2012	Minneapolis
7/25/2012	Chicago
7/26/2012	Atlanta
7/27/2012	Orlando

I emailed work and let them know I won’t be in until Monday, 7/30.

Consolidating My Cloud Storage–Part I: Backups

2012-02-01T15:41:00.000-08:00

Many years ago, when it first came out, I used Carbonite for online backups. After a while, I found that I had so much NAS storage in my house that I stopped using Carbonite. Then a year or so ago, I moved into an apartment and decided to go with offsite backup for my data again – in a house, you’re the only one you have to worry about burning the place down, but in an apartment you’re at the mercy of the dumbass next door – so I signed up with Mozy.

These are both good, cost-effective services, but over time I’ve found myself either signing up for or trying to find other uses for cloud storage. Obviously services like Dropbox for file synching, but also I’d like to be able to mount cloud storage and use it directly, without using local disk space. So I also looked at TntDrive, which allows you to mount Amazon S3 buckets as a drive.

At $9.99 a month for Mozy, the same for a larger Dropbox, and $39.95 for TntDrive, we’re at $270 for the first year. $240 for each year after that, assuming no upgrade costs for TntDrive. Mozy has a new Stash service in beta, which is somewhat similar to Dropbox for the PCs attached to your Mozy account, but sometimes I need to share a large file with someone who doesn’t even have Dropbox. My mom, for instance, isn’t going to install Dropbox, or delivering processed video files to customers – for that I use S3, because I can upload the file and then send my customer a download link.

I had been considering a switch to Megaupload for that, but …

Anyway, I’ve always used CloudBerry’s free S3 Explorer for managing my S3 buckets, but I was still using a version I’d downloaded years ago and never bothered to upgrade, so I decided to see what the new version might offer. Turns out that’s quite a bit, starting with a whole product for backups: CloudBerry S3 Backup.

My main requirement for a backup solution is that it be as transparent and timely as Mozy or Carbonite. Full system backups I can do locally to NAS periodically, the offsite solution is for data. I don’t want to have to run it manually. CloudBerry meets this requirement with both scheduled and continuous, real-time backup. We’ll give that a try and see how it works.

After downloading the demo and installing it, the first step is to create a Backup Plan and … holy crap!

S3, Azure, Google, and, like, a dozen other cloud storage services, including some I think they must have made up because I’ve never heard of them. So, clearly, my storage target is not limited to S3 and I like that. Options are good.

Next we enter the connection information for the S3 account and specify a bucket:

Note the little hint at the bottom of the dialog – mounting cloud storage as a virtual disk is one of the things I want to do. This option is read-only, which is actually one of the uses I have for that feature. I want my kids to be able to access my main music library, but not be able to change it (I don’t care what they do with their music, but I’ll take no chances with my Katy Perry MP3s). We’ll check that feature out in a later post.

Next we specify a new S3 bucket to contain the backup and select its location. This is one of the things that I like about an S3 solution – this degree of control may not be for everyone, but, well, I have control-issues, so this makes me happy.

Um … did I mention lots of control?

I went with Advanced Mode to support multiple versions of the files and block level backups (backing up only the changed segments of files). I also turned on the Volume Shadow Copy Service, as I want this backing up changes continuously while I use the computer.

Then we select the files and directories we want to backup:

A nice feature here is the ability to add a network share to your backup, something not found in services like Mozy or Carbonite (last I checked).

But something those services do offer that CloudBerry doesn’t seem to is Explorer-integration:

It would be nice to be able to add a file or folder to a backup plan from Explorer – because opening the CloudBerry app and changing it there is too much work and I’m lazy. It’d be a bit more work to do than Mozy’s, because Mozy only has one backup plan. I’d suggest an “Add to CloudBerry Backup >” menu with submenus for applicable plans.

More options:

And another suggestion: I’d like to be able to specify filters like these per folder/subfolder. For instance, I might have a folder for downloaded apps that I want to keep the installs for (exe, msi, etc.), but I’d like to ignore the exes and dlls in my Visual Studio projects. That would be interesting … because it would satisfy my control issues …

Compression and encryption are self-explanatory, but Reduced Redundancy Storage requires some explanation. According to Amazon, S3 offers 99.999999999% durability and can survive concurrent data loss in two facilities – in layman’s terms that means “really, really good”. RRS “only” offers 99.99% durability and data loss in a single facility. What does that mean?

Lots of options for cleaning up old versions of files and deleted files:

And here’s where I can make the setting that will let me replace Mozy:

Real-time Backup is what I’m looking for myself, but the product’s flexible and powerful enough to handle a variety of backup strategies. Why real-time? Well, this is what my Mozy status looks like today:

I have it scheduled for twice a day and the laptop was on most of last night and all day the day before … but it hasn’t backed up in two days, despite my twice a day schedule. I like the idea of the backup application being notified of changes and backing up right then, with possibly a scheduled backup to, well, backup the backup.

And finally email notifications for the backup status:

And the configuration’s done so I ran the backup. My dataset for this was about 14GB, which brings us to some areas in which CloudBerry Backup could be improved. There doesn’t seem to be a way to determine the original and compressed total for a given backup plan. This is information that I’d like to know, so I had to figure out the original size manually by reviewing the folders I’d selected for backup:

Improvement Opportunity: In the review of the selected folders, the UI for a partial folder is very faint and indistinguishable from an unselected folder. Compare this with Mozy’s view:


CloudBerry	Mozy

The Mozy representation is far more usable.

I used S3 Bucket Explorer to determine the size of the files on S3 and came up with a little less than 12GB after compression. CloudBerry’s S3 Explorer also has the capability to determine bucket size, and in a much nicer interface that allows you to drill down and graphically see the space used by different folders:

Unfortunately for me, the free version is limited to 2GB of objects for this report.

Improvement Opportunity: I’d like to see this same capability in the backup tool – for a given Backup Plan I’d like to see, in the same graphical drill-down, the original size on disk and the compressed size on S3.

My next test was of the “continuous” feature, so I created a new folder in my documents library and dropped a Word document in it, using S3 Explorer to watch the bucket. Within about two minutes, the new folder and Word document showed up on S3. This is a feature Mozy doesn’t offer – it may not be something I use for all folders, but CloudBerry offers the flexibility to have multiple backup plans, scheduled, continuous, or on-demand, so I can set the appropriate plan for each type of data.

Next I wanted to test performance, so I created a new folder with three 700MB files. I then added these to a CloudBerry backup plan and to Mozy in order to compare the upload speed of each.

Ouch … what’s up with this? CloudBerry averages about 500KB/second when it’s backing up files, but Mozy averages 3.5-4MB/second. That’s a pretty significant difference (a 7x to 8x difference in performance).

CloudBerry, of course, is dependent on the S3 infrastructure, so this can probably be blamed on Amazon. This difference doesn’t thrill me, but I’m more concerned with the restore (download) performance. After all, the backup will be in the background and transparent, but when it comes time to restore it’ll be because a Bad Thing has happened and I want access to my data.

It seems Mozy still has the edge here, but the 4.2MB/second restore speed is completely respectable.

So I’ll run this for about a week and then see where we are.

Parallel Programming in .Net 4.0 and VS2010: Part II – WinForms, Tasks and Service Level Agreements

2010-06-03T17:31:00.001-07:00

Note: This article was originally published with code samples from the Visual Studio 2010 Beta. This version has been updated for the release version. This article, especially, has changed due to the changes in the Task cancellation mechanism.

The Console application in my previous post was actually the prototype for a more robust WinForms implementation – I have a customer who likes prime numbers. We’ll call him Bob.

Sure, Bob’s a little weird, but he typically pays his invoices Net-10, so I like to keep him happy.

I first deployed the application to Bob without using the Parallel Task Library, so it was single-threaded:

     private void goButton_Click(object sender, EventArgs e)

      {

          Stopwatch watch = Stopwatch.StartNew();

          for (int i = 0; i < 100; i++)

          {

              doWork(i);

          }

          watch.Stop();

          listBox1.Items.Add(String.Format("Entire process took {0} milliseconds", watch.ElapsedMilliseconds));

      }

      private void doWork(int instance)

      {

          Stopwatch watch = Stopwatch.StartNew();

          for (int i = 3; i < 30000; i++) 

          {

              if (isPrime(i));     

          } 

          watch.Stop();

          listBox1.Items.Add(String.Format("{0} took {1} milliseconds", instance, watch.ElapsedMilliseconds));

      }

      private static bool isPrime(int i)

      {

          for (int j = 2; j <= (i / 2); j++) 

          { 

              if ((i % j) == 0)             

                  return false; 

          } 

          return true; 

      }

Bob was happy with the results, but not with the performance:

“Sixteen seconds is too long! I can’t wait that long! Time is money in my business! It needs to be instantaneous!”

I tried to explain to Bob that “instantaneous” is not a Service-Level Agreement, but he was adamant: “Faster!”

And, no, I have no idea what Bob’s business is or why he needs this application. He pays on time – I don’t ask a lot of questions.

So my first change is to make the for-loop parallel:

    Parallel.For(0, 100, i =>

     {

         doWork(i);

     });

Unfortunately, changing an application from single- to multi-threaded can have unintended consequences. When writing a single-threaded WinForms application you don’t have to worry about things like WinForms Controls only being accessible from the UI thread:

The doWork() method accesses the ListBox directly to add items to it, but since doWork() is now being run on a different thread, it violates a fundamental Windows requirement that UI controls only be accessed from the thread they were created on.

This problem isn’t new with .Net 4.0, it’s always been there and remains even in WPF. UI Controls can only be accessed from the thread that created them and that should be the main application thread. So there are some hoops we have to jump through in order to get back to the UI thread in order to update the control. There are a number of articles available that describe patterns for dealing with this – the one I typically use (now) is:

    private void updateList(string item)

    {

        if (listBox1.InvokeRequired)

            listBox1.BeginInvoke((Action)delegate() { listBox1.Items.Add(item); });

        else

            listBox1.Items.Add(item);

    }

Then I change the doWork() method to add items to the list through the addToList() method instead of directly:

    private void doWork(int instance)

     {

         Stopwatch watch = Stopwatch.StartNew();

         for (int i = 3; i < 30000; i++) 

         {

             if (isPrime(i));     

         } 

         watch.Stop();

         updateList(String.Format("{0} took {1} milliseconds", instance, watch.ElapsedMilliseconds));

     }

And, for consistency, I do the same to the goButton_Click where the total elapsed time is recorded.

Running the application now results in the same performance improvement seen in the console application:

I take this new version to Bob, pretty confident that dropping the processing time from almost 16 seconds to 4 will make him happy. The only problem is that I’m not sure how to bill him for it – after all, using the Parallel Extensions I was able to get this speed improvement with only a few minutes of work -- .Net 4.0 might improve my productivity, but it could have a negative effect on my Accounts Receivable.

Unfortunately, Bob’s not as impressed as I thought he’d be:

“4 seconds? I still have to wait 4 seconds? Faster! Faster! Faster! I need instantaneous results! I need to start working with the list as soon as I click the Go button!”

Bob’s a little high-strung.

But something he said sparks an idea. Bob needs to work with the list immediately, but not with the entire list. His process is to do something with each item in the list (no, I still don’t know what he does with them), so he doesn’t need everything, he just needs enough to start working. While he’s working on the early results, later results can be completed and returned.

The way we’d do that today is to start our own background thread using something like ThreadPool.QueueUserWorkItem(). I can move the current code from button click event to another method, then use QueueUserWorkItem to run that code on a background thread:

    private void goButton_Click(object sender, EventArgs e)

    {

        ThreadPool.QueueUserWorkItem(new WaitCallback(freeUi));

    }

    private void freeUi(object sync)

    {

        Stopwatch watch = Stopwatch.StartNew();

        //for (int i = 0; i < 100; i++)

        Parallel.For(0, 100, i =>

        {

            doWork(i);

        });

        watch.Stop();

        updateList(String.Format("Entire process took {0} milliseconds", watch.ElapsedMilliseconds));

    }

This works great. The list starts populating immediately and Bob will be able to get started working on the first items in the list while the remaining work finishes. But QueueUserWorkItem is a little passé – it’s very … .Net 2.0 – what does 4.0 offer us to replace it with?

Enter the System.Threading.Tasks namespace and the Task class. Using the StartNew() method on Task.Factory, we can create our background thread using the new, .Net 4.0 Task model, rather than via the old ThreadPool. New is better. Mostly. Except New Coke – New Coke was bad. Very, very bad.

       1: private void goButton_Click(object sender, EventArgs e)

       2:  {

       3:      Task.Factory.StartNew(() => { freeUi(null); });

       4:  }

Bob is thrilled with this new version.

“I’m thrilled! This is great! It’s instantaneous! By the way … how do I make it stop?”

So Bob wants a way to stop the population of the list once he’s started it. We can give him that with the CancellationTokenSource and CancellationToken. First we need a token to use for cancelation:

       1: private CancellationTokenSource tokenSource;

       2: private CancellationToken token;

       3:  

       4: public Form1()

       5: {

       6:     InitializeComponent();

       7:  

       8:     tokenSource = new CancellationTokenSource();

       9:     token = tokenSource.Token;

      10: }

Now this token must be passed to the Task:

       1: private void goButton_Click(object sender, EventArgs e)

       2: {

       3:     var task = Task.Factory.StartNew(() => { freeUi(null); }, token);

       4: }

And, via a ParallelOptions object, to the Parallel.For loop:

       1: var options = new ParallelOptions();

       2: options.CancellationToken = token;

       3:  

       4: Parallel.For(0, 100, options, i =>

       5: {

       6:     doWork(i);

       7: });

And, finally, having given Bob a Cancel button, we would call Cancel() on the CancellationTokenSource when he clicks it:

       1: private void cancelButton_Click(object sender, EventArgs e)

       2: {

       3:     tokenSource.Cancel();

       4: }

Now that we have a token in all of our Tasks and threads that will tell us when Bob clicks Cancel, we need to gracefully shutdown all of those background threads and what’s spawning them.

For the Parallel.For loop, we need to get the ParallelOptions down into the doWork method itself, because we want to be able to interrupt the prime number loop itself:

    Parallel.For(0, 100, options, (i) =>

    {

        doWork(i, options);

    });

Once there, we can use the CancellationToken property to break out of the process when it’s cancelled:

    private void doWork(int instance, ParallelOptions options)

     {

         Stopwatch watch = Stopwatch.StartNew();

         for (int i = 3; i < 30000; i++) 

         {

             if (isPrime(i));

             options.CancellationToken.ThrowIfCancellationRequested();

         } 

         watch.Stop();

         updateList(String.Format("{0} took {1} milliseconds", instance, watch.ElapsedMilliseconds));

     }

This method throws an exception, so you should catch that and use it to clean up after cancelled tasks.

    try

     {

         Parallel.For(0, 100, options, (i) =>

          {

              try

              {

                  doWork(i, options);

              }

              catch (OperationCanceledException ex)

              {

                  // clean up iteration

              }

          });

     }

     catch (OperationCanceledException ex)

     {

         // clean up loop

     }

Bob’s happy with this latest version. It satisfies both reasons to parallelize or multi-thread an application: Performance and User Experience. Bob’s experience is improved because he’s able to continue work immediately after clicking on the Go button and doesn’t have to wait at all, and the entire process’ execution time has improved from over fifteen seconds to under four (on a quadcore PC). Even I’m happy, because I can now send Bob an invoice and get paid.

Download Project Source Code

Parallel Programming in .Net 4.0 and VS2010: Part I – The Parallel Task Library (Parallel.For, Parallel.Foreach() and Invoke())

2010-02-09T16:30:00.001-08:00

With the availability this week of the Visual Studio 2010 RC, it’s time to update the parallel posts from last year to cover changes in the API – so this is much the same information as presented in the original article, but it’s updated for the Visual Studio 2010 release candidate.

In this article, we’re going to look at the Parallel Task Library and what it makes available for parallelizing for and foreach loops.

Parallel.For()

Starting with a simple, single-threaded application that does some work a few times:

     for (int i = 0; i < 100; i++)

    {

        var watch = Stopwatch.StartNew();

        doWork();

        watch.Stop();

        Console.WriteLine("{0} took {1} milliseconds", i, watch.ElapsedMilliseconds);

    }

    Console.ReadLine();

And where the doWork() method is simply a really bad way of determining the prime numbers under 30000:

    private static void doWork()

     {

         for (int i = 3; i < 30000; i++)

         {

             if (isPrime(i))

                 ;

         }

     }

     private static bool isPrime(int i)

     {

         for (int j = 2; j <= (i/2); j++)

         {

             if ((i % j) == 0)

                 return false;

         }

         return true;

     }

The purpose of the doWork() method, of course, is just to give the CPU something to do – which it does, consistently taking about 147 milliseconds for each iteration on a system with a 2.27 GHz quadcore Q9100 processor.

Although there’s some activity on all four cores as this runs, the total CPU usage stays between 20% and 25%, never making full use of the processor’s four cores:

Although the CPU and operating system will cooperate to send work from multiple applications to the cores in such a way as to make as much use of them as possible, a single-threaded application by itself will never get much above one core’s worth of the CPU’s total power.

To access that power for our applications, we have to create multiple threads – and .Net 4 makes it very easy to do so.

New in .Net 4 is the System.Threading.Tasks namespace which contains the Parallel class. This new class has some static methods which allow us to change the code slightly to parallelize* it:

    //for (int i = 0; i < 100; i++)

    Parallel.For(0, 100, (i) =>

        {

            var watch = Stopwatch.StartNew();

            doWork();

            watch.Stop();

            Console.WriteLine("{0} took {1} milliseconds", i, watch.ElapsedMilliseconds);

        }

    );

Parallel.For has multiple overloads, but at its most basic (above) it takes a from integer (inclusive), a to integer (exclusive) and a delegate (in this case a lambda expression). The step defaults to 1.

The effect of this small change is dramatic. The CPU utilization will now spike to 100% when the application is run:

And the total runtime for the 100 iterations drops from 14.7 seconds to 4.3 seconds – a huge increase in performance because we’re now making full use of the processor’s four cores.

A look at the Visual Studio debugger’s Thread window (Debug | Windows | Threads) shows what made the difference. When executing the first version of the code, with the traditional for-loop, only a single thread is executing at any one time:

But the change to Parallel.For results in multiple threads doing the work:

In this case, five threads are simultaneously executing iterations of the work (the main application thread and four worker threads). The exact number of threads used for parallelization is determined by .Net based on the number of cores available (there are some advanced options for controlling this, but careful consideration should be given before doing so).

A comparison of the output of both versions does show a couple of important differences that you should consider before parallelizing your code:

for-loop

Parallel.For

The first consideration is performance. Although the total performance improved from 14-seconds to four, the time spent in each iteration has increased and become less predictable. In a single-threaded, for-loop each iteration takes a consistent 147-milliseconds, but the parallel implementation varies from 147 to over 300-milliseconds. This is due to overhead associated with the parallelization and the potential for threads to be swapped out by the operating system to provide CPU cycles to other applications.

Another consideration is ordering of the work. As you can see from the screenshots above, the single-threaded example performs the work sequentially. Each time through the for loop does its work and completes before the next starts. But when this is parallelized, the order of completion can’t be guaranteed. As the work is off-loaded to seven worker threads (in this example), each of those threads could complete its work and get the next task at any time. So parallelizing isn’t an option (or is a more complex option) when the order of execution matters to your application.

Parallel.ForEach

The Parallel.ForEach() method follows the same pattern:

    List<int> list = new List<int>();

    // populate list

    Parallel.ForEach(list, (item) =>

        {

            // parallel work here

        }

    );

Parallel.Invoke

Parallel.For() and Parallel.ForEach() are useful if you have collections you need to act on or a known number of times you have to execute the same code, but what about when you have several different things (methods) you need to do? For that, we have Parallel.Invoke().

Parallel.Invoke() simply executes, in parallel, a list of methods passed to it:

    static void Main(string[] args)

    {

        Parallel.Invoke(A, B, C, D, E);

        Console.ReadLine();

    }

    public static void A(){}

    public static void B(){}

    public static void C(){}

    public static void D(){}

    public static void E(){}

Methods A(), B(), C(), D() and E() will be assigned to worker threads as they become available and execute in parallel. As with the other methods, there are no guarantees about the order of execution.

Conclusion

The Parallel Extensions in .Net 4.0 are going give developers a much easier and consistent way to parallelize their applications. The library greatly insulates us from the complexity and inner plumbing of the parallel world, but still have responsibilities to use them properly. Hard questions and issues will remain around the architecture, design and implementation of parallelization in our applications, but Microsoft is aware of this and is busy providing us with more resources than just the tools in this library. The Parallel Computing Developer Center has a wealth of whitepapers and presentations on these topics.

Source code for the Parallel.For example

* I’d really like to track down and ~~beat~~ speak strongly to the ~~bastard~~ person who coined the term “parallelize” because every time I talk about this feature I invariably drop a syllable and tell my audience how easy .Net 4 makes it for you to paralyze your code**.

** On the other hand, if you don’t keep the pitfalls of ~~the work of the devil~~ multi-threaded programming in mind, your code will wind up paralyzed, so it’s still an accurate statement.

The Blogger Next Door - Update

2009-05-01T14:50:00.001-07:00

It’s been about a month since I made my post about The Blogger Next Door, referring to Bil Simser’s The Girl Next Door post – well, Bil has now posted an update, including pictures of Natalie receiving her new laptop with Dragon Naturally Speaking at her birthday party this week. On top of the laptop and software, Bil’s post raised $2100 to help Natalie’s family with the medical expenses.

A Bit About Nuance Communications and Dragon Naturally Speaking

One of the things I find most impressive about the result is the actions of Nuance Communications, makers of Dragon Naturally Speaking.

After reading Bil’s original post and making my own, I gave in to a bit of a whim and faxed a letter to the CEO of Nuance, referencing Bil’s blog and briefly describing the situation. I faxed that letter after close of business on a Friday afternoon.

Before 10:00 AM Monday morning, I had received an email from the Dragon Naturally Speaking Product Manager telling me that they had emailed Bil to offer a free copy of the software.

They really didn’t have to respond at all and certainly not that quickly, but they did – and it wasn’t because of any great amount of publicity they’d get for the deed. There were no national news vans hovering around this story – they did it because they were able to help and wanted to. That’s the best reason.

So, for what it’s worth coming from my little blog, the folks at Nuance are a stand-up group and I know I’ll be looking to them on any project I work on that might benefit from their products.