I started to develop a new Windows 10 images for our WDS. I know we are a little late still running W7... but i have a problem concerning W32TM.
We had problems adding computers to the Domain after we deployed an image to a new computer because of a time difference. Lots of the new computers are sometimes days of. So before adding computer to the domain i batched a timesync. So I started W32Time service, added the locally time server and did a W32Time /resync /force.
On W10 the force does not work any more and I receive a message the time difference is to big. So i searched the Internet and found to edit the Register to increase the time limit from 54000 seconds to 4294967295 seconds. But i still receive the same Error message.
So i looked into the log and found some interesting. The Error ID is 34 and the text makes no sense. Well it is in German. Before i made the REG-Change the error message was:
Der Zeitdienst hat festgestellt, dass die Systemzeit um 82597 Sekunden geändert werden muss. Die Systemzeit kann durch den Zeitdienst um maximal 54000 Sekunden geändert werden.
So this is telling me the 82597 seconds are more than maximum of 54000 sec. Well this made sense, but after the Reg-Change it told me:
Der Zeitdienst hat festgestellt, dass die Systemzeit um 82597 Sekunden geändert werden muss. Die Systemzeit kann durch den Zeitdienst um maximal 4294967295 Sekunden geändert werden.
So the 82597 seconds won't fit into the 4294967295... I'm not that good in Mat, but eeehhhh.
Now even more strange. I started the Time and Date configuration app (or how it is called in English), set it to manually and changed the date to fit in the 15H/54000Sec. I switched back to automatically, and it switched back to yesterday.... Why? Time zone is correctly set to UTC+01:00
Next step: BIOS... edited Time and Date correctly in the bios, booted W10 and finally i could sync the time... using the GUI. But than i tested the script, and noticed it gives the same error and time and date went off 27 hours again. Even totally unlogical time i.a. now it is 12:13 and the time on the machine is yesterday 8:39. Hmm I did another restarts and BIOS-change to demonstrate this to my colleague and now the difference has changed. Time now 12:25 time on machine yesterday 8:29.
Also tested another Time server, same result. Now i am at the End of my wisdom an need some idea's from others.
I'm working on STM32H753 (STM32H753I-EVAL2 board) using STM32CubeIDE and I'm trying to setup the ITM.
I've started by enabling SWV in the Debugger setting (of course I selected SWD) with Core Clock 400MHz (my CPU clock) and SWO clock 2MHz.
Then in my code I defined the following macro:
#define ITM_Port(n) (*((volatile unsigned long *)(0xE0000000 + 4*n)))
and call this macro as follows, at the location of my code where I want to get a timestamp.
ITM_Port(20) = 0x10;
Finally, in the debug session, I enable ITM stimulus port number 20 and Timerstamp, and launch the SWV Trace Log.
However I don't understand the output:
If I remove the calls to ITM_Port, the trace is empty...
I checked the registers ITM_TCR and ITM_TER and they look correct. Stimulus port 20 is indeed enabled in TER. In TCR, bits ITMENA, TSENA, SYNCENA and TXENA are set.
I looked at assembly level (that looks correct) and I noticed that the store instruction that is supposed to write 0x10 into ITM_STIM20 has no effect,the register is not modified. Is there something to unlock / enable ?
I also configured the GPIO PB3 with alternate function SWO.
Any idea ?
[...] I noticed that the store instruction that is supposed to write 0x10 into ITM_STIM20 has no effect, the register is not modified.
Please re-check the read/write semantics of this register in the
Reference Manual, page 3222:
Write data is output on the trace bus as a software event packet. When reading, bit 0 is a
FIFOREADY indicator:
0: Stimulus port buffer is full (or port is disabled)
1: Stimulus port can accept new write data
Therefore, I don't believe that there must be a mistake around this register.
The trace log screenshot in the question shows plenty of ITM trace packets at other ports (24, 25, 26, 28, 29, 30, 31).
Please take care not to overdo the ITM trace packet creation:
The question refers to SWV Trace Log, so the trace packets of different ITM ports must all pass through the same SWO line.
That interface is not very fast (while the CPU of STM32H7 certainly is!), so software-triggered ITM packet creation can easily choke this bottleneck so that packets are discarded.
The question doesn't contain the surrounding code where trace packets are created, but my guess is that during the analysis, inserting additional ITM packet triggers at a finer level (inside loops or so) increased the port traffic until lost packets weren't even noticeable.
The easiest way out may be to remove parts of the ITM triggers (or, to activate only few ITM channels at a time, which will filter packets in ITM before they are transmitted through SWO) and measure different aspects at a time, repeating the measurement with different ITM channel selection.
The second easiest way is to spend a few k$ on a debug adapter that supports the synchronous trace port. This feature is only supported by high-end adapter variants such as J-Trace, Lauterbach, etc. - it is usually targeted at ETM tracing, but you can also use the parallel TPIU interface to output ITM data, probably at a higher rate.
This strategy isn't the most elegant in the described situation - please consider the other way first!
I'm planning on making a clock. An actual clock, not something for Windows. However, I would like to be able to write most of the code now. I'll be using a PIC16F628A to drive the clock, and it has a timer I can access (actually, it has 3, in addition to the clock it has built in). Windows, however, does not appear to have this function. Which makes making a clock a bit hard, since I need to know how long it's been so I can update the current time. So I need to know how I can get a pulse (1Hz, 1KHz, doesn't really matter as long as I know how fast it is) in Windows.
There are many timer objects available in Windows. Probably the easiest to use for your purposes would be the Multimedia Timer, but that's been deprecated. It would still work, but Microsoft recommends using one of the new timer types.
I'd recommend using a threadpool timer if you know your application will be running under Windows Vista, Server 2008, or later. If you have to support Windows XP, use a Timer Queue timer.
There's a lot to those APIs, but general use is pretty simple. I showed how to use them (in C#) in my article Using the Windows Timer Queue API. The code is mostly API calls, so I figure you won't have trouble understanding and converting it.
The LARGE_INTEGER is just an 8-byte block of memory that's split into a high part and a low part. In assembly, you can define it as:
MyLargeInt equ $
MyLargeIntLow dd 0
MyLargeIntHigh dd 0
If you're looking to learn ASM, just do a Google search for [x86 assembly language tutorial]. That'll get you a whole lot of good information.
You could use a waitable timer object. Since Windows is not a real-time OS, you'll need to make sure you set the period long enough that you won't miss pulses. A tenth of a second should be safe most of the time.
Additional:
The const LARGE_INTEGER you need to pass to SetWaitableTimer is easy to implement in NASM, it's just an eight byte constant:
period: dq 100 ; 100ms = ten times a second
Pass the address of period as the second argument to SetWaitableTimer.
One of our legacy applications is producing resource leaks on 1 specific machine. Over time the overall processor usage increases until the application is closed and restarted.
Using perfmon I found a direct correlation between the process's handle count and the processor usage. This count went up into the thousands and I used SysInternal's handle to expose that all the extra handles (at least during the process running this afternoon when I ran handle) had a path of \Device\00000066.
I want to learn how to discover more information about exactly what device the device path is referring to so we know where to go from here. I have strong suspicions that the device is a PIN pad (used during debit transactions), but need proof.
Windows XP sp3.
Resolution
After Seva Titov's advice helped me identify it was a USB device, I had one main suspect: a cash drawer. We had the client unplug it and use it manually for a few hours: no constant increase in handles. I looked through that project's code and the developer neglected to close handles to the device after obtaining them. The rapid increase in handles was due to a timer that checked the drawer's status after it was opened to determine when the user had closed it.
Here is how you can get more information on the kernel directory object:
Install LiveKd, install Windows Debugging Tools
Launch LiveKd in the directory that contains kd.exe
Inside LiveKd prompt type this:
!object \device\00000066
Then use the value that it shows for the object (the first it prints) with !devobj command.
This is the example I did on my system -- I picked up a random device with name \device\0000006a as an example (just to confuse you :->)
0: kd> !object \device\0000006a
Object: fffffa8007959630 Type: (fffffa8006bce2d0) Device
ObjectHeader: fffffa8007959600 (new version)
HandleCount: 0 PointerCount: 6
Directory Object: fffff8a00000b8f0 Name: 0000006a
0: kd> !devobj fffffa8007959630
Device object (fffffa8007959630) is for:
0000006a \Driver\ACPI DriverObject fffffa8006b25d00
Current Irp 00000000 RefCount 1 Type 00000032 Flags 00003040
Dacl fffff9a100092d31 DevExt fffffa800792e7d0 DevObjExt fffffa8007959780 DevNode fffffa800796db10
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) fffffa800907d040 \Driver\i8042prt
Device queue is not busy.
The \driver should give you a hint on what the device is.
I've developed a Windows service which tracks business events. It uses the Windows clock to timestamp events. However, the underlying clock can drift quite dramatically (e.g. losing a few seconds per minute), particularly when the CPUs are working hard. Our servers use the Windows Time Service to stay in sync with domain controllers, which uses NTP under the hood, but the sync frequency is controlled by domain policy, and in any case even syncing every minute would still allow significant drift. Are there any techniques we can use to keep the clock more stable, other than using hardware clocks?
Clock ticks should be predictable, but on most PC hardware - because they're not designed for real-time systems - other I/O device interrupts have priority over the clock tick interrupt, and some drivers do extensive processing in the interrupt service routine rather than defer it to a deferred procedure call (DPC), which means the system may not be able to serve the clock tick interrupt until (sometimes) long after it was signalled.
Other factors include bus-mastering I/O controllers which steal many memory bus cycles from the CPU, causing it to be starved of memory bus bandwidth for significant periods.
As others have said, the clock-generation hardware may also vary its frequency as component values change with temperature.
Windows does allow the amount of ticks added to the real-time clock on every interrupt to be adjusted: see SetSystemTimeAdjustment. This would only work if you had a predictable clock skew, however. If the clock is only slightly off, the SNTP client ("Windows Time" service) will adjust this skew to make the clock tick slightly faster or slower to trend towards the correct time.
I don't know if this applies, but ...
There's an issue with Windows that if you change the timer resolution with timeBeginPeriod() a lot, the clock will drift.
Actually, there is a bug in Java's Thread wait() (and the os::sleep()) function's Windows implementation that causes this behaviour. It always sets the timer resolution to 1 ms before wait in order to be accurate (regardless of sleep length), and restores it immediately upon completion, unless any other threads are still sleeping. This set/reset will then confuse the Windows clock, which expects the windows time quantum to be fairly constant.
Sun has actually known about this since 2006, and hasn't fixed it, AFAICT!
We actually had the clock going twice as fast because of this! A simple Java program that sleeps 1 millisec in a loop shows this behaviour.
The solution is to set the time resolution yourself, to something low, and keep it there as long as possible. Use timeBeginPeriod() to control that. (We set it to 1 ms without any adverse effects.)
For those coding in Java, the easier way to fix this is by creating a thread that sleeps as long as the app lives.
Note that this will fix this issue on the machine globally, regardless of which application is the actual culprit.
You could run "w32tm /resync" in a scheduled task .bat file. This works on Windows Server 2003.
Other than resynching the clock more frequently, I don't think there is much you can do, other than to get a new motherboard, as your clock signal doesn't seem to be at the right frequency.
http://www.codinghorror.com/blog/2007/01/keeping-time-on-the-pc.html
PC clocks should typically be accurate to within a few seconds per day. If you're experiencing massive clock drift-- on the order of minutes per day-- the first thing to check is your source of AC power. I've personally observed systems with a UPS plugged into another UPS (this is a no-no, by the way) that gained minutes per day. Removing the unnecessary UPS from the chain fixed the time problem. I am no hardware engineer, but I'm guessing that some timing signal in the power is used by the real-time clock chip on the motherboard.
As already mentioned, Java programs can cause this issue.
Another solution that does not require code modification is adding the VM argument -XX:+ForceTimeHighResolution (found on the NTP support page).
9.2.3. Windows and Sun's Java Virtual Machine
Sun's Java Virtual Machine needs to be started with the >-XX:+ForceTimeHighResolution parameter to avoid losing interrupts.
See http://www.macromedia.com/support/coldfusion/ts/documents/createuuid_clock_speed.htm for more information.
From the referenced link (via the Wayback machine - original link is gone):
ColdFusion MX: CreateUUID Increases the Windows System Clock Speed
Calling the createUUID function multiple times under load in
Macromedia ColdFusion MX and higher can cause the Windows system clock
to accelerate. This is an issue with the Java Virtual Machine (JVM) in
which Thread.sleep calls less than 10 milliseconds (ms) causes the
Windows system clock to run faster. This behavior was originally filed
as Sun Java Bug 4500388
(developer.java.sun.com/developer/bugParade/bugs/4500388.html) and has
been confirmed for the 1.3.x and 1.4.x JVMs.
In ColdFusion MX, the createUUID function has an internal Thread.sleep
call of 1 millisecond. When createUUID is heavily utilized, the
Windows system clock will gain several seconds per minute. The rate of
acceleration is proportional to the number of createUUID calls and the
load on the ColdFusion MX server. Macromedia has observed this
behavior in ColdFusion MX and higher on Windows XP, 2000, and 2003
systems.
Increase the frequency of the re-sync.
If the syncs are with your own main server on your own network there's no reason not to sync every minute.
Sync more often. Look at the Registry entries for the W32Time service, especially "Period". "SpecialSkew" sounds like it would help you.
Clock drift may be a consequence of the temperature; maybe you could try to get temperature more constant - using better cooling perhaps? You're never going to loose drift totally, though.
Using an external clock (GPS receiver etc...), and a statistical method to relate CPU time to Absolute Time is what we use here to synch events in distributed systems.
Since it sounds like you have a big business:
Take an old laptop or something which isn't good for much, but seems to have a more or less reliable clock, and call it the Timekeeper. The Timekeeper's only job is to, once every (say) 2 minutes, send a message to the servers telling the time. Instead of using the Windows clock for their timestamps, the servers will put down the time from the Timekeeper's last signal, plus the elapsed time since the signal. Check the Timekeeper's clock by your wristwatch once or twice a week. This should suffice.
What servers are you running? In desktops the times I've come across this are with Spread Spectrum FSB enabled, causes some issues with the interrupt timing which is what makes that clock tick. May want to see if this is an option in BIOS on one of those servers and turn it off if enabled.
Another option you have is to edit the time polling interval and make it much shorter using the following registry key, most likely you'll have to add it (note this is a DWORD value and the value is in seconds, e.g. 600 for 10min):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval
Here's a full workup on it: KB816042
I once wrote a Delphi class to handle time resynchs. It is pasted below. Now that I see the "w32tm" command mentioned by Larry Silverman, I suspect I wasted my time.
unit TimeHandler;
interface
type
TTimeHandler = class
private
FServerName : widestring;
public
constructor Create(servername : widestring);
function RemoteSystemTime : TDateTime;
procedure SetLocalSystemTime(settotime : TDateTime);
end;
implementation
uses
Windows, SysUtils, Messages;
function NetRemoteTOD(ServerName :PWideChar; var buffer :pointer) : integer; stdcall; external 'netapi32.dll';
function NetApiBufferFree(buffer : Pointer) : integer; stdcall; external 'netapi32.dll';
type
//See MSDN documentation on the TIME_OF_DAY_INFO structure.
PTime_Of_Day_Info = ^TTime_Of_Day_Info;
TTime_Of_Day_Info = record
ElapsedDate : integer;
Milliseconds : integer;
Hours : integer;
Minutes : integer;
Seconds : integer;
HundredthsOfSeconds : integer;
TimeZone : LongInt;
TimeInterval : integer;
Day : integer;
Month : integer;
Year : integer;
DayOfWeek : integer;
end;
constructor TTimeHandler.Create(servername: widestring);
begin
inherited Create;
FServerName := servername;
end;
function TTimeHandler.RemoteSystemTime: TDateTime;
var
Buffer : pointer;
Rek : PTime_Of_Day_Info;
DateOnly, TimeOnly : TDateTime;
timezone : integer;
begin
//if the call is successful...
if 0 = NetRemoteTOD(PWideChar(FServerName),Buffer) then begin
//store the time of day info in our special buffer structure
Rek := PTime_Of_Day_Info(Buffer);
//windows time is in GMT, so we adjust for our current time zone
if Rek.TimeZone <> -1 then
timezone := Rek.TimeZone div 60
else
timezone := 0;
//decode the date from integers into TDateTimes
//assume zero milliseconds
try
DateOnly := EncodeDate(Rek.Year,Rek.Month,Rek.Day);
TimeOnly := EncodeTime(Rek.Hours,Rek.Minutes,Rek.Seconds,0);
except on e : exception do
raise Exception.Create(
'Date retrieved from server, but it was invalid!' +
#13#10 +
e.Message
);
end;
//translate the time into a TDateTime
//apply any time zone adjustment and return the result
Result := DateOnly + TimeOnly - (timezone / 24);
end //if call was successful
else begin
raise Exception.Create('Time retrieval failed from "'+FServerName+'"');
end;
//free the data structure we created
NetApiBufferFree(Buffer);
end;
procedure TTimeHandler.SetLocalSystemTime(settotime: TDateTime);
var
SystemTime : TSystemTime;
begin
DateTimeToSystemTime(settotime,SystemTime);
SetLocalTime(SystemTime);
//tell windows that the time changed
PostMessage(HWND_BROADCAST,WM_TIMECHANGE,0,0);
end;
end.
I believe Windows Time Service only implements SNTP, which is a simplified version of NTP. A full NTP implementation takes into account the stability of your clock in deciding how often to sync.
You can get the full NTP server for Windows here.