"marfi" <marfi @bb.onet.pl> wrote in message
news:h2b5q6$m8$1@nemesis.news.neostrada.pl...
> Użytkownik "Pszemol" <Pszemol@PolBox.com> napisał w wiadomości
> news:h2ajcg.dj8.0@poczta.onet.pl...
>> "tg" <aa@bb.cpl> wrote in message
>> news:851c1$4a490c9d$59641b7f$13583@news.upc.ie...
>>> "lamer" <lamer@pl.pl> wrote in message
>>> news:h2arso$gtk$1@nemesis.news.neostrada.pl...
>>>> W sumie ciekawy pomysł. Dzięki, pobawię się. Na razie sprawdziłem, że
>>>> na normalnym dysku tworzenie nowego pliku 100 MB jest wykonywane z
>>>> prędkościa 6 MB/s, a na ram dysku 110 MB/s. Takiej prędkości to chyba
>>>> nic nieulotnego nie osiągnie.
>>>
>>> 6MB/s??
>>> wg benchmarkow samsung f1 1tb ma zapis rzedu 100MB/s dla probki 8MB
>>> u mnie z szyfrowaniem tc w tle sa to predkosci (zapis 700MB) rzedu
>>> 90MB/s
>>
>> W tym dysku terabajtowym to ty masz pewnie 8 mega lub więcej
>> samego cache... Czyli zapis pójdzie do cache i zgłosi gotowość,
>> a potem sobie będzie pisał spokojnie już na talerze ale z cache...
>>
>> Nie ma chyba sensu testować szybkości dysku na próbkach danych
>> mniejszych od wielkości jego wewnętrznej pamięci cache, no chyba
>> że testujesz przepustowość interface SATA II :-)
>
> 700MB jest mniejsze niż 8MB ???
Chodzi mi o rozmiar próbki ciągłych danych.
Niech to sobie będzie 700 mega, ale poszatkowane w 8MB, to kontroler
wyśle 8mega, poczeka na odpowiedź, pobierze znowu następne 8MB
a w między czasie dysk zapisuje na talerze...
Przy 8-megowym cache w dysku, minimalny kęs danych powinien
być większy niż te 8 mega przy testach, najlepiej 2-3 razy większy aby
nie było wątpliwości co do tego że dysk ma gdzie dane przechować
na czas przerw w wysyłce kolejnego kęsa danych.
Received on Mon Jun 29 22:40:04 2009
To archiwum zostało wygenerowane przez hypermail 2.1.8 : Mon 29 Jun 2009 - 22:51:06 MET DST