standby/resume - clock fast until caught up

Just an observation...

I frequently put my workstation in standby and resume.
OpenVMS running on FreeAXP typically survives this great, except for the network.

In general, just hit a return on the console and there is the next prompt.
This morning I noticed my box running hot, and it was FreeAXP.
A simple monitor mode reacted odd... not waiting at all it seemed.
Monitor/int=100 brought it under control... refreshing every few seconds.
Using simple manual timing I noticed the clock was ticking /adjusted at about 200 seconds every 10 second! That's good for 15% interrupt time, 6% kernel according to monitor.
All the while the clock was 'behind' real time.
On a hunch I let it catch up with the real time and sure enough it started to behave normally once it was back in sync.
Manually setting the time backwards did not cause a repeat.

[ XP-sp2, Pentium-D 3.0 Ghz, FreeAXP x86 version 1.1.0.307 (Sep 6 2010 13:39:22) OpenVMS 8.3, TCPIP 5.6, RDB 7.2, Datatrieve... ]

fwiw,
Hein

<hr>Hein van den Heuvel
HvdH Performance Consulting
firstnamelastname.gmail.com

Now running 2.0-377
Unlike before VMS no longer seems to continue after sleep+wake. .
Too bad, I liked that.. even if it was a little quirky and the network did not survive going to sleep.

Hein

<hr>Hein van den Heuvel
HvdH Performance Consulting
firstnamelastname.gmail.com

Actually, I might not have been patient enough.
At works after all

After an overnight pause, i resumed, and did not get a response in the console terminal window.
I tried to connect a fresh Putty session to localhost 9000 which gave a freeaxp header but no more.
But when I looked back a few minutes later, all my carriage-returns were acted upon. Maybe it was 'catching up' on the sleep time?
Hein.

<hr>Hein van den Heuvel
HvdH Performance Consulting
firstnamelastname.gmail.com

It is not a really big deal, but I would love to somehow be able to continue OpenVMS after a Reasume from Pause for the host (Windows) OS.
It is really close: OpenVMS itself continues just fine, accessible from the console which already helps me some.
But the network does not come back.
A simple TCIP stop / restart would be great, but that does not fix it (for my OpenVPN loopback based network config)
I need to
- fully stop FreeAXP (&gt;&gt;&gt;exit
exit: No such command
- C:&#92;&gt;net stop msipcap
The Migration Specialties Network driver (PCAP NDIS 5.0) service is stopping...
The Migration Specialties Network driver (PCAP NDIS 5.0) service was stopped successfully.
C:&#92;&gt;net start msipcap
The Migration Specialties Network driver (PCAP NDIS 5.0) service was started successfully.
- Now start FreeAXP and re-boot OpenVMS

I am very grateful for that already,
but I am still hoping/wishing that someone figured out a way to get the network going without having to reboot.

Thanks!
Hein



<hr>Hein van den Heuvel
HvdH Performance Consulting
firstnamelastname.gmail.com

This is on our "nice to add in our spare time" list. When Windows hibernates it breaks the link between the emulator and the network driver. The link is not automatically re-established when Windows wakes up.

On a related note, we were discussing the clock "catch-up" feature. This is primarily there to ensure the emulator "hardware clock" stays in sync with the host hardware clock. It was not designed to take laptop style usage into consideration. We were discussing having the catch-up feature ignore the large discrepancies that occur when a laptop is placed into Standby or Hibernation. If we do this, the emulator clock and VMS or Tru64 will remain at the date/time it was at when the host system paused. Is this desirable, or do you prefer to wait for the emulator to catch the time back up to the host?

&gt;&gt; The link is not automatically re-established when Windows wakes up.

I'd be happy with a manual work around before or after the pause.
Maybe a "net pause msipcap" or accept a "net start msipcap" to do a re-start after wake-up.

The catchup hasn't been too bad, as long as one understand what is happening. It is sort of a waste for when you don't use FreeAXP over a specific wake-up. I'd be happy do issue a manual SET TIME after un-pause when i know I'll actually use FreeAXP (which is rather often!).
I'd settle for a jump forward in time for the clock. Not sure what would break with that. Sure, T4 and similar might look ugly, but it woudl be cear something was going on. A fake catchup time period is harder to explain.
Keep up the good work! Much appreciated. Hein.



<hr>Hein van den Heuvel
HvdH Performance Consulting
firstnamelastname.gmail.com