🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: de.comp.sys.amiga.tech
24 messages
24 total messages Started by Thomas Schuerger Thu, 25 Jan 1996 19:28
HD Cache
#3087
Author: Thomas Schuerger
Date: Thu, 25 Jan 1996 19:28
36 lines
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
#3125
Author: Jens-Olaf Brand
Date: Sat, 27 Jan 1996 13:00
41 lines
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
#3220
Author: Alexander Abt
Date: Thu, 01 Feb 1996 20:33
19 lines
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
#3342
Author: Matthias Scheler
Date: Fri, 09 Feb 1996 21:03
13 lines
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
#3317
Author: Fionn Behrens
Date: Sat, 10 Feb 1996 17:37
18 lines
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
#3731
Author: Marco Krause
Date: Sun, 11 Feb 1996 17:25
13 lines
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
#3622
Author: Fionn Behrens
Date: Wed, 14 Feb 1996 22:19
27 lines
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
#3733
Author: Marco Krause
Date: Thu, 15 Feb 1996 18:59
12 lines
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
#3501
Author: Fionn Behrens
Date: Wed, 21 Feb 1996 22:01
27 lines
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
#3543
Author: Marco Krause
Date: Fri, 23 Feb 1996 17:35
19 lines
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
#3555
Author: Michael van Elst
Date: Sat, 24 Feb 1996 00:41
11 lines
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
#3760
Author: Marc 'Nepomuk' Heuler
Date: Sun, 25 Feb 1996 08:43
19 lines
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
#3763
Author: Marco Krause
Date: Sun, 25 Feb 1996 16:59
13 lines
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
#3767
Author: Michael van Elst
Date: Sun, 25 Feb 1996 22:29
28 lines
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
#3768
Author: Michael van Elst
Date: Sun, 25 Feb 1996 22:31
20 lines
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
#3786
Author: Marco Krause
Date: Mon, 26 Feb 1996 18:11
12 lines
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
#3787
Author: Marco Krause
Date: Mon, 26 Feb 1996 18:13
10 lines
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
#3790
Author: Michael van Elst
Date: Mon, 26 Feb 1996 22:38
18 lines
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
#3791
Author: Michael van Elst
Date: Mon, 26 Feb 1996 22:39
14 lines
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
#3818
Author: Sven Tegethoff
Date: Tue, 27 Feb 1996 11:49
45 lines
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
#3820
Author: Michael van Elst
Date: Tue, 27 Feb 1996 18:22
60 lines
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
#3867
Author: Marco Krause
Date: Wed, 28 Feb 1996 18:26
12 lines
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
#3868
Author: Marco Krause
Date: Wed, 28 Feb 1996 18:28
10 lines
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
#3889
Author: 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
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