XUG Osnabrück-Treffen mit Besuch von Steffen Pirsig

[andreas]

Ich habe es schon ausprobiert: von der Einrichtung unter Windows (Einzelplatz) bis zu der Durchführung mit Shell-Befehlen.
Ich denke, dass es evtl. ein Thema für unser nächstes Treffen seien könnte.
Es gibt noch einen Windows-Client mit GUI "WinCVS", den habe ich aber bis jetzt mit meiner lokalen Version nicht zum laufen bekommen.
Irgendwie verstehe ich es gar nicht!

CVS hat aber ein Nachteil: es sichert automatisch alle Textdateien. Die binäre Daten bleiben außen vor. Diese müsste man dann einzeln mit speziellen Parameter sichern, was vielleicht bei vielen Bildern problematisch wäre.
Es gibt einen Nachfolger "subversion" oder ähnlich. Diesen habe ich mir aber noch nicht angesehen.

[Jan]

Steffen hatte ja erwähnt, daß er twittert. Und auch schon Erfolg damit hatte, daß es zu neuen Kontakten durch Twitter geommen ist. Hier gibt es die Neuigkeiten. Die letzte, 2 Stunden alt, ist natürlich für die Mitglieder der XUG OS und deren Gäste nichts neues mehr

Jan

[Manfred]

Super,

jetzt ist die Handynummer von Andreas wenigstens komplett bekannt. (Oder ist es nicht Deine?)
Also Andreas vielleicht viel Spass noch damit.

[Jan]

Meine Firmen-Nummer. Na, mein Chef wird sich freuen

Jan

[Tom]

Die letzte, 2 Stunden alt, ist natürlich für die Mitglieder der XUG OS und deren Gäste nichts neues mehr

Mussten Verschwiegenheitserklärungen unterschrieben werden oder warum berichtet nicht mal jemand - wenigstens zusammengefasst - darüber, was so alles erklärt und verkündet wurde?

[Manfred]

Es hat ja keiner gefragt...

Es sah jetzt bis jetzt so aus, als wenn es allen egal war, das wir uns getroffen haben.

[Manfred]

Na gut,

dann eben ohne Aufforderung.

Also Steffen Piersig und Friedhelm hatten Beiträge geliefert. Steffen von ca. 13:30 Uhr bis 18:30 Uhr und dann kam Friedhelm noch kurz zum Zug. (Hatte Glück, der Bahnhof war nicht weit weg.)

Steffen hatte uns einen Vortrag darüber gehalten, wie sich die Hardware von 1990 bis 2009 verändert hat. Festplatten wurde größer, schneller usw. Prozessoren wurde schneller und Netzwerke und RAM.
Dann hat er alles in Relation zu einander gesetzt und damit Verdeutlicht, das zwar die HD größer und schneller geworden sind, Prozessoren schneller geworden sind RAM mehr zur Verfügung steht und auch schneller geworden ist, aber wenn man es genau sieht, dann dauert es heutzutage wesentlich länger die Menge an Daten zu verarbeiten, weil die Latenzzeit im Verhältnis dazu nicht mitgewachsen ist. Mit anderen Worten, es ist alles langsamer als früher, weil halt die Menge wesentlich größer geworden ist. Netzwerkkarten sind das beste Beispiel dafür. Es gibt zwar GBit Netzwerke, aber ein vernünftiges 100MBit Netzwerk dürfte schneller sein, als ein weniger gutes 1Gbit Netzwerk. Usw.

Was aber sehr interessant war, war die Sache mit dem Sleep() Befehl:

Sleep(0)

Sleep(0) erreicht folgendes: Es wird dafür gesorgt, dass bei Nichtstun der CPU dieser Prozess (oder eine Schleife) die volle Aufmerksamkeit erhält. Solange bis ein anderer Prozess etwas will. Sollte der andere Prozess fertig sein, dann geht die Aufmerksamkeit sofort wieder zurück an den Prozess mit Sleep(0). Bei Sleep(100) z.B. würde der Prozess frühestens nach Ablauf der 100ms wieder Aufmerksamkeit erhalten. So kann man immer sicher sein, dass der besagte Prozess sofort und solange laufen kann, bis ein anderer Prozess etwas anfordert oder es abgibt. (ich hoffe das war jetzt nicht von hinten durch die Brust erklärt.

[Manfred]

weiter gehts

Friedhelm zeigte seine Vorabversion des Formdesigners, welcher eigentlich schon eine komplette Projektverwaltung darstellt/darstellen soll. Da Friedhelm aber nur 1 Stunde Zeit hatte, wurde es wohl nur etwas an der Oberfläche angekratzt.

Arctica soll ab September für Kunden zur Verfügung stehen. Was jetzt ganz genau welche Sub. bekommen kann/wird, ist letztendlich noch nicht genau geklärt, aber so wie ich Steffen verstanden habe, sollen die ersten beiden SQL Stufen für die Foundation und die 3.Stufe (ich glaube das ist Universal SQL. Verbessert mich, wenn ich falsch liege) dann ab der Prof. Sub zur Verfügung stehen. Steffen möchte auf jeden Fall das ALLE Xbase++ Kunden (zahlende!) SQL benutzen können.

VX 2.0 ist in der Mache, wird aber noch "etwas" dauern.
Updates für die VX 1.9.338 wird es wohl zwischendurch noch geben, aber wann war auch nicht geklärt. Im Moment ist die .388 angesagt und etwas anderes gibt es auch nicht. (Habe ich heute von Andreas erfahren) Die Priorität liegt zur Zeit darin, bei Arctica Dampf zu machen.

[Tom]

Hallo, Manfred.

Danke!

Die Erklärung für Sleep(0) (Wo soll das hin? Und wann?) habe ich nicht ganz verstanden.

Und dann war doch wohl noch die Rede von Hotfixes für SL1. Welche? Wann verfügbar?

Und auch dafür gleich vorweg: Danke!

[Manfred]

Hi Tom,

das gilt generell für ein Sleep(). Sleep(0) sorgt dafür, dass das OS sich um die Zeitverteilung kümmert, wenn man ein Maximum erreichen will. Wenn Du Sleep(100) z.B. wählst, egal jetzt wo Du eine "Pause" einbauen willst, dann ist die Pause 100. bei "0" ist sie solange, wie sie max. sein muß. Wie war die passende Erklärung am Samstag? Das OS sagt dann zu dem Sleep(0): Wenn keiner was tut und Du hast Langeweile, dann arbeite für mich. Was bei 100 oder so erst nach der abgelaufenen Zeit wieder der Fall wäre.

Ich hoffe ich verklausuliere das jetzt nicht so sehr.

So, und wie war die andere Frage?

Hotfixes für SL1 ? Gibt es da welche? Ich weiß von nichts.

[Jan]

Tom,

mit dem Sleep das Problem liegt darin, daß wenn ich eine Zeit angebe (z. B. Sleep(100)), das Programm sich diese Zeit auch nimmt. Bei Sleep(0) bekommt aber Windows schlicht nur die Möglichkeit, da Threadmäßig einzugreifen. Wenn aber sonst nichts wartet, kann es sofort mit dem Xbase-Programm weitergehen. Was bei einer Zeitvorgabe nichts so wäre, da würde immer gewartet werden. Ich konnte es mir natürlich nicht verkneifen, Steffen auf einen Fehler in deren eigenem Beispielprogramm hinzuweisen. Er meinte, das in dem Animate ein Sleep(0) drin wäre, aus genau diesem Grund. Stimmt aber nicht, die haben da ebenfalls Verzögerungswerte reingeschrieben.

Außerdem wurde darauf hingewiesen, daß diese Systematik nicht in der Onlinehilfe steht. Steffen wird das korrigieren.

Jan


OOps, Manfred war schneller

[Tom]

Danke für die Erklärungen. Es mag an mir liegen, dass ich mir derzeit keinen Anwendungsfall vorstellen kann.

[Jan]

Hotfixes für SL1 ? Gibt es da welche? Ich weiß von nichts.

Doch, hat Steffen angekündigt. Und wenn Du richtig mitgelesen hättest, dann hättest Du hier nachgesehen.

Jan

[Manfred]

Noch watt,

Wenn mann eine Do while Schleife hat z.B. dann wird/würde die Prozessorauslastung evtl. sehr hoch gehen, also wird ein Sleep eingebaut, damit andere Prozesse auch eine Scheibe abbekommen. Wenn aber jetzt kein anderer Prozess da ist (mal angenommen) dann würde die Pause trotzdem gemacht werden und das wäre doof. Also Sleep(0) in der Schleife, für den Fall, dass es einen anderen Prozess gibt. Wenn nicht, gibt es auch keine Pause. Motto: Soviel Pause wie nötig, sowenig Pause wir möglich.

[Manfred]

@Jan

Zankapfel.....

habe ich gelesen, aber genau so ignoriert, wie Du, wenn man Dir was sagt.

[Jan]

Arctica soll ab September für Kunden zur Verfügung stehen. Was jetzt ganz genau welche Sub. bekommen kann/wird, ist letztendlich noch nicht genau geklärt, aber so wie ich Steffen verstanden habe, sollen die ersten beiden SQL Stufen für die Foundation und die 3.Stufe (ich glaube das ist Universal SQL. Verbessert mich, wenn ich falsch liege) dann ab der Prof. Sub zur Verfügung stehen. Steffen möchte auf jeden Fall das ALLE Xbase++ Kunden (zahlende!) SQL benutzen können.

Das verstehe ich jetzt nicht, was Du da schreibst.

Steffen hat gesagt daß Arktica NICHT wie das SL1 durch ein Preview laufen wird. Es wird 4 Abschnitte à 20 Werktage geben, in denen genau diese 4 Bereiche abgeklopft werden. Macht also 4 Monate. Wenn also alles glatt geht, dann haben wir um die Jahreswende Arktica im Postfach.

Außerdem hat Steffen darauf hingewiesen, daß Arktica vermutlich bis auf das Migrationstool in der Foundation Subscription liegen wird. Das ist noch nicht abschließend entschieden. Aber wie Du schon sagtest: Alaska möchte das tolle Feature Arktica unter die Leute bringen.

Und VX kommt irgendwann danach. Es wird schon massiv daran geschraubt, in der Versionsnummerierung ist das sogar schon weiter als Arkitca. Wichtig für uns ist , daß durchzieht, die er in Berlin angekündigt hat: Es wird nicht gewartet, bis alles fertig ist, sondern nach jedem Teilstück kommt der fertige Teil auch sofort raus.

Jan

[Manfred]

Jaja,

das Du mich nicht verstehst, dass war mal wieder klar. Habe ich geschrieben, Steffen hat gesagt, oder so wie ich ihn verstanden habe? Dann habe ich ihn eben falsch verstanden. Ich bin 50, ich darf das......

[Jan]

@Jan

Zankapfel.....

habe ich gelesen, aber genau so ignoriert, wie Du, wenn man Dir was sagt.

Herr von und zu Kunz,

würden Sie bitte diese persönlichen Animositäten lassen?

Außerdem: Steffen hat das am Samstag auch verbal vermittelt. Aber da waren wohl gerade die Vollmilchkekse wichtiger als das Zuhören Sind die Kilos schon abgeradelt?

Jan

[Tom]

@Manfred:

Also sowas:

Code: Alles auswählen

DO WHILE !RLock()
Sleep(0)
ENDDO

für eine Situation, in der man zwar weiß, dass Datensätze wahrscheinlich nicht und wenn, dann bestenfalls für ein paar Sekundenbruchteile gesperrt sind (weil man in der gesamten App so arbeitet), und also sicherheitshalber so eine Schleife baut. Richtig?

[Manfred]

Hm,

sagen wir mal so: Egal wo Du das mit dem Sleep(0) einbaust. Wenn Du verhindern willst, dass dieser eine Prozess alle Prozessorzeit an sich bindet, dann baust Du ja ein Sleep(x) ein um dem OS zwischendurch mal die Möglichkeit zu geben, einen anderen Prozess mit Rechenzeit zu versorgen. Das ist auch OK so, ABER die eingegebe Pause wird immer genommen, egal ob ein anderer Prozess sie haben will oder nicht. Bei "0" wird nichts gemacht, solange kein anderer Prozess Zeit haben will. Der Sleep(0) Prozess kann also Gas geben, bzw. wird so schnell wie möglich wieder mit Zeit versorgt.

[Manfred]

So, nochmal auch für die, die mich nicht verstehen wollen...

es soll ja 3 Stufen für SQL geben:

1) PostGreSql
2) die hier vergesse ich immer
3) Universal SQL

1+2 kommt wohl mindestens in die Foundation. Ob 3 auch da rein kommt, das wird noch überlegt. Aber 3 kommt auf jeden Fall in die Prof Sub.

Alles klar Jan?

[Rolf Ramacher]

Hi,

also ein Sleep(100) z.B. baue ich ein, wenn eine große anzahl von Daten durchlaufen werden. Sei es Array oder eine DBF. Dieses verhindert die Systemauslastung von 100 %. Ob man 100 oder 50 nimmt oder wieviel auch immer darüber läßt sich mit Sicherheit
streiten. Aber es macht Sinn, damit andere Programme noch genügend Power vom System erhalten.

@Manfred du mußt nicht immer alles auf die '50' schieben.

[Jan]

Rolf,

genau das ist es, was Steffen meinte. Setz es auf Sleep(0). Damit kann Windows immer noch eingreifen, aber Du verlierst nicht so viel Zeit beim Durcharbeiten der großen dbf.

Jan

[Manfred]

Manchmal kann das Leben einfach nur gemein sein. Aber warum immer zu mir...

am besten immer nur ganz tief durchatmen und sagen: alles wird gut.

[AUGE_OHR]

Na gut,
dann eben ohne Aufforderung.

... siehste geht doch

...dann dauert es heutzutage wesentlich länger die Menge an Daten zu verarbeiten, weil die Latenzzeit im Verhältnis dazu nicht mitgewachsen ist.

das ist eine "Milchmädchen" Rechnung die "so" nicht stimmt...

richtig ist das jeder CPU "Zyklus" jetzt "länger" dauert, dafür sind aber andere wesentlich schneller
geworden wie RAM (Dimm, SDram, DDR1, DDR2, DDR3 ) oder auch "das langsamste" Teil die HD
(PIO, UDMA, SATA)

... das wir "grössere" Datein z.b. Vilme etc haben ist ja schön und gut, aber wie "wirkt" sich das
auf Xbase++ aus ? welche "Blockgrösse" benutzt Xbase++ ? ... bestimmt nicht 1GB Blöcke

, aber ein vernünftiges 100MBit Netzwerk dürfte schneller sein, als ein weniger gutes 1Gbit Netzwerk. Usw.

ja die leidige Erfahrung habe ich auch schon gemacht und deshalb auch die Frage nach
der "Blockgrösse" von Xbase++

unter Novell arbeite ich mit der "kleinsten" Blöckgrösse 4Kb. Im Vergleich zu 64Kb Blöcken ist ein
"random" SEEK() ca. 20% (!!!) langsamer (2x Stationen 100mbit, 24Std Dauertest).
anders sieht die Sache bei einem Browse/PgDn/stabilize aus, da sind grössere Blöcke "besser",
wobei es ab 16Kb Blöcken wieder schlechter wird ...

unter W2K3r2 habe ich es auch auf verschiedenen Partitionen mit verschiedenen Blöckgrössen
ausprobiert, aber da geht auch immer der "Windows Cache" mit rein ... der Unterschied liegt
da bei 5-8% ... das "könnte" auch andere Ursachen haben.

was ist nun "schneller" ?

wie schon gesagt es scheint mir darauf an zu kommen "was" Xbase++ macht, den bei Cl*pper
bekomme ich nicht solche Werte z.b. PACK/INDEX ON ca. 130MB DBF und 50MB Index von
Workstation übers Netzwerk

100mbit/100mbit Novell* 58sec
100mbit/100mbit W2K3r 54sec
1Gbit/1Gbit W2K3r2 49sec

W2K3r2 "local" 48sec., also kaum ein Unterschied zum Netzwerk. ("zuviel" RAM bei "zuwenig" DBF ?)

btw. über eine 10mbit dauert es über 600sec sodas ich sogar über WLan "schneller" bin, das zu
der "Milchmädchen" Rechnung.

bei Xbase++ sieht die Sache ganz anders aus (>1min), erst bei "grossen" Datei und "langen"
Operationen (Copy TO) wird es schneller "unter Windows" ... der Novell Server scheint sich
"linear" zu verhalten.

*NW 3.2x mit v4.x NLM, 2.8Ghz, 1Gb, Promise ATA UDMA, 120GB 7200rpm, 3C90x 100mbit
sowie 3C2000-T 1Gbit (under Construction)

zu den 1Gbit Netzwerkkarten : "Vorsicht" bei "billigen" Ware. Zwar ist bei fast allen der "RealTech"
Chipsatz verbaut, aber die Treiber ... noch schlechter als die "Windows" Treiber. (sollte man nicht
benutzen wenn möglich). Dito. bei "onBoard" unbedingt nach den "lates" Treibern suchen.

und nicht vergessen "Power save" bei den Netzwerkkarten "ab-zu-schalten" den dann braucht
man sich nicht zu wundern warum es so lange dauert bis die Netzwerkkarte "aufgewacht" ist ...

Was aber sehr interessant war, war die Sache mit dem Sleep() Befehl:
Sleep(0)

das hört sich interessant an !