[Equest-users] Multithreading

[Brian Tysoe]

Hwakong,

That did it!

I set the compliance mode to none and the performance is much faster.

I was previously running in "LEED-NC - v3.0 (LEED.bin)" compliance mode. The compliance function was not working on this particular file anyway.

Thanks!


Brian Tysoe M.A.Sc., P.Eng., LEED AP
Mechanical Engineer

MCW Consultants Ltd. <http://www.mcw.com>
600-156 Front Street West
Toronto, ON M5J 2L6
Phone 416-598-2920
Fax 416-598-5394

This e-mail may be privileged and confidential. Any unauthorized use is strictly prohibited. If you received this e-mail in error, please contact the sender directly.

From: Hwakong Cheng [mailto:hwakong at hotmail.com]
Sent: May 19, 2011 8:16 PM
To: Brian Tysoe
Subject: RE: [Equest-users] Multithreading

Brian - I haven't actually used 3.64 much yet, but I have sometimes encountered it running extremely sluggish, as you describe, and other times running just normally. I think that we decided that changes to the compliance engine were to blame; that eQUEST is slow when you have selected one of the compliance modes (like Title 24) and that it runs normally when not in compliance mode. I haven't thorougly tested, but that was our theory. If this is the case for you (maybe not if you're in Toronto?), it seems that you may just eventually need to put up with the sluggishness, but one way to partially get around it is to change the compliance version to "none" while you are working on editing the model in detailed mode, and then put it back to your compliance mode closer to the end when most of your inputs are complete.

Didn't reply to the full list because I'm not positive this is a real fix/workaround but let me know if it works for you.

Hwakong
________________________________
From: BTysoe at mcw.com
To: equest-users at lists.onebuilding.org
Date: Thu, 19 May 2011 14:05:43 -0400
Subject: [Equest-users] Multithreading
Hello equest-users,

Does anyone out there know if the next release of eQuest (based on a new version of DOE 2 I believe) will be able to make use of processor multithreading?

We are running into problems modelling large buildings with eQuest 3.64. Files are taking upwards of 5 minutes to open and once they are open it takes about 8 seconds to modify any single field. If you want to change the flow rate of an AHU you enter your number and then wait for 8 seconds while the software thinks about it.

We have done some monitoring and found that the software is running on one processor core at 100% and that is the bottleneck.

Exhibit A: Loading the model


In this graph (taken while loading the model) you can see that eQUEST's CPU usage is constant. It is only using one of the available CPU cores and it is using that core to the max. Compare this to the Disk usage and you can see that the Disk usage spikes up several times but those spikes are relatively low.

Exhibit B: Changing values


In this graph you can see the CPU usage spike up when I made a change in eQUEST and then dip down several seconds after. The Disk usage is still sporadic and low.

We have concluded that adding RAM will not speed things up. The best solution is a faster processor.
Has anyone else done any similar benchmarking and want to share their findings?

Thanks,


Brian Tysoe M.A.Sc., P.Eng., LEED AP
Mechanical Engineer

MCW Consultants Ltd. <http://www.mcw.com/>
600-156 Front Street West
Toronto, ON M5J 2L6
Phone 416-598-2920
Fax 416-598-5394

This e-mail may be privileged and confidential. Any unauthorized use is strictly prohibited. If you received this e-mail in error, please contact the sender directly.


_______________________________________________ Equest-users mailing list http://lists.onebuilding.org/listinfo.cgi/equest-users-onebuilding.org To unsubscribe from this mailing list send a blank message to EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG<mailto:EQUEST-USERS-UNSUBSCRIBE at ONEBUILDING.ORG>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20110519/75ce4b67/attachment-0002.htm>