Thread View: de.comp.sys.amiga.tech
24 messages
24 total messages
Started by Thomas Schuerger
Thu, 25 Jan 1996 19:28
HD Cache
Author: Thomas Schuerger
Date: Thu, 25 Jan 1996 19:28
Date: Thu, 25 Jan 1996 19:28
36 lines
1776 bytes
1776 bytes
Hi!
Ich bin auf der Suche nach einem wirklich guten HD/Floppy-Cache.
Folgende Features sollte er haben:
- möglichst dynamisch
- möglichst mit Read-Ahead
- Write-Behind Option
- LRU
- verschiedene Devices über gleichen Cache
- 030er Version
Es gibt da ja Dynami-Cache. Das Programm wird aber AFAIK seit langem
nicht mehr weiterentwickelt und unterstützt nicht Write-Behind. Außerdem
weiß ich da nichts über die Geschwindigkeit.
Außerdem kenne ich noch FastCache (unterstützt nicht verschiedene
Devices und Read-Ahead) und PowerCache (Demoversion) ein wenig.
Was ist zu empfehlen? Was liegt in dieser Hinsicht vernünftiges auf
dem Aminet?
PD/Shareware/Löhnware?
___
Ciao, LCS / / _______
/ /_/ ____/
Thomas Schuerger E-Mail: T.Schuerger@lcs.ndh.com \___ __/
or: Phobos@eratosth.dssd.sub.org \_/ PGP
CoSysOp of Eratosthenes BBS: (+49) 0228/230083 V.FC & 239522 V.34/ISDN
=======================================================================
Note my new e-mail address!
Bus Error! Passengers dumped.
Re: HD Cache
Author: Jens-Olaf Brand
Date: Sat, 27 Jan 1996 13:00
Date: Sat, 27 Jan 1996 13:00
41 lines
2307 bytes
2307 bytes
T.Schuerger@lcs.ndh.com (Thomas Schuerger) benutze seine Tastatur am 25.01.1996 um 20:28:18 Uhr, um
folgenden Text unter dem Betreff "HD Cache" zu erzeugen:
> Hi!
>
> Ich bin auf der Suche nach einem wirklich guten HD/Floppy-Cache.
> Folgende Features sollte er haben:
>
> - möglichst dynamisch
> - möglichst mit Read-Ahead
> - Write-Behind Option
> - LRU
> - verschiedene Devices über gleichen Cache
> - 030er Version
Nimm PowerCache! Wenn du mit den verschiedenen Devices meinst,
zum Beispiel DF0: und ds0: den gleichen Cachespeicher zur Ver-
fügung zu stellen, dann geht das leider nicht, aber sonst er-
füllt er alle von dir geforderten Kriterien. Außerdem verfügt
er noch über nen Low-Memory-Handler. Das Teil ist Shareware,
die Demoversion ist auf eine halbe Std. Laufzeit begrenzt und
muß dann nochmal gestartet werden.
> ___
> Ciao, LCS / / _______
> / /_/ ____/
> Thomas Schuerger E-Mail: T.Schuerger@lcs.ndh.com \___ __/
> or: Phobos@eratosth.dssd.sub.org \_/ PGP
>
> CoSysOp of Eratosthenes BBS: (+49) 0228/230083 V.FC & 239522 V.34/ISDN
> =======================================================================
> Note my new e-mail address!
>
> Bus Error! Passengers dumped.
Bis dann,
Brandy
__
///
__ /// E-Mail:
\\\/// BRANDY@PINK.anubis.sub.de
\XX/ BRANDY@WB08.Lummerland.WaD.org
Re: HD Cache
Author: Alexander Abt
Date: Thu, 01 Feb 1996 20:33
Date: Thu, 01 Feb 1996 20:33
19 lines
1116 bytes
1116 bytes
Florian Lohoff wrote in de.comp.sys.amiga.tech about "Re: HD Cache":
> : erm, und was macht man wenn man einen oktagon hat ?
>
> Powercache nehmen ?
Powercache hat auf nem Oktagon etwa den Effekt, den Softram (Placebo Forte
aus der c't) auf ner DOSe hat. Ich hab nen ALF3 und bisher hab ich
Dynamicache und Powercache getestet, Ergebnis : Die Programme laufen zwar,
aber cachen tun die gar nix.
Ciao
Alex [Team ALWAYS/ULTRA]
640x480x256 color resolution or better,3+MB or Ram
(CD System requirements)
Re: HD Cache
Author: Matthias Scheler
Date: Fri, 09 Feb 1996 21:03
Date: Fri, 09 Feb 1996 21:03
13 lines
907 bytes
907 bytes
Im Artikel <c87_9602062000@big-biz.gun.de> schrieb Matthis
<Matthis@2433-740-6.big-biz.gun.de>:
> Wo ist das Problem. Einfach auf dem Web-Server suchen lassen ... oder
> auf den CDs die Suchroutine starten ...
Oder die Suchfunktion von ADT(*) bzw. AmFTP benutzen.
(*) Vorher mit "O)ptions" "S)earch" auf Netzwerksuche umstellen und einen
netznahen Such-Server anwaehlen.
--
Matthias Scheler
tron@lyssa.owl.de
Re: HD Cache
Author: Fionn Behrens
Date: Sat, 10 Feb 1996 17:37
Date: Sat, 10 Feb 1996 17:37
18 lines
1542 bytes
1542 bytes
Aaron Digulla schrieb in <69359470@home.lake.de> über "Re: HD Cache":
> Das stimmt so nicht. DynamiCache verwendet da ein viel besseres System als
> PowerCache. DC hat eine eigene AllocMem()/AvailMem()-Funktion, so dass der
Es ist doch eine Frage, ob man einen SetFunction()-Hack als besser bezeichnen
kann, wenn dafuer Betriebssystem-Routinen, die ungefaehr dieselbe
Funktionalitaet bieten aussen vor gelassen werden.
Gruss,
Fionn
--
fionn@informatik.uni-siegen.de IRC: Fionn@#amigager
PGP Key available on request
-====### legal notice ###====------------------------------------------------
Microsoft Network is prohibited from redistributing this work in any form, in
whole or in part. License to distribute this post is available to Microsoft
for $499. Posting without permission constitutes an agreement to these terms.
Re: HD Cache
Author: Marco Krause
Date: Sun, 11 Feb 1996 17:25
Date: Sun, 11 Feb 1996 17:25
13 lines
1145 bytes
1145 bytes
fionn@informatik.uni-siegen.de (Fionn Behrens) schrieb am 10.02.1996: > Es ist doch eine Frage, ob man einen SetFunction()-Hack als besser bezeichnen > kann, wenn dafuer Betriebssystem-Routinen, die ungefaehr dieselbe > Funktionalitaet bieten aussen vor gelassen werden. Das stimmt so nicht. DynamiCache leitet einen Aufruf von AllocMem() und AvailMem() an die Original-Routinen weiter! -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Fionn Behrens
Date: Wed, 14 Feb 1996 22:19
Date: Wed, 14 Feb 1996 22:19
27 lines
1954 bytes
1954 bytes
Marco Krause schrieb in <xHkKOMD4E25anz7@marco.cosmos-l.gun.de> über "Re: HD
Cache":
> fionn@informatik.uni-siegen.de (Fionn Behrens) schrieb am 10.02.1996:
>
> > Es ist doch eine Frage, ob man einen SetFunction()-Hack als besser
> > bezeichnen kann, wenn dafuer Betriebssystem-Routinen, die ungefaehr
> > dieselbe Funktionalitaet bieten aussen vor gelassen werden.
>
> Das stimmt so nicht. DynamiCache leitet einen Aufruf von AllocMem() und
> AvailMem() an die Original-Routinen weiter!
Ja und? Das tun mindestens die Haelfte alles SetFunction()-Hacks. Davon
werden sie kein Stueck besser. Fakt bleibt, dass Avail/AllocMem() sich
hinterher anders verhalten als vorher (sons waere der Patch ja nicht da),
wass immer zu Problemem fuehren kann.
Gruss,
Fionn
--
fionn@informatik.uni-siegen.de IRC: Fionn@#amigager
PGP Key available on request
-====### legal notice ###====------------------------------------------------
Microsoft Network is prohibited from redistributing this work in any form, in
whole or in part. License to distribute this post is available to Microsoft
for $499. Posting without permission constitutes an agreement to these terms.
Re: HD Cache
Author: Marco Krause
Date: Thu, 15 Feb 1996 18:59
Date: Thu, 15 Feb 1996 18:59
12 lines
1055 bytes
1055 bytes
fionn@informatik.uni-siegen.de (Fionn Behrens) schrieb am 14.02.1996: > Ja und? Das tun mindestens die Haelfte alles SetFunction()-Hacks. Davon > werden sie kein Stueck besser. [...] Es wäre auch nicht gerade systemkonform, wenn die Memory-Funktionen des OS durch eigene vollkommen ersetzt werden. -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Fionn Behrens
Date: Wed, 21 Feb 1996 22:01
Date: Wed, 21 Feb 1996 22:01
27 lines
2013 bytes
2013 bytes
Marco Krause schrieb in <xI568MD4E25anz7@marco.cosmos-l.gun.de> über "Re: HD
Cache":
> fionn@informatik.uni-siegen.de (Fionn Behrens) schrieb am 14.02.1996:
>
> > Ja und? Das tun mindestens die Haelfte alles SetFunction()-Hacks. Davon
> > werden sie kein Stueck besser. [...]
>
> Es wäre auch nicht gerade systemkonform, wenn die Memory-Funktionen des OS
> durch eigene vollkommen ersetzt werden.
Du postest offensichtlich ohne Bezug. Es ging darum, dass mit den Memory Pools
in diesem Fall eine voellig legale Alternative zu SetFunction() existiert, der
trotz einiger konzeptioneller Schwaechen der Vorzug gegeben werden sollte
(sie kann ja immer noch besser werden).
Um Ersetzen oder nicht ging es ueberhaupt nicht.
Gruss,
Fionn
--
fionn@informatik.uni-siegen.de IRC: Fionn@#amigager
PGP Key available on request
-====### legal notice ###====------------------------------------------------
Microsoft Network is prohibited from redistributing this work in any form, in
whole or in part. License to distribute this post is available to Microsoft
for $499. Posting without permission constitutes an agreement to these terms.
Re: HD Cache
Author: Marco Krause
Date: Fri, 23 Feb 1996 17:35
Date: Fri, 23 Feb 1996 17:35
19 lines
1370 bytes
1370 bytes
fionn@informatik.uni-siegen.de (Fionn Behrens) schrieb am 21.02.1996: > Du postest offensichtlich ohne Bezug. Es ging darum, dass mit den Memory Pools > in diesem Fall eine voellig legale Alternative zu SetFunction() existiert, der Dann habe ich Dich falsch verstanden. > trotz einiger konzeptioneller Schwaechen der Vorzug gegeben werden sollte > (sie kann ja immer noch besser werden). > Um Ersetzen oder nicht ging es ueberhaupt nicht. Ich sehe da keinen Zusammenhang zwischen den Memory-Pools und SetFunction(). Ein vollkommen dynamischer Cache ohne Patchen der Speicherfunktionen ist nicht möglich. -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Michael van Elst
Date: Sat, 24 Feb 1996 00:41
Date: Sat, 24 Feb 1996 00:41
11 lines
731 bytes
731 bytes
marco@cosmos-l.gun.de (Marco Krause) writes:
>Ein vollkommen dynamischer Cache ohne Patchen der Speicherfunktionen ist
>nicht möglich.
Quatsch.
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Marc 'Nepomuk' Heuler
Date: Sun, 25 Feb 1996 08:43
Date: Sun, 25 Feb 1996 08:43
19 lines
1343 bytes
1343 bytes
In article <4glmsk$ekc@serpens.rhein.de>, Michael van Elst writes: > >Ein vollkommen dynamischer Cache ohne Patchen der Speicherfunktionen ist > >nicht möglich. > > Quatsch. Also in der Art von DynamiCache ist's nicht möglich. Denn echtes Belegen des Speichers würde dazu führen, daß AvailMem() nur wenig freien Speicher meldet. Programme, die sich dynamisch dem verfügbaren Speicher anpassen (zB ein Copy-Befehl, der 50% des freien Speichers als Buffer-Größe ansetzt, oder eine durch viel Speicheraufwand zu beschleunigende Kompression ala PowerPacker), würden verwirrt und daher weniger Speicher nutzen, als ihnen zustände. Ein Programm kann schließlich nicht erfragen, wieviel wenig wichtiger Speicher im Ernstfall frei gemacht werden kann, sondern nur wieviel Speicher völlig leer brachliegt.
Re: HD Cache
Author: Marco Krause
Date: Sun, 25 Feb 1996 16:59
Date: Sun, 25 Feb 1996 16:59
13 lines
961 bytes
961 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 23.02.1996: > >Ein vollkommen dynamischer Cache ohne Patchen der Speicherfunktionen ist > >nicht möglich. > > Quatsch. Und wie willst Du das bitte machen? -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Michael van Elst
Date: Sun, 25 Feb 1996 22:29
Date: Sun, 25 Feb 1996 22:29
28 lines
1631 bytes
1631 bytes
marc@aargh.incubus.sub.org (Marc 'Nepomuk' Heuler) writes:
>Denn echtes Belegen des Speichers würde dazu führen, daß AvailMem() nur
>wenig freien Speicher meldet.
Was sicher nicht stoert.
>Programme, die sich dynamisch dem
>verfügbaren Speicher anpassen (zB ein Copy-Befehl, der 50% des freien
>Speichers als Buffer-Größe ansetzt, oder eine durch viel Speicheraufwand zu
>beschleunigende Kompression ala PowerPacker), würden verwirrt und daher
>weniger Speicher nutzen, als ihnen zustände.
Selber schuld.
>Ein Programm kann schließlich nicht erfragen, wieviel wenig wichtiger
>Speicher im Ernstfall frei gemacht werden kann, sondern nur wieviel
>Speicher völlig leer brachliegt.
Wo ist das Problem ? Ein Programm sollte soviel Speicher anfordern, wie es braucht.
Wenn das schiefgeht, kann es sich ja was anderes ueberlegen. Ein Nachschauen per
AvailMem hilft allenfalls die Behandlung des Worst-Cases zu beschleunigen.
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Michael van Elst
Date: Sun, 25 Feb 1996 22:31
Date: Sun, 25 Feb 1996 22:31
20 lines
968 bytes
968 bytes
marco@cosmos-l.gun.de (Marco Krause) writes:
>mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 23.02.1996:
>> >Ein vollkommen dynamischer Cache ohne Patchen der Speicherfunktionen ist
>> >nicht möglich.
>>
>> Quatsch.
>Und wie willst Du das bitte machen?
Speicher anfordern, wenn er gebraucht wird und Speicher freigeben, wenn andere
Programme Speicher brauchen.
Salut,
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Marco Krause
Date: Mon, 26 Feb 1996 18:11
Date: Mon, 26 Feb 1996 18:11
12 lines
1038 bytes
1038 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 25.02.1996: > Speicher anfordern, wenn er gebraucht wird und Speicher freigeben, wenn andere > Programme Speicher brauchen. Und woher willst Du wissen, wann andere Programme Speicher brauchen? Der Memory-Handler ist ja wohl ein Witz. -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Marco Krause
Date: Mon, 26 Feb 1996 18:13
Date: Mon, 26 Feb 1996 18:13
10 lines
953 bytes
953 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 25.02.1996: > Wo ist das Problem ? Ein Programm sollte soviel Speicher anfordern, wie es braucht. Und dadurch womöglich im ChipMem landen? Nein danke! -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Michael van Elst
Date: Mon, 26 Feb 1996 22:38
Date: Mon, 26 Feb 1996 22:38
18 lines
1053 bytes
1053 bytes
marco@cosmos-l.gun.de (Marco Krause) writes:
>mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 25.02.1996:
>> Speicher anfordern, wenn er gebraucht wird und Speicher freigeben, wenn andere
>> Programme Speicher brauchen.
>Und woher willst Du wissen, wann andere Programme Speicher brauchen? Der
>Memory-Handler ist ja wohl ein Witz.
Du meinst die explizit vom System zu diesem Zweck vorgesehene Funktion ist ein
Witz und ein paar wilde Patches sind besser ?
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Michael van Elst
Date: Mon, 26 Feb 1996 22:39
Date: Mon, 26 Feb 1996 22:39
14 lines
887 bytes
887 bytes
marco@cosmos-l.gun.de (Marco Krause) writes:
>mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 25.02.1996:
>> Wo ist das Problem ? Ein Programm sollte soviel Speicher anfordern, wie es braucht.
>Und dadurch womöglich im ChipMem landen? Nein danke!
ChipMem ist besser als gar kein Speicher, oder ?
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Sven Tegethoff
Date: Tue, 27 Feb 1996 11:49
Date: Tue, 27 Feb 1996 11:49
45 lines
2841 bytes
2841 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 25.02.1996 um 23:29:54 Uhr folgendes unter dem Betreff "Re: HD Cache":
ME> marc@aargh.incubus.sub.org (Marc 'Nepomuk' Heuler) writes:
ME>
ME> >Denn echtes Belegen des Speichers würde dazu führen, daß AvailMem() nur
ME> >wenig freien Speicher meldet.
ME>
ME> Was sicher nicht stoert.
Sämtliche Programme, die einen möglichst grossen Zusammenhängenden
speicherblock benötigen, schauen in die Röhre, weil man sich mit
dem dynamischen Cache ganz wunderbar den Speicher zerfräst, und
der noch nichtmal freigegeben wird.
ME> >Ein Programm kann schließlich nicht erfragen, wieviel wenig wichtiger
ME> >Speicher im Ernstfall frei gemacht werden kann, sondern nur wieviel
ME> >Speicher völlig leer brachliegt.
ME>
ME> Wo ist das Problem ? Ein Programm sollte soviel Speicher anfordern, wie es braucht.
ME> Wenn das schiefgeht, kann es sich ja was anderes ueberlegen. Ein Nachschauen per
ME> AvailMem hilft allenfalls die Behandlung des Worst-Cases zu beschleunigen.
Woher soll z.B. Audiomaster wissen, wieviel Speicher ich brauche, bevor
ich mit dem sampeln angefangen habe ?
Und wenn ich mit dem Sampeln anfange, woher soll Audiomaster im vorraus
wissen, wie lang das Stück werden soll ?
Zu dumm, daß dank dem Cache MEMF_LARGEST nur 100 Kilobytes von 8MB sind...
Ganz davon abgesehen, daß ich jetzt auch mit dem AVAIL-Befehl nicht
mehr vernünftig abfragen kann, wieviel Speicher eigentlich _wirklich_
zur verfügung steht, es sei denn ich schaue immer per Hand die aktuelle
cache-grösse nach, und ziehe sie vom belegten speicher ab.
Mag sein, daß man für die patchmethode nicht den goldenen Amiga-Technologies-
Styleguide-Preis verliehen bekommt, aber nen dynamischen Cache nur über
nen low-memory-handler zu implementieren finde ich vom Benutzerstandpunkt
aus einfach gnadenlos unkomfortabel.
CIAO, ____/|
____ |____ ____ ____ |__ ____ |____ @ius.gun.de | Radjah on \ o.O|
(_____| )(___/_(___/_|____(____|| ) @softgold.com | FurryMuck =(_)=
U
A smiling face, a warm embrace, two paws to hold me tenderly ...
Re: HD Cache
Author: Michael van Elst
Date: Tue, 27 Feb 1996 18:22
Date: Tue, 27 Feb 1996 18:22
60 lines
2449 bytes
2449 bytes
CHEETAH@IUS.gun.de (Sven Tegethoff) writes:
>ME> >Denn echtes Belegen des Speichers würde dazu führen, daß AvailMem() nur
>ME> >wenig freien Speicher meldet.
>ME> Was sicher nicht stoert.
>Sämtliche Programme, die einen möglichst grossen Zusammenhängenden
>speicherblock benötigen, schauen in die Röhre,
Nein. Warum sollten sie ?
>weil man sich mit
>dem dynamischen Cache ganz wunderbar den Speicher zerfräst,
Das haengt einzig und allein von der Strategie des Caches ab.
>und
>der noch nichtmal freigegeben wird.
Warum sollte der nicht freigegeben werden ? Weil Du das nicht willst ?
>Woher soll z.B. Audiomaster wissen, wieviel Speicher ich brauche, bevor
>ich mit dem sampeln angefangen habe ?
Du sagst es ihm oder er macht eine Abschaetzung und versucht einfach den
Speicher anzufordern.
>Und wenn ich mit dem Sampeln anfange, woher soll Audiomaster im vorraus
>wissen, wie lang das Stück werden soll ?
Muss er nicht wissen.
>Zu dumm, daß dank dem Cache MEMF_LARGEST nur 100 Kilobytes von 8MB sind...
Warum sollte Audiomaster denn den groessten zusammenhaengenden Block anfordern ?
Ich weiss, dass der das tut, aber das ist halt eine dumme Strategie.
>Ganz davon abgesehen, daß ich jetzt auch mit dem AVAIL-Befehl nicht
>mehr vernünftig abfragen kann, wieviel Speicher eigentlich _wirklich_
>zur verfügung steht,
Das konntest Du nie.
>es sei denn ich schaue immer per Hand die aktuelle
>cache-grösse nach, und ziehe sie vom belegten speicher ab.
Ein "avail flush" wird wohl den gesamten Cache flushen.
>Styleguide-Preis verliehen bekommt, aber nen dynamischen Cache nur über
>nen low-memory-handler zu implementieren finde ich vom Benutzerstandpunkt
>aus einfach gnadenlos unkomfortabel.
Direkten Hardwarezugriff zu verhindern ist fuer C0d3r auch unkomfortabel,
aber micht stoert das nicht.
--
Michael van Elst
Internet: mlelstv@serpens.rhein.de
"A potential Snark may lurk in every tree."
Re: HD Cache
Author: Marco Krause
Date: Wed, 28 Feb 1996 18:26
Date: Wed, 28 Feb 1996 18:26
12 lines
1031 bytes
1031 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 26.02.1996: > Du meinst die explizit vom System zu diesem Zweck vorgesehene Funktion ist ein > Witz und ein paar wilde Patches sind besser ? Sie ist ein Witz, solange dadurch Programme und deren Daten im ChipMem landen können! -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Marco Krause
Date: Wed, 28 Feb 1996 18:28
Date: Wed, 28 Feb 1996 18:28
10 lines
929 bytes
929 bytes
mlelstv@serpens.rhein.de (Michael van Elst) schrieb am 26.02.1996: > ChipMem ist besser als gar kein Speicher, oder ? Solange noch genug anderer Speicher zur Verfügung steht, nicht. -- _--------------------------------------------------' _ // Marco Krause (<*>) E-Mail: Marco@Cosmos-L.gun.de/ \X/ (Germany) <Powered by Motorola 'o4o & SAS/C> / ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: HD Cache
Author: Sven Tegethoff
Date: Fri, 01 Mar 1996 23:47
Date: Fri, 01 Mar 1996 23:47
71 lines
3502 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads