Jump to content

ShaunR

Members
  • Posts

    4,862
  • Joined

  • Days Won

    296

Posts posted by ShaunR

  1. Luckily, we don't have to guess. It's called math. :-)

    A guesstimate is not a guess. It is an estimate without having all the facts. As Order Of Growth is a simplified relational analysis and usually only denotes a upper bound; it is a "guesstimate" however much maths you put around it. It is a very crude way of describing processes.

  2. It's in my profile.

    We have so much code and libraries that we don't upgrade very often. The last upgrade happened when we went from 7.0 to 8.6 in December of 2008.

    I try to participate in the betas and keep up on things, but I'm falling behind the times. I did download 2012 today, but won't do much with it until the end of the year. We might start our next project on 2012, the latest TestStand and win7

    This is quite common so I wouldn't feel too left behind. Moving to a newer version represents a significant project risk and if/when you upgrade (which should be for a very good reason rather than there is just a new one) it's better to let other people find all the bugs/issues and any work-arounds for them. I'm still on 2009 which is far more stable and performant than than 8.6 (and, anecdotally/arguably, more performant than everything to date) and I'm waiting for a feature list or bug list that warrants an upgrade.

    However. Back to toolbars. The change was made in 2011. 2009 and 2010 both have the (much better IMHO) standard 3D button bar.

  3. Hi ShaunR. Is this figure of 8 independent of CPU core count (ie. in my case I have 8 logical cores)? The reason I ask is that the threadconfig.vi in the sysinfo.llb allows me to specify up to 20 threads in each combination of execution system and priority. I might be understanding this wrong, maybe this ability in threadconfig.vi is misleading? On my machine all the table entries were set to 8 initially as you suggested.

    Or is this a case of a single thread, per execution system, per priority per CPU core (hence the default of 8 in the tables on my machine)?

    Hmmm. In 2009 and 2010 it was max 8 per exec, per priority irrespective of the number of cores. Max 200+1 in total.

    I've just looked in 2011 (I rarely use it) and indeed you seem to be right; you can set 20. However, it can be set to 20 on both my Quad core (8) and my dual core (4) so I think they just bumped up the limit rather than made it scalable in accordance with number of cores.

    • Like 1
  4. Thanks everyone for your posts.

    The solution I have run with is separating the tasks out into each execution system. In particular, I placed only the tasks with .net calls into the "Other 2" execution system and specified, by the configuration ini file, for 20 threads at Normal priority (there are 20 maximum simultaneous calls to the dll) for this ES. I added this as a Post-build action in the executable build configuration to automate that process.

    This has fractionally increased CPU loading by a few percent as expected but also allowed all the remaining tasks to operate within their required timings (ie. now properly "insulated" from the dll calls). So it would appear the .net dll calls were consuming all available threads, as suggested by Mark Smith.

    I'll dig deeper into seeing if I can improve the performance any further (ie. via tweaking VI priorities) but this helps me out for now, thanks all for your help!

    The maximum is 8 per execution system, per priority. You can get your twenty by spreading them over 3 execution systems (for normal priority)

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.