Autor: Krzysztof Pralat (qservice_at_sylaba.poznan.pl)
Data: Sun 05 Apr 1998 - 17:53:35 MET DST
[ciach]
>Jeszcze nie jestem przekonany czy się mylę, napisz co może być nie tak z
>płytą...
Jej wadliwa praca (patrz wypowiedz ponizej).
>No dobra, to teraz ze strony teoretycznej, dlaczego ma nie zwolnić, skoro
>dostęp do DIMM jest wolniejszy niż do cache?
Ktos na tej liscie zasugerowal jakoby W95 ladowal sie w przypadku 128MB
ramu, poczynajac od obszaru niecacheowanego przez TX. Nie jestem
specjailsta od W95, ale kloci sie to z moja skromna wiedza.
Bez watpienia dostep procesora do danych zawartych w pamieci cache (L2, na
plycie) jest znacznie krotszy niz do pamieci operacyjnej. Jak wiadomo
chipset TX cacheuje obszar pamieci operacyjnej do 64MB. Moim zdaniem tam
wlasnie znajduja sie pliki systemowe i biblioteki. Poza nimi znajdzie sie
tam rowniez miejsce dla innych programow :). Dlatego dolozenie kolejnych
64MB do istniejacych w systemie nie spowoduje jego spowolnienia (pliki
systemowe caly czas znajduja sie w obszarze cacheowalnym). Natomiast dostep
do danych zawartych w obszarze niecacheowanym bedzie dluzszy, ale i tak o
niebo krotszy niz ich pobieranie z dysku twardego. Dlatego nie nalezy sie
bac "ograniczenia" chipsetu TX.
>Mam tak, że jak nie obrabiam plików dużych takich, że przy 64Mb korzystają z
>cache dyskowego, to trwa to dłużej przy 128 Mb na płycie Shuttle TX
O Shuttle nie bede sie wypowiadal w mysl zasady: o zmarlych mowi sie dobrze
albo wcale. Nacialem sie na tych plytach jeszcze w okresie 486 i prosze
mnie do nich nie przekonywac bo nie bede polemizowal z zadnymi argumentami.
Nie jestem fanem Asusa ;), ale na tej plycie takie zjawiska nie wystepuja.
>Jaka jest Twoja konfiguracja, gdzie nie widzisz różnic?
Cala konfiguracja: Asus TX97, 512kB L2 cache, chwilowo 3x32MB DIMM 10ns
LGS, iP 200 noMMX (3x75), STB LightSpeed (ET6000), Quantum ST 2GB, Seagate
1,3GB, Caviar 0,7GB, IOmega ZIP, CD-ROM LiteOn 16x, Diamond Monster 3D, SB
AWE64, Zoom 34i, ethernet OvisLink 8029R.
Systemy: W95osr2, WNT4, RedHat5.
Krzychu
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 17:09:14 MET DST