Sākumlapa › Forumi › Hardware › Pamatplates un CPU › dators raustās dažas sekundes un pāriet
Dators neko īpašu nedarot, noraustās dažas sekundes un tā diezgan bieži.
Raustīties mēdz pat tikai atskaņojot interneta radio, vai strādājot wordā. Skaņa paliek metāliska.
Sistēmas monitors parasti tad uzrāda procesora lecienu.
2. Problēma ko pamaniju strādājot ar PS, Photoshops tik lēni izpilda ne pārāk apjomīgus efektus ka liekas esmu atpakaļ 2004 gadā. Darot to pašu darbā uz intel Pentium G840 un tādu pašu ramu, nekas tāds nav manīts.
Procis arī tajos brīžos ir maksimāli noslogots.
Lietoju windows 8.1
CPU Core i5-4430 (3.0GHz, 6MB Cache, LGA1150)
Ram 8 gb
cietais disks sistēmai ssd 30 gb
otrs WD grean 1 tb
Page cache atslēgts
Atslēdzu jo SSD ir maziņš, bet w8 arī ir maziņš (sitēma aizņem labi ja 18 gb) Pārējās progas lieku uz otra cietā.
Starp citu – nereti visādus jokus taisa SATA štekeri, īpaši tie bez klipšiem – vari tos pārspraust.
Varbūt sāc ar cietā diska pārbaudīšanu, vēl var noklonēt sistēmu uz parastā, palaist no tā, brāķi gadās visiem.
1) Izskanēt parasto HDD ar hdtune, utml programmām – apskatīties SMART datus, bad blokus.
2) Apdeitot SSD disku (firmware update).
3) Uztaisīt benchmark testus SSD diskam un salīdzināt ar internetā atrodamajiem testiem.
Viņš elementāras lietas nejēdz, pamatus nezin, pac kauko instElē…
windows 8 versija ir 9431
un MD5: F104B78019E86E74B149AE5E510F7BE9
(MD5 ir 64bit Core/Pro versijai).
Vienam samērā jaunam datoram pagājušogad sakomplektētam bija līdzīgi, bij uzlikts Windows7, tas šādi darījās, pārejot uz Windows 8 problēma vairs nebij. Takā cilvēkam galvenais lai dators strādā bez problēmām, palika viņš uz Windows 8, un Windows 7 tā arī vairs necentāmies piemocīt viņam klāt… 🙂
Uz Windows 2000 – Windows 7 ir programma DPC (Deferred Procedure Calls) Latency Checker
Atvaino, bet šeit būs apraksts angliski:
Processing of streaming data in real-time is a very challenging task for Windows based applications and device drivers. This is because by design Windows is not a real-time operating system. There is no guarantee that certain (periodic) actions can be executed in a timely manner.
Audio or video data streams transferred from or to an external device are typically handled by a kernel-mode device driver. Data processing in such device drivers is interrupt-driven. Typically, the external hardware periodically issues interrupts to request the driver to transfer the next block of data. In Windows NT based systems (Windows 2000 and better) there is a specific interrupt handling mechanism. A device driver cannot process data immediately in its interrupt routine. It has to schedule a Deferred Procedure Call (DPC), which is basically is a call-back routine that will be called by the operating system as soon as possible. Any data transfer performed by the device driver takes place in the context of this callback routine, named DPC for short.
The operating system maintains DPCs scheduled by device drivers in a queue. There is one DPC queue per CPU available in the system. At certain points the kernel checks the DPC queue and if no interrupt is to be processed and no DPC is currently running the first DPC will be un-queued and executed. DPC queue processing happens before the dispatcher selects a thread and assigns the CPU to it. So, a Deferred Procedure Call has a higher priority than any thread in the system.
Note that the Deferred Procedure Call concept exists in kernel mode only. Any user-mode code (Windows applications) runs in the context of a thread. Threads are managed and scheduled for execution by the dispatcher.
While there is a pre-emptive multitasking for threads, DPCs are executed sequentially according to the first in, first out nature of a DPC queue. Thus, a sort of cooperative multitasking scheme exists for Deferred Procedure Calls. If any DPC runs for an excessive amount of time then other DPCs will be delayed by that amount of time. Consequently, the latency of a particular DPC is defined as the sum of the execution time of all DPCs queued in front of that DPC. In order to achieve reasonable DPC latencies, in the Windows Device Driver Kit (DDK) documentation Microsoft recommends returning from a DPC routine as quickly as possible. Any lengthy operation, specifically loops, that wait for a hardware state change (polling) are strongly discouraged.
Unfortunately, many existing device drivers do not conform to this advice. Such drivers spend an excessive amount of time in their DPC routines, causing an exceptional large latency for any other driver’s DPCs. For a device driver that handles data streams in real-time it is crucial that a DPC scheduled from its interrupt routine is executed before the hardware issues the next interrupt. If the DPC is delayed and runs after the next interrupt occurred, typically a hardware buffer overrun occurs and the flow of data is interrupted. A drop-out occurs.
Pašam arī bija šāda problēma, ka uz mazāk par sekundi viss uzkārās un bija nepatīkama skaņa.
Manā gadījumā izrādījās, ka problēmas taisīja Ethernet draiveris. Uzliku pašu jaunāko draiveri un problēmas vairs nav bijušas.
Tad nu, kā tās programmas lapā ir ieteikts, iekš Device Manager atslēdz pa vienam kādu ierīci.
Ierīces, kuras vajadzētu mēģināt atslēgt pa vienai un izmēģināt, vai problēma ir atrisināta:
* Network adapters for Ethernet and Wireless LAN (W-LAN)
* Internal modems
* Internal sound devices (on-board sound systems)
* Any PCI or PCI Express add-on card, any PCCard or ExpressCard, e.g. TV tuner cards, ISDN or DSL adapters, modems, etc.
Ierīces, kuras neatslēgt
* any device listed in Device Manager under System devices or Computer,
* the hard disk that contains the system partition,
* the IDE/ATAPI or SATA controller this hard disk is connected to,
* the system keyboard,
* the mouse, track point or touch pad device,
* the USB controller external keyboard and/or mouse devices are connected to,
* the display controller listed under Display adapters.
Iesaku izlasīt norādītās programmas lapā visu info.
1. Parbaudīt vai SafeMode met tādus pašus gļukus.
Preses relīzes