Last month we released InTime v1.2, and we've been pushing out a number of incremental updates ever since.
While the past few versions have been all about introducing new kick-ass features into InTime, this time we focused on working out the kinks. Here are the highlights of this version.
New "Seeded Effort Level Exploration" Recipe
Like the cousin of the placement seeds, we find that the "placement effort level" setting has a similar "random" effect. In fact, the impact on results does not correlate with the description. According to the documentation, it is intuitive to think that higher values for effort levels will yield better results. However, our tests and customers' results do not indicate a consistent relationship; instead, they display almost random-like characteristics. What we did learn from this is that certain effort level values work best when combined with certain seed values, and they seem to operate within a smaller variance than seeds.
The new "Seeded Effort Level Exploration" recipe is created so that we can leave InTime to automatically iterate through the different combinations, without us humans getting into the way. This recipe can be configured to run effort levels on the top strategies, and then apply placement seeds to find the sweet spot for these two settings. Our approach recommends that this recipe is only used near the end phase of the project, meaning it is best applied after you have derived the optimal strategy with InTime.
Smarter Private Cloud
One of the modes in which you can run InTime is "Private Cloud". It is a generic term that we use to refer to the mish-mash of computers and network equipment sitting 3 floors below you in the datacenter. One of key goals of InTime is that we wanted it to operate under any IT conditions, whether it is a pool of desktop computers or a highly guarded datacenter facility. We spend a lot of time polishing and optimizing the performance of the InTime private cloud mode.
Although this is something which is mostly transparent to the user, optimizations in this area have a big impact on the runtime of big designs as well as the workload added to the customer's networking infrastructure. Here are a few highlights of the optimizations which made it into the v1.2 release:
- Improved queuing algorithm: The server now hands out individual strategies to workers instead of dividing the complete job into chunks and handing those out when the job starts. This is because we found out that our customers' IT infrastructure is prone to failure, just like yours and mine. Workers may be killed if one of the machines is not responsive. This change allows us to dynamically reallocate builds to other available machines.
- Reduce network load: As designs get bigger and more complex, not only do the designers work harder, but filesystems are taking on a higher load. Projects consuming quite a few GBs are commonplace. Hence, all files transferred over the network are now archived and only things that changed are submitted, greatly reducing the load placed on the network infrastructure.
- Reduce worker load: The load placed on individual worker machines while running strategies have also been optimized, resulting in significant per-strategy runtime improvements in jobs with many strategies.
Stability, Stability, Stability
One of the big focus areas of the v1.2 release and its incremental updates have been the overall stability of the product. We've ironed out issues to make InTime more polished and more stable than ever. We have also focused on making the first-time user experience as smooth as possible and that the documentation is as clear as possible. Most importantly we've paid great attention to customer feedback, adding and changing things based on their likes and dislikes.
A bunch of other useful and important things are part of the latest release, so make sure to check out the latest release notes here.