Re: Martin's Privatmeinung

Hallo Joerg,

>As norbert.meissner(at)daimlerchrysler.com wrote:

>Ich kann Martins Reaktion verstehen, auch wenn ich sie nicht billigen
>mag. (Hängt vielleicht damit zusammen, das ich täglich mit Kunden zu
>tun habe, die ähnlich besch***ene Software verwenden wie Du, so daß
>ich verstümmelte Threads, nicht ordentlich markierte Quotes etc.
>mittlerweile gewohnt bin. Dennoch k*tzen sie auch mich genauso an wie
>Martin. Nicht die Leute, die so einen Mist verwenden müssen, obwohl
>sie nicht anders dürfen [in der Firma], sondern eher die
>Programmierer, die so einen nicht mit Internet-Gepflogenheiten
>konformen Quatsch verzapft haben, sowie das Resultat, das uns dann
>präsentiert wird und uns das Leben schwerer macht als nötig.)

Ich habe mich nicht gegen Martins Klage gewandt, sondern gegen die Art,
wie er das tut. Ich habe keine Lust mich hier in der Liste diffamieren
zu lassen, als jemand der nur Unsinn redet und "korrigiert" werden muss!

>Aber: steter Tropfen höhlt den Stein. Auch DaimlerChrylserBMWwasweissich
>nimmt irgendwann eine andere Software, wenn sich nur genügend Leute über
>den Müll beschweren, den die jetzige fabriziert. Davor steht aber Deine
>Erkenntnis, _daß_ Eure Software Datenmüll produziert.

Diese Erkenntnis haben hier ca 90%, meine Wenigkeit eingeschlossen. Aber,
um aus dem Naehkaestchen zu plaudern, diese Software ist Konzernbeschluss,
es wurden zur Einfuehrung enorme Summen aufgewendet und die Sache ist von
daher ein Selbstlaeufer geworden. Was soll ich machen, kuendigen? Mein
Versuch die ganze Mail-Geschichte hier auf der BSD-Maschine abzuwickeln
ist auch gescheitert, da ich im externen DNS nicht eingetragen bin und
auch nicht werde.

>> Leider wieder falsch. Da Kompression ein statistisches Verfahren ist,
>> erreicht man in groesseren Dateien (=Bloecke) bessere Kompressions-
>> raten.
>
>Im Prinzip ja. Komprimierung der Tapelaufwerke ist aber an deren
>Hardware-Blockgröße gebunden. Leider lassen nur wenige Hersteller so
>tief in Details gucken, daß Du darüber was erfährst. Du kannst aber
>davon ausgehen, daß die größten Hardwareblockgrößen heutiger
>Tapelaufwerke bei einigen wenigen Kilobyte liegen. Komprimiert wird
>dann innerhalb dieser Blöcke, mehr nicht. Die Limitierung auf
>derartige Blockgrößen ist für die Anwendung einer automatischen
>Fehlerkorrektur unabdinglich -- wir leben schließlich nicht mehr in
>einer Zeit wie früher bei den Floppies, wo man hinterher alles nochmal
>kontrollesen mußte...

Hmmm, ich habe mal meine alte Liste vom VXA herausgekramt. Da wird eine
Datei mit tar auf Band geschrieben (Groesse weiss ich nicht mehr) mit
wechselnden Blocksizes (512Byte Blocks) und danach die Sekunden, die es
gedauert hat.

asciidaten, comp on
 16 135
 32 99
 64 80
 96 73
128 70
160 80
192 77
224 76
256 71
320 75
384 71
448 75
512 72

binary-daten, comp on
 16 133
 32 114
 64 79
 96 73
128 72
160 79
192 76
224 74
256 71
320 75
384 71
448 73
512 73

Bei den Ascii-Daten sieht man bei der Verdoppelung der Blocksize
(16,32,64) jeweils eine Zunahme von ueber 10%; bei den Binary-Daten
ist es nicht ganz so viel. Ich wuerde allerdings den Unterschied
nicht als gering bezeichnen. Wenn man sich allerdings den doch recht
dramatischen Unterschied zwischen 8K und 64K anschaut, spricht das
nicht gerade fuer deine Aussage von Kompression auf Basis der Hard-
warebloecke. Weiterhin ist der Wert fuer unkomprimiertes Schreiben
nur unwesentlich (2-3 Sekunden) groesser als beim komprimierten
Schreiben auf Basis von 8k-Blocks. Hier findet die Kompression offen-
sichtlich nicht statt. Ganz am Anfang, hatte ich mit den Default-
Blockgroessen der Programme gearbeitet und erreichte damit nicht
einmal ansatzweise die angebebenen Eckdaten des Laufwerks hinsicht-
lich der Performance. Auf Anfrage bekam ich von Ecrix die Auskunft
die Blockgroesse mal "anzuheizen".

>> Das habe ich auch so nicht behauptet. Ich weiss nur, das ich in der
>> liste mal gelesen habe, das das SCSI-System maximal 64Kb grosse
>> Bloecke verarbeitet und darueber also kein Performancegewinn mehr
>> auf Platte oder Band zu erwarten ist.
>
>Der Performancegewinn ist schon darunter sehr gering. Probier's mal
>aus, den Unterschied zwischen 10 KB (default Größe vom tar) und 32 KB
>(default von dump für einige Laufwerke) zu messen.

Richtig, ich den obigen Test auch mit comp off durchgefuehrt und aus
den ermittelten Werten geht genau das hervor.

>> Ich moechte dir jetzt hier zum zweiten Mal empfehlen deinen Schreibstil
>> zu ueberdenken bzw. dir eine andere Liste zu suchen.

>Wir

Pluralis majestatis ?

>würden Dir hier zum N-ten Mal empfehlen, eine Software zu
>benutzen, die zumindest die Threads beisammen läßt. Es liest sich
>_sehr_ lästig, wenn man zum gleichen Thema an drei verschiedenen
>Stellen lesen muß. Es zählt dabei auch nicht als Entschuldigung, daß
>die von Dir verwendete Software sowieso keine Ahnung von Threads hat
>und Dir folglich diese auch nicht darstellen kann (das ist
>ausschließlich Dein Problem), sondern entscheidend ist, daß die
>`References' Headers so benutzt werden, wie sie auch der Rest der Welt
>benutzt.

Siehe oben. Ich bin allerdings fuer jeden konstruktiven Vorschlag dankbar,
um die "Manieren" von Lotus Notes auf diese Liste anzupassen bzw. das
DNS-Problem auf meiner BSD-Maschine zu loesen.

Im uebrigen habe ich mir der obigen Zeile zum Ausdruck bringen wollen,
das Martin mich mittlerweile zum 2. Male angeflamed hat.

>>> >Die variable Blocksize hat m.W. nicht das geringste mit Kompression
>>> >oder Comprimierbarkeit zu tun,
>>>
>>> Schoen, das du lesen kannst.
>
>Schön, daß Du Ahnung hast, um mit Deinen Worten zu kontern...

Schlecht, das ich keine Ahnung habe, wie ich in der Zeile darueber
zugegeben habe. Leider hast du diese nicht mitgequotet.

Viele Gruesse
Norbert

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 22 Nov 2000 - 13:51:33 CET