On Stability of XTension
James Sentman
james at sentman.com
Thu Oct 10 13:26:57 EDT 2013
I'm on the same side of the isle as you Brian. I upgraded my mini last year and have kept my OS current on it since then. I have 2 7 port USB hubs (though good, metal and externally powered and grounded ones) maxed out, literally a dozen different USB/Serial adaptors, another dozen or more sources of data in the form of arduino projects or other ethernet or xBee connected devices.
So I'm the one of the team that pushes the envelope in that direction ;) I dont really think that there is anything built into the system to make it problematic or crash prone, but it certainly seems that things can get that way. My own experience is that it's really rock solid. This new mini has not had a single freeze or kernel panic since the day i turned it on. The only reboots have been for system updates.
From observing and helping folks I regularly see 2 kinds of problems. Not specifically OS version related. I see scripts that can get corrupt. I dont know how this happens. Scripts are very much handled by the system, I never get to even see the guts of them until I ask the system for the entire opaque block of data to write it to disk and for some people once in a while a script stops returning any data this way, or returns corrupt data.
XTension does it's best to work around this problem, right now you have to restart with the option key held down and select to recompile all the scripts. That makes them all fresh again, but will lose any saved local variables that you might be using in them. This should either solve any problems, or at least indicate that one script is so badly gone that it can't even get the source out of it to recompile. In which case you can manually go in to the edit script dialog, and it will be blank because the system refused to return any source, and hit the revert menu to get the last text and save it again.
I did have one script on my old system that did this twice a year. It was the script that drove the little VCD display up in my office that shows a clock and motion hits for the system in real time. (connected now over an xBee encapsulated serial port and a DIY interface) this script ran every second to update the clock so it was getting a lot of work. I dont know if that had anything to do with it or not, but it's working perfectly now and has been since I upgraded my mini.
The new XTension version I'm testing now bothers system less often for the data of the script so if thats the reason it should reduce it happening, but it also has the ability to recover automatically from errors in a script like this because upon a good compile I am now saving off a backup of the compiled script data which I can restore from as soon as the script starts returning these errors. So going forward this will be an automatic repair of the script data. This is a work around and not a real fix for the problem, but it will mean an increase in reliability for people who are having this problem while we continue to dig at it and try to figure out why.
The other problem that is also very real is the damnable USB bus resetting. This has been a plague since OSX beta and doesn't just affect XTension. It just effects XTension more because we tend to have so many devices plugged in. I will bet real money that any kernel panic or system freeze that you can't narrow down to failing hardware/disk/memory is due to this. Any induced noise or bad connections on the USB bus can cause it to reset, which unloads all the drivers from the kernel and then immediately comes back online causing them to try to reload into the kernel. This is like plugging and unplugging your devices with only a few milliseconds between them and the drivers bump into each other unloading and loading and the whole machine can crash. I've had machines that were prone to this in the last. My old PPC titanium laptop that became my house server so many years ago I can't count would reliably kernel panic everytime the AC blower started up in the attic on the other side of my wall. I finally had to move it to the other side of the room to make it stop. You can look for this in the logs though, the system will log kextunload and kextload messages for the USB devices, often hundreds of them in a row, if this is happening.
And just lastly XTension is a scripting host. It's entirely possible to do really horrible things to the poor scripts that I can't fully guard against that you didn't really mean to do.
Dont forget that the storage of a script is cumulative and is actually saved to the database. If you keep appending to a string, that string stays in memory from one run of the script to another and can grow to the point where it crashes the program due to memory access delays. You could keep appending to a list and cause the same thing. You can create a script that causes the script to run itself somehow until the stack overflows. XTension will try very hard to recover from a stack over error and will probably do so 99 times out of a hundred, but that hundredth time it will crash. So you might not even be aware that this is happening, that script just took a while longer to run, but it worked so there is no problem. Except the hundredth time it will take down the program. There are probably more things you could do in a script that could cause havoc too ;) Thats not to imply that any of these issues are your own fault, but it's impossible for us to test the same environment that you have and why we always ask to see peoples databases because you may have solved your problems in a way that never occurred to us.
On Oct 9, 2013, at 6:24 PM, Brian Williams <brwill at me.com> wrote:
> So, I made a change, and it is everything that Michael seems to recommend
> against. I installed a current-model Mac mini (Mountain Lion) to host
> Xtension, I have made it my iTunes library (Home Sharing), and have hung 4
> external hard drives off it - one to serve as the disk space for iTunes, and
> three to serve as backup (Time Machine) repositories for the Mac mini and a
> couple of Macbooks. I made the full switch over this past weekend, and
> everything seems to be running well. I am running it headless and manage it
> using screen sharing. It is put away in a cabinet, along with its own UPS,
> which serves only the Mac mini and its peripherals.
>
> This note is not intended to counter anything that Michael wrote, as quoted
> above. I am just sharing my current experiences, and look forward to the
> continuing evolution of Xtension, especially the evolution of Web Remote.
Thanks,
James
James Sentman http://sentman.com http://MacHomeAutomation.com
More information about the XTensionList
mailing list