I am using Windows XP Embedded on my machine, which is installed from a backup image.
Recently, I have detected a system clock drift on my machine. This drift is very large (one second at every 5 minutes).
This drift is not permanent, it randomly happened at every bootup.
But if the unit boots up with a drift, it will stay until the next bootup.
Another important thing is that at the bootup the unit starts with 0 delay every time, for example:
booting up the unit.
world time is 12:00:00.00, unit time is 12:00:00.00.
wait for 10 minutes.
world time is 12:10:00.00, unit time is 12:09:58.00.
turn off the unit
booting up the unit.
world time is 12:15:00.00, unit time is 12:15:00.00.
The clock cannot be synchronized.
I installed regular XP ( not embedded) and the drift did not appear.
Can someone give me any help on how to find the root cause of the problem and how to solve it at the Embedded XP?
Many systems will synchronize the operating system's clock to the system hardware clock at bootup, and then maintain the system time purely in software thereafter. It looks like what's happening is that Windows Embedded is doing that, but the software clock is drifting -- whereas Windows XP is regularly synchronizing the software clock to the hardware clock.
Even if you can't use time synchronization to an external time server, there should still be a way to get Windows Embedded to use the hardware clock.
Related
Unity takes a very long time to launch. It literally takes too long. My laptop's specs are far beyond the recommended specs. It takes more than 6 minutes to run. I installed it on the c drive, and the capacity is about 50GB, so it is sufficient.
I tried securing enough space and closing other programs, but nothing changed.
my system since last couple of days is behaving strangely. I am a regular user of pycharm software, and it used to work on my system very smoothly with no hiccups at all. But since last couple of days, whenever I start pycharm, my CPU utilization behaves strangly, like in the image: Unusual CPU util
I am confused as when I go to processes or try ps/top in terminal, there are no process which is utilizing cpu more then 1 or 2%. So I am not sure where these resources are getting consumed.
By unusual CPU util I mean, That first CPU1 is getting used 100% for couple or so minutes, then CPU2. Which is, only one cpu's utilization goes to 100% for sometime followed by other's. This goes on for 10 to 20 minutes. then system comes back to normal.
P.S.: I don't think this problem is related to pycharm, as I face similar issues while doing other work also, just that I always face this with pycharm for sure.
POSSIBLE CAUSE: I suspect you have a thrashing problem. The CPU usage of your applications are low because none of them are actually getting much useful work done. All the processing is being taken up by moving memory pages to and from the disk. Your CPU usage probably settles down after a time because your application has entered a state where its memory working set has shrunk to a point where it all can be held in memory at one time.
This has probably happened because one of the apps on your machine is handling a larger data set than before, and so requires more addressable memory. Another possibility is that, for some reason, a lot more apps are running on your machine.
POTENTIAL SOLUTION: There are several ways you can address this. The simplest is to put more RAM on your machine. If this doesn't work or isn't possible, you'll have to figure out which app is the memory hog. You may simply have to work with smaller problems/data-sets or offload some of the apps onto a different box.
MIGRATING CPU LOAD: Operating systems will move tasks (user apps, kernel) around for many different reasons. The reasons can range anywhere from it being just plain random to certain apps having more of their addressable memory in one bank vs another. Given that you are probably doing a lot of thrashing, I'm not surprised that the processor your app is running is randomized over time.
I was just wondering whether the switch between the kernel mode and the user mode in an operating system is done by the hardware or the os itself.
I understand that when a user process wants to get into kernel mode it can make a system call and execute some kernel code. When the system call is made, the process goes into the kernel mode and now all memory becomes accessible, etc. In order for this to happen, I would assume that the interrupt handler needs to switch or alter the page table. Is this true? If not, how does the CPU know, that it is running in the kernel mode and does not need to page fault when accessing restricted (unaccessible to the user process) memory?
Thanks!
The last answer is actually not true....
Changing to kernel mode doesn't go through 'Real mode'. Actually after finishing the boot process, the computer never goes back to real mode.
In normal x86 systems, changing to kernel mode involves calling 'sysenter' (after setting parameters in some registers), which causes jumping a predefined address (saved in the MISR register of the CPU), that was set when the computer booted, because it can be done only from kernel mode (it is a 'privileged' command).
So it basically involves executing a software command, that the hardware responds to, by the way it was set, when it was in kernel mode
This is kind of a broad question - each hardware platform is going to do things slightly differently, but I think the basic answer is that it's done w/ software that leverages hardware facilities for memory protection, etc.
When a user process wants to do a system call, it executes a special CPU instruction, and the CPU switches from virtual mode (for user processes, has page tables specific to processes) to real mode (for the kernel) and jumps to the OS syscall handler. The kernel can then do what it likes.
CPU support for this is required. The CPU keeps track of which mode it is in, where the page tables are located, jumping the instruction pointer, etc. It is triggered by the user software doing the syscall, and is dependent on the kernel providing support for whatever it is trying to do. As with all computation, it's always both hardware and software. I cannot be done solely with software however, because then there would be no way to prevent a process making a syscall from abusing the privelages it gains, e.g. it could start reading /etc/shadow.
Modern x86 computers have a special instruction just for doing system calls. Earlier x86 processors, and some current RISC ones, have an instruction to trigger an interrupt. Older architecures had other ways of switching control.
Does a multitasking system involve a mouse cursor to make the user able to interact with more than one task/process at a time?
You don't need a mouse to have a multitasking system. The Wikipedia article on multitasking has some history of multitasking systems; they're a lot older than window environments and mice. The first multitasking systems ran batch jobs: you submit a task (by loading up a deck of punched cards, for example) and wait for it to finish; there could be multiple tasks in progress at any given time.
Later systems had user interaction through a command line; for example, in a purely textual unix user interface, you can use job control to run commands in the background, and control which program you get to interact with.
Even in a typical window environment, the application that has the focus (i.e. the application that you type into) isn't the only one that can get CPU time. A window environment on a multitasking operating system lets you switch to another window while an application is computing something. Additionally pretty much any multitasking system has a bunch of tasks ready in the background, only running when some event happens (hardware event, packet received over the network, timer, …). So even when there are windows and a mouse, there's no particular relationship between them and multitasking.
There's nothing about a multi-tasking system that requires any kind of involvement by the user.
To tackle the banal answer, my system, which is a Windows 7 64-bit system, could start up Notepad and seem to be single-process only in the sense that I'm only running one program, but obviously that's far from the truth.
In the other end of the scale you could have a system where the concept of a mouse cursor wouldn't make sense at all, let alone a display. For instance, a mainframe would fit this end of the scale, where the system doesn't really have a user-interface or a mouse, but is still very much so a multi-user and thus a multi-process system.
I guess my answer is more like this: What is actually your question?
I am working on a Windows game and while rendering, some computers will experience intermittent pauses ("hitches" for lack of a better term). When profiled they appear in seemingly random places in the code. Eventually I noticed that it wasn't just my process that was affected, but (seemingly) every process on the system. All of the threads in my application hitch at once. The CPU utilization drops during these hitches and it appears as if most processes make no progress.
This leads me to believe this may be an Operating System or Driver issue, but it only occurs while playing the game (and only on some systems). What sort of operations might the operating system be doing that would require the kernel to pause all user threads and block. Some kind of I/O? At first I thought of paging but my impression is that would only affect a single process, no?
Some systems in use: Windows, DirectX (3d), nVidia cards (unknown if replicates on ATI), using overlapped io for streaming
If you have a lot of graphics in use, it may be paging graphics memory into the swap file.
Or perhaps the stream is getting buffered on disk?
It's worth seeing if the hitches coincide with the PC's disk activity LED.
Heavy use of memory mapped IO. This of course includes the system pagefile, but can also include user applications that use mmio heavily (gcc for one)