What could go wrong?

[Howard F. Cunningham]

Hi See my comments below


Howard Cunningham, MCP
howardc at macrollc.com<mailto:howardc at macrollc.com> - personal
For technical support, send an email to service at macrollc.com<mailto:service at macrollc.com> or call 703-359-9211 (24/7)

From: kf4hcw [mailto:kf4hcw at lifeatwarp9.com]
Sent: Monday, June 29, 2020 10:20 AM
To: Howard F. Cunningham; tacos at amrad.org
Subject: Re: What could go wrong?

On 6/29/20 9:54 AM, Howard F. Cunningham wrote:

Today’s Windows rarely needs to be rebooted, if only Windows is running.  What you are running into is a program that is not playing nice and creating problems.

I beg to differ -- I am in the position to directly and indirectly support many systems on many different platforms and of all of them Windows is the most misbehaved. As for requiring the restart -- this is my direct experience. If left to run for more than about 30 hours, clock jitter creeps into the system and the scheduler no longer keeps pace with the data up and down with the flex6300 -- this causes missed samples which amount to wideband noise in the channel. The only mitigation that has been successful is the reboot. (I tried everything except for running dedicated hardware).

[HC:>] When you say clock jitter I think that you are saying that the clock drifts, probably slower, over time.  This tells me that the system is busy and missing the clock timings.  When Windows starts, it checks the BIOS clock for its time.  While running Windows does not check the BIOS clock but rather updates a counter which is used for the time.  I wonder if telling Windows to use a ntp server would solve this problem.

As for "Today's Windows" - For some things win 7 pro is still required (due to driver and other support issues) and in any case Win10 is just as nightmarish and unstable if not worse... again, direct experience, not a myth.

[HC:>] That is not our experience with Windows 7 and Windows 10.  We have found Windows 10 to be more stable than Windows 7.

I work with systems that almost never need to be restarted most of the time -- all of the win* boxen I must manage frequently have these and other issues when compared with my lin* boxen. It's not a myth, it's an inescapable burden I fight every day.

[HC:>] I never said that Windows was more stable than Linux.

It's my experience that most folks are so used to rebooting Windows on a regular basis that they don't even notice they are doing it. As a result they don't run into some of these issues simply because as a matter of course they regularly reboot for all sorts of reasons (often enough not even their choice).

[HC:>] My clients do not routinely reboot their computers.  What usually happens is that the systems are rebooted as part of the monthly patch process.  That most likely prevents us from seeing the need to reboot random Windows 10.

Trying to support long-running timing critical software on Windows is problematic and requires special care -- that's all I'm saying. I didn't make it up.

[HC:>]  I never said that Windows never needs rebooting and I did not say that there are never problems on some Windows systems.  The problem has very muchly improved today.  What I should have said is that Windows should not need to be rebooted daily or even weekly.  Where we see this problem we are able to track the need to reboot down to a specific program that causing the problem.
 A thought on the unlimited amount of data..  You could try running a scheduled task to delete the data.  Keep in mind that I do not know if this data is needed or what happens if the data is deleted while wispr is running.  If wispr needs that data while running, you could try using a scheduled task to shutdown wispr, delete the files, and restart wispr (assuming that wispr does not require any keyboard interaction to start)

I don't think it's required by wspr -- wspr is simply generating the data as some kind of log... given the unmitigatable bloat of win* 40G of disk space is not enough after a few days and wspr will generate enough data to fill up the remaining space; but since I have to reboot it in order to avoid the timing problems it's a) not a problem to delete the data (there is indeed a menu option for it in the program) and b) a scheduled task would not run reliably because of the necessary reboot.

[HC:>] We use a tool that allows to schedule things like deleting files like this.  We have also used it to reset the clock on a couple of systems that has clock drift.  That was years ago.

It's not as terrible as it seems -- one should check in on these kinds of systems periodically as a matter of course anyway; so handling the required reboot and reset as part of that maintenance is easy enough to fit in.

[HC:>] We do monitor all of our client systems to hopefully catch problems before the client sees them.

_M



--

kf4hcw

Pete McNeil

lifeatwarp9.com/kf4hcw



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amrad.org/pipermail/tacos/attachments/20200629/4c6bdb49/attachment-0001.html>