Komentarze
Komentarzy na stronę
1
MAR89TUM (2013.08.21, 15:31)
Ocena: 19
#3

0%
PClabowy test był robiony na WIN 7 ULTIMATE 64 bit więc głowa spokojna bo końca świata nie ma.
Kiciuk (2013.08.21, 15:32)
Ocena: 3
#4

0%
@tomandr
przecież i tak podkręcalne jest jedynie pare układów BLCK to nie kręcenie ;)
Edytowane przez autora (2013.08.21, 15:33)
misiu9091909 (2013.08.21, 15:39)
Ocena: 3
#5

0%
tomandr @ 2013.08.21 15:21  Post: 680306
Najprościej byłoby zablokować podkręcanie procesorów z poziomu Windows. I problem rozwiązany. Ludzie którzy chcą mieć podkręcony procesor i tak robią to z poziomu BIOS a nie przez aplikacje okienkowe. A wtedy problem nie występuje bo dotyczy on tylko osób podkręcających procesor aplikacjami.

Dlaczego by tak? Mam Phenoma 955, wprawdzie nie jestem zapalonym overclockerem, ale czasami zmieniam częstotliwość zegara i wygodnie jest to mieć pod ręką, a nie specjalnie resetować kompa.
Tak, wiem, to dotyczy inteli, ale domyślam się, że z inteli również korzystają osoby, które sobie czasem podkręcają i nie chce im się co chwilę wyłączać komputera.
Edytowane przez autora (2013.08.21, 15:39)
focus (2013.08.21, 15:40)
#6

0%
Trepcia @ 2013.08.21 15:23  Post: 680307
Czyli co? Wyniki na procesorach Intela sa zawyzone i bedziecie musieli od nowa przeprowadzic testy 200 procesorow? Koniec swiata jest bliski jednak... :-)

Trolujesz dla samego trolowania? Po pierwsze: testowaliśmy na Windows 7. Po drugie: nie podkręcamy z poziomu systemu Windows.
fevi (2013.08.21, 15:47)
Ocena: 8
#7

0%
Jak zwykle jakiś cyrk z Windnowsem 8
ghs (2013.08.21, 16:07)
Ocena: 0
#11

0%
Microsoftowi należy zaliczyć ogromne osiągnięcie in plus. Sprowadził większość meneli i gimbazy spod budek z piwem przed klawiatury i monitory. Dzięki M$ ulice mamy bezpieczniejsze
Relativy (2013.08.21, 16:27)
Ocena: 4
#12

0%
Cała zagadka byłaby rozwiązana gdyby podali na jakich mobo kręcili
Bo windows8 bierze częstotliwość z zegara bazowego i teraz pytanie którego?
Odpowiedź raczej oczywista: z PCI-E która taktuje wszystko. W przypadku AMD
AM3 mamby BUS niezależny od PCI-E, w przypadku FM2 też są odpowiednie mnożniki
i pci-e zostaje praktycznie nieruszone. W Sandy/ivy/haswell ruszając BLCK ruszamy PCI-E bo są ze sobą nieodwracalnie sprzężone, w HSW mamy też mnożniki ale puki go nie przestawimy pci-e lata razem z BLCK. Zagadką zostaje platforma 775. O ile na P35 i P45 PCI-E jest niezależne od FSB o tyle na wszystkich pozostałych chipsetach przy FSB powyżej 333 pci-e leci za szyną i mamy nasz problem. To wydaje się być najprostrzym rozwiązaniem, ale mogę się mylić, wszystko zależy jakiego mobo na s775 użyto.
Czabor (2013.08.21, 21:13)
Ocena: -4
#14

0%
To sa wlasnie Benchmarki.20 % zawyzona wydajnosc nowych atmow,znikajce smoki,biosy
pokazujace 100 mhz zamiast rzeczywistych 102 mhz.I czy to win 7 czy 8 to bez roznicy.
Bardzo dobrze ze wkoncu ten smrodek ujrzal swiatlo dzienne.Na 7/XP smrodek mozna bylo ukryc na poziomie biosu.
Edytowane przez autora (2013.08.21, 21:13)
Stanley (2013.08.22, 08:51)
Ocena: 1
#15

0%
Temat RTC oraz RDTSC jest obszerny, próbowałem wczoraj znaleźć odpowiedź ale zaspamował bym komentarze(co pewno zrobie) a sam nie do końca wszystko rozumiem. Na konkurencyjnym portalu jest bardzo sensowna teoria zapisana w formie stwierdzenia - bez podania źródła która mysle wkrótce sie potwierdzi. Otóż - przyczyna rozbieżności wynika ze zmian w windows 8 w kierunku uniezależnienia od RTC którego to nie ma na wszystkich maszynach np. tablety laptopy ARM - możliwe że zrobiono to po uśmierceniu WinCE by ujednolicić prace nad kernelami Windows Phone, Windows RT, i desktopowy 8 (w którym na 100% jest zegareczek i bateryjka)
ale sprawa by przeszła gdyby nie specyfika procesorów intela o czym pobieżnie można przeczytać tu: http://en.wikipedia.org/wiki/Time_Stamp_Counter
(jest lekka różnica amd i intel w podejsciu do rdtsc które jest dość złożonym zagadnieniem w praktyce.. być może to ma wpływ)
być może ma to wpływ na funkcje kernela podobne do http://msdn.microsoft.com/en-us/library/wi...8(v=vs.85).aspx
które sa oparciem dla innych funkcji bibliotecznych jak np. z biblioteki standardowej C - time(każda wywołuje te czy inne funkcje kernela to oczywiste - musi to na tym polega kernel) tym samym na funkcje używane przez benchmarki, przeliczenie czasu przez system być może jest oparte na czymś w tym stylu:

static unsigned __int32 rdtsc_b;
unsigned __int32 __stdcall C_Start()
{
__asm {rdtsc }
}
unsigned __int32 __stdcall C_End(unsigned __int32 b)
{
__asm {rdtsc }
__asm { mov EBX,b}
__asm { sub EAX,EBX }
__asm { sub EAX,0x0E }
}
a później liczba cykli procesora przeliczona po podzieleniu, pomnożeniu i iinnych przeliczeniach przez podstawe która zamiast ilości cykli procesora zwraca ilość czasu w ms, być może wcześniej Windows przeliczał te wartości na podstawie obsługi cyklicznego przerwania od RTC i systematycznie korygował, może wymyślono inne metody, może procesor intela zwraca wówczas niewłaściwe liczby albo, a być może to obiczenie jest oparte o jakiś parametr który sie źle skaluje po podkreceniu(jakieś inne stałe przerwanie?) co nie zmienia faktu że sprawa sie rypła, a wedle tej teori przez zmiany w Windows 8, bo w każdym PC jest podtrzymywany bateryjnie RTC wywołujacy przerwanie które można obsłużyć albo olać http://www.compuphase.com/int70.txt
Wczoraj przyszło mi to do głowy bo miałem kiedyś NAS Edmini marki LaCie, na pokładzie linux jak we wszystkich ale płyta pozbawiona zegara RTC, dlatego za każdym razem po uruchomieniu synchronizował czas z serwerem NTP w przeciwnym wypadku funkcja time() zwracała 1970r(unixowa podstawa obliczeń) i z takim czasem ustawiał daty plików. Synchronizował to źle napisane - próbował to robić bezskutecznie i to chyba był jedyny powód jego sprzedaży.
Natomiast w logach uruchomienia widać było że kernel symulował obecność RTC w usłudze w razie gdyby jakiś program próbował pobierać informacje o czasie z niego. Być może Windows 8 również wyposażono w taki 'symulator' można nawet bardziej - całkowicie wyeliminowano obsługe RTC poza sytuacjiami np. wybudzania z hibernacji itp.

Tak na marginesie unixowa podstawa napotka problem 'milenijny' w 2038r (liczba milisekund od 1970r przekroczy 2^32) a na jeszcze innym marginesie Windows obsługuje troche inny format czasu np. dla plików http://msdn.microsoft.com/en-us/library/wi...4(v=vs.85).aspx bardziej precyzyjny który za 0 przyjeto 1601r a rozdzielczość wynosi 100nanosekund i jest zapisany w 64bitach co powinno doprowadzić do przepełnienia w 30828r a jak widać doprowadziło do problemu już dziś w Windows 8

W każdym razie sprawa jest ciekawa, nie jestem inżynierem informatyki i sie nie znam, jest przecież tylu speców branży wyjaśnienie powino być błyskawicznie :P
Edytowane przez autora (2013.08.22, 09:12)
Zaloguj się, by móc komentować
Aktualności
Ostatnie podwyżki w Polsce to mógł być tylko początek. 112
Sytuacja jednak powoli się stabilizuje. IDC opublikowało właśnie kolejny raport dotyczący rynku PC. 31
W przypadku polskiej dystrybucji trzeba dopłacić kilkaset złotych. 42
Informacji na temat urządzeń udzielił DJ Koh, szef działu urządzeń przenośnych. 8
Ogrzewanie wody w kranach i basenach to następny krok. 22
Poprawa sytuacji dopiero na wiosnę, być może. 85
Producent obudów mógł zrobić tylko jedno. 27
Świetna wiadomość dla fanów konsol retro. Hyperkin, firma odpowiedzialna za m.in. 8
Pięć nowych modeli. Targi CES 2018 obfitowały w premiery sprzętu. 1
Poprawa sytuacji dopiero na wiosnę, być może. 85
Ogrzewanie wody w kranach i basenach to następny krok. 22
Może da się nie oślepnąć. 35
Producent obudów mógł zrobić tylko jedno. 27
Podczas trwających właśnie w Las Vegas targów CES Mercedes zaprezentował zupełnie nowy kokpit swoich samochodów, kontrolowany przez nowy interfejs MBUX (Mercedes-Benz User Experience). 26
Ostatnie podwyżki w Polsce to mógł być tylko początek. 112
Facebook
Ostatnio komentowane