🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.comp.sys.amiga.tech
Article #3889

Re: HD Cache

#3889
From: Sven Tegethoff
Date: Fri, 01 Mar 1996 23:47
71 lines
3502 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 27.02.1996 um 18:22:04 Uhr folgendes unter dem Betreff "Re: HD Cache":

ME> >Sämtliche Programme, die einen möglichst grossen Zusammenhängenden
ME> >speicherblock benötigen, schauen in die Röhre,
ME>
ME> Nein. Warum sollten sie ?

Weil sie nicht rausfinden können, wieviel Speicher sie denn nun
haben dürfen. (Ausser, sie probieren einfach verschiedene Grössen
aus, oder überlassen die Grösseneingabe dem User, der daß auch
nicht weiss.) Falls doch, sag' mir wie.

ME> >weil man sich mit
ME> >dem dynamischen Cache ganz wunderbar den Speicher zerfräst,
ME>
ME> Das haengt einzig und allein von der Strategie des Caches ab.

Die brauchbarste Strategie dürfte im normalgebrauch LRU sein,
also alles andere als fragmentierungsfreundlich.

ME> >und
ME> >der noch nichtmal freigegeben wird.
ME>
ME> Warum sollte der nicht freigegeben werden ? Weil Du das nicht willst ?

Low-Memory Handler werden doch nur dann aufgerufen, wenn eine 
Speicheranforderung im ersten Versuch fehlschlägt, oder habe
ich da was falsch verstanden ?

ME> >Woher soll z.B. Audiomaster wissen, wieviel Speicher ich brauche, bevor
ME> >ich mit dem sampeln angefangen habe ?
ME>
ME> Du sagst es ihm oder er macht eine Abschaetzung und versucht einfach den
ME> Speicher anzufordern.

... und flusht beim ersten Fehlversuch den kompletten Cache, auch wenn er
nur ein zehntel der Cachegrösse als zusammenhängenden block bekommt.

ME> >Zu dumm, daß dank dem Cache MEMF_LARGEST nur 100 Kilobytes von 8MB sind...
ME>
ME> Warum sollte Audiomaster denn den groessten zusammenhaengenden Block anfordern ?
ME> Ich weiss, dass der das tut, aber das ist halt eine dumme Strategie.

Ich bin intensiver Benutzer von AdPro und Audiomaster.

Soll ich mir wegen einem neuen Cache etwa für 1000 Mark neue
Software anschaffen ?

ME> >Ganz davon abgesehen, daß ich jetzt auch mit dem AVAIL-Befehl nicht
ME> >mehr vernünftig abfragen kann, wieviel Speicher eigentlich _wirklich_
ME> >zur verfügung steht,
ME>
ME> Das konntest Du nie.

Man konnte es zumindest besser abschätzen, mit welcher Grösse man es
mal probieren kann... natürlich muss man _immer_ damit rechnen, daß
ein anderer Task den Speicher wegschnappt, das ist klar.

ME> >es sei denn ich schaue immer per Hand die aktuelle
ME> >cache-grösse nach, und ziehe sie vom belegten speicher ab.
ME>
ME> Ein "avail flush" wird wohl den gesamten Cache flushen.

Wozu ist ein Cache da, wenn er bei jeder furzigen Gelegenheit komplett
gelöscht werden muss ?

CIAO,                                                                ____/|
 ____ |____  ____  ____ |__   ____ |____  @ius.gun.de   | Radjah on  \ o.O|
(_____|    )(___/_(___/_|____(____||    ) @softgold.com | FurryMuck   =(_)=
                                                                        U
Waiting For you To speak I sit And shiver And wrap The night Around My Mind
Technical Details
Message-ID: <xN6ijMD4FEFagz5@chepoint.ius.gun.de>
Path: arc1-ca.pugleaf.net!ius.gun.de!CHEETAH
References: <xB+fiMD362aUz1@lcs.ndh.com> <4gvi4c$j8j@serpens.rhein.de>

Show Full Headers
Complete Article Headers
Newsgroups: de.comp.sys.amiga.tech
Message-ID: <xN6ijMD4FEFagz5@chepoint.ius.gun.de>
From: CHEETAH@IUS.gun.de (Sven Tegethoff)
Path: arc1-ca.pugleaf.net!ius.gun.de!CHEETAH
Organization: ReaLogic
Subject: Re: HD Cache
Date: Sat, 02 Mar 1996 00:47:15 +0100
X-Mailer: MicroDot 1.10 [REGISTERED 004fef]
References: <xB+fiMD362aUz1@lcs.ndh.com> <4gvi4c$j8j@serpens.rhein.de>
X-Gateway: ZCONNECT XX ius.gun.de [UNIX/Connect v0.73]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Z-Telefon: 02151-310992