nice Mini-ITX box

The front cover has two side blades, eacj with a beveled arrowhead sort of end. They snal into narrow slots in the main board. I suppose one could get the front cover off by removing the other covers and unlatching the tangs somehow, but that would be absurd. There are two USB ports under the front cover, and it doesn't make sense to disassemble the entire system just to plug in a mouse.

It works fine with the side tabs broken off.

It's surprising how much stuff you have to re-engineer, right out of the box.

I built an interface to the RTDs and the gas furnace

ftp://jjlarkin.lmi.net/Auto_wired.jpg

which has three relays, one wired across the heater thermostat and two available for other uses. If I can persuade the webcam app to not hang/recover when the modem is powered down, I could kill power to the modem with a relay. But then, why not just kill it with the mechanical timer?

Assuming the PC and XP is healthy and running for months at a time. I reboot my desktop PCs when they get slow, which they do, from memory leaks or whatever.

Powerup/down once a day is hardly unusual wear and tear on a PC. Lots of people turn off their PC every day.

The mechanical timer has the virtue of always working, irrespective of the states of a few hundred million lines of code.

John

I didn't use the task scheduler. I just loaded shortcuts into the 'startup' folder which is buried, well, somewhere deep in some other folders, somewhere.

John

Well, things get power cycled at 2AM, or 4AM, instead of 3.

John

Well, they do for speed, but not so much for reliability!

I also remember many an early cable modem or DSL modem being quite flaky; they just weren't reliable enough for 24/7 operation, and when you called to complain they'd tell you, "oh, you're using our consumer/residential grade equipment -- for 24/7 use, you need to upgrade to our commercial grade equipment at 5x the price!" What the hey!? Consumers aren't worthy of models that don't require manual reboots every now and again?! Bizarre...

But things do seem better these days. I have a Netgear DGND-3300 DSL modem/router/wireless access point that I've *never* had lock up, and it's been in use a couple of years now. Prior to that I had a "low end" commercial modem, a Netopia 3346-ENT... that worked fine, which had the traditional text-based interface (that you telnetted to -- no web-browser-based configuration!), and there were a bazillion options that I never did spend the time to fully understand or appreciate.

(I do realize that "it works just fine for me!" sometimes doesn't mean much -- many people never turn on port forwarding or any even slightly-fancy features of a router, certain ISPs use DSLAMs that tend to "provoke" bad behavior in not-quite-perfect modems, etc.)

---Joel

The computer knows about daylight savings. Does the timer know about daylight savings?

That depends on the filesystem and the mounting/journaling mode.

The Linux "ext3" filesystem has several different journal modes, which provide different tradeoffs between performance and reliability.

The most "paranoid" mode is "data=journal". This writes all of the file data into the journal, and then commits it to the real locations on disk in an order which guarantees correctness. If I understand things correctly, this will ensure that a power outage part-way through the file write will result (after reboot) of all of the file's which actually made it into the journal, ending up in the real file, and the file's size actually corresponds to this. This is what you use when you really, really want the data to be correct and not-lost.

"data=ordered" is a bit less paranoid, in that it doesn't write the data changes to the journal - just the metadata changes which say where the file will be. It does ensure that the data changes are pushed out to the disk before the metadata changes are written to the journal (and then committed). With this option, you can lose un-written data if power goes out or the system crashes, but this won't leave you with a situation in which a file appears to have been updated but has "stale" data in its disk pages. This is the default journaling mode for most ext3 installations.

An even higher-performance (but less-robust) option is "data=writeback", which doesn't enforce data-before-metadata ordering. Its journaling of metadata changes will ensure that you don't see file-level inconsistencies (lost inodes, two files pointing to the same sectors on disk, etc.), but you *can* see stale data in files which were in the process of being written when things went *foom*.

I imagine that other journaling filesystems have similar "tuning" modes, which trade off robustness for performance.

In most Linux installations, writes to files do go into the in-memory buffer cache first (making the writes "appear" to be very fast), and are written-back to disk periodically (every 5 seconds, in many installation). This behavior can usually be tuned, or even over-ridden (forcing synchronous access) on a per-filesystem or per-file basis via various sorts of options on the mount() or open() call.

Where, in Task Scheduler, is the shut-down action available?

EWF does not always play nice with other drivers (or possibly the other way around). When our machines misbehave with a particular incarnation of out software, the first thing we do is check if that feature has turned itself back on again.

I've often wondered just how much extra performance is obtained with this option -- on most systems, if there's a significant performance boost (say,

While I hesitate to describe anything about WinXP/XPe as playing nicely, it has been pretty bulletproof once we got a good embedded image to burn. Of course, with all of the inter-dependencies in XP, a minimal logon image was a fantasy but it did finally work once I included the kitchen sink, its parent retail store, and everything in it ...

Now *that* sounds more like XP! :-)

Won't work. You are also mistaken file system integrity with protection against loss of data. If half of the file is still in memory and the other half is on disk when the power goed out then you will have half the file on disk and the other half is lost. A journalling filesystem will not get corrupted in such an event but the data in fact is corrupted!

If you say so. I suppose it is Larkin bug free now.

I suspect looking at it carefully would have revealed the way in. A lot of these plastic mouldings have sneaky ways to unlock the clips.

Pretty dumb then not to have considered the problems you have with the modem hanging up then and provides a couple of extra sets of contacts.

XP isn't that unstable. It will run for weeks provided you are not running something that includes gratuitous memory or handle leaks.

There is a big difference between pressing the button on the front to instigate an orderly shutdown and summarily removing the power by pulling out the plug without any warning and potentially in the middle of a disk write. XP is fairly robust but it will suffer degradation and certainly much longer bootups possibly requiring manual intervention.

Though the mechanical timer may well end up after a while being the only thing that *is* working. UPS gear is cheap enough and would allow the thing to shutdown gracefully (and also when the power line dies).

Regards, Martin Brown

Provided that you're brave enough to run it unpatched. Otherwise it reboots the second Tuesday of each month, and usually more often than that.

Cheers

Phil Hobbs

In this case (if the design is done correctly), the file would be lost (entirely), or truncated (partially written), but would not be corrupted (stale or incorrect data appears when you read back the file). In many applications those are significant differences!

You are *always* going to face the possibility of some loss of data... if the system resets or loses power in the middle of transferring a sector over the I/O bus to the hard drive, that sector (at least) will be lost.

You can't avoid this problem even with an indefinite-lifetime RAMdisk. The data is always *somewhere* (in transit or in construction) before it arrives, intact, at some sort of storage device which can guarantee "I won't lose data, no matter, no how" - and during that transit or construction it's vulnerable to loss.

Good filesystem journaling can reduce the odds of losing data that you thought had been written, and can greatly increase the confidence that the data you read back is actually valid and was not corrupted as a side effect of the power loss.

It's a common fault, and windows will gladly produce an error message telling you to replace the device ;)

Yup, and sometimes you need to remove, wait, replace device for it to be recognised.

Sometimes it's what you need to do. Any machine expected to work reliably needs some form of watchdog timer to kick things along when they lock up.

I've found a modern machine with 4GB memory can take as long to boot as to restore from hibernate -- besides, if there's active network connections it's common for them to lockup during hibernate or sleep.

Remote servers have that problem solved by fitting a card with serial line, so one can talk to the box when it is down, reboot it and so on. Not cheap.

Grant.

Turn off the front cover?

But how is the task scheduler going to know that the mechanical timer is about to switch?

John

Who cares? I'll be sound asleep anyhow.

John

But when the covers are on, there's no way to see the latch hardware, short of a CT scan. And the only way to get inside, to see how it latches, is to remove the cover. Oh, but it breaks if you try to remove it.

HAving seen the insides, it's still not obvious how one would remove the cover. Maybe it's intended to be used by people with higher IQs than mine.

And why would the designer implement a "sneaky way" to remove a removable cover? You would think his job was to make it obvious.

I just told you that I have extra relay contacts, under computer control. You can see them in the pic. The timer is easier.

I wouldn't have expected a cable modem to hang up for no good reason.

John

No, a legit copy of XP.

That's the obsolete one, no?

To be legit, you have to

We have stacks of them.

John