Page 1 of 1

V3.30 stability

Posted: Fri Jan 09, 2009 8:28 am
by sundodger
Is anyone seeing the latest version crash more often. My V3.3 seems a lot more unstable and rarely stays running for more than 24hours.
would be interested to see if anyone is having the same problem.
thanks Mark..

Re: V3.30 stability

Posted: Fri Jan 09, 2009 10:48 pm
by vcruz777
I have seen more crashes than before and a database corrupt error which I hadn't seen before. In addition I have seen in a couple of ocassions the CPU going up to 50% and staying there. Housebot continues running normally but I have to restart it to get my CPU usage down. Not sure if it is related to 3.30 since I am constantly changing the configuration but in my last crash when I hda problems with the database the only way I was able to solve it was going back to 3.20. I am now back to 3.30 again, lets see.

Saludos,

Victor

Re: V3.30 stability

Posted: Sat Jan 10, 2009 8:17 am
by Richard Naninck
There has been a lot of email traffic outside the forum to get to the bottom of at least one error that seems related to hanging tasks. The one thing that resolves this for now is setting the cpu affinity to use just one core. Obviously this is only true if your system is running dual core or higher. You might try to use only one cpu core and check again the uptimes. For some reason a hanging task gets a runtime error in the task thread, but HB doesn't shutdown and doesn't produce a dump.

Re: V3.30 stability

Posted: Sat Jan 10, 2009 3:08 pm
by sundodger
only running a single core. so that is not it my end.
any more ideas?

Re: V3.30 stability

Posted: Sat Jan 10, 2009 6:05 pm
by Richard Naninck
sundodger wrote:only running a single core. so that is not it my end.
any more ideas?
Meaning you don't have a dual core cpu? In that case my reply doesn't help you.
If all is OK, whenever HB crashes it produces a dump. If these dumps are consistently the same, you should report those to Scott. Even if the dumps are different all the time, they might have something in common. The HB Server should be able to run without any issues. I have seen uptimes of above 30 days so if anything is wrong and it is HB induced, you should/could report it...

Re: V3.30 stability

Posted: Sun Jan 11, 2009 4:01 pm
by ScottBot
sundodger wrote:Is anyone seeing the latest version crash more often. My V3.3 seems a lot more unstable and rarely stays running for more than 24hours.
would be interested to see if anyone is having the same problem.
thanks Mark..
Mark,

When the system crashes, it should create a file in the \HouseBot\Dump directory. Please send me (support @ cebotics.com) the latest dump(s).

Re: V3.30 stability

Posted: Mon Jan 12, 2009 10:06 am
by ScottBot
vcruz777 wrote:I have seen more crashes than before and a database corrupt error which I hadn't seen before. ...
If anyone having an issue where their database gets corrupted due to the system crashing, be sure to check and make sure that the write caching for the disk (a windows setting) is disabled.

Re: V3.30 stability

Posted: Mon Jan 12, 2009 10:26 am
by Richard Naninck
Scott:

Is that write caching the same as having no virtual drive other than memory only? I don't get to see much dbase errors and I know how to fix them easy but occaisionally I get my dbase corrupted when something heavy happens and HB crashes or the PC reboots while HB was running (blue screens)

Re: V3.30 stability

Posted: Mon Jan 12, 2009 10:42 am
by ScottBot
When you say, 'except for memory', my response is that you want to try and remove any memory caching from the writes as much as you can. Now there are obviously memory transfers along the way, but the trick is to not cache anything in memory.

In Vista, you can configure a drive (it may depend on the capabilities of the drive,driver,or interface), to 'enable write caching' on the disk. You can find the option if you dig into the properties of the drive under a 'Hardware' tab in the Property page. In XP I think there was a policy option in same general area to optimize performance (via caching).

It's an option that will greatly increase write speeds, which is very handy for a file server that you write (not read) a lot of data to. The bad part about it is that when data is cached like this and the system goes down, there's really no telling what state the physical file (HouseBot database or any other file) was in when it was last written to, but you can probably be sure that it was not with the complete data (since some of the data would have still been in the memory cache).

On my development system, I constantly kill HouseBot in the middle of a debugging session where the database would be left open. I can't remember the last time I corrupted my own database, so I feel fairly confident in the jet/access DB and drivers at least under this particular setup. That's why I'm wondering if caching is somehow involved in these DB corruptions.

Re: V3.30 stability

Posted: Mon Jan 12, 2009 11:24 am
by vc1234
Scott,

The suggestion to disable the disk on-board write cache is a good one, but folks probably should be aware of severe performance consequences. As I posted elsewhere:

"On my laptop, with WCE (write cache enabled) I get 20MB/s throughput for 64K OS-cache-bypass writes; without WCE I get only 3.6 MB/s."

Similarly, to hibernate (saving memory image to the disk) takes several minutes as opposed to about half a minute with cache enabled.

It may not matter if the computer is used solely for HouseBot.

Re: V3.30 stability

Posted: Mon Jan 12, 2009 11:33 am
by ScottBot
Victor,

Yes, I tried to point out the performace issue in my post. I agree that it is a significant performance difference. My HouseBot server also doubles as a file server and even runs MCE. I enabled write caching to get all of the files (photos & music) transferred quickly, but then disabled it and I really don't see any performance issues, since generally music and photos are read from the disk and this option should only effect writes. I'm actually pleased that MCE seems to run without issue either.