# Problem mit zeitsynchroner Hauptschleife/Threads



## 0xdeadbeef (18. Feb 2006)

Ich habe da ein merkwürdiges Problem.

Für ein Spiel möchte ich alle X Millisekunden einen Bildschirm berechnen. Das mache ich, indem ich einen folgenden Thread laufen lasse:



```
public void run() {    
    long timeBaseRepaint = System.currentTimeMillis();

    while (true) {
        long t = System.currentTimeMillis();
        if (t >= timeBaseRepaint + GameController.timePerFrame) {
            timeBaseRepaint += GameController.timePerFrame;
            redraw(); // does also repaint
        } else {        
            try {
                // time until next frame
                long diff = timeBaseRepaint + GameController.timePerFrame - t;
                // doesn't work well 
                /*
                if (diff>1)
                    Thread.sleep(diff);
                else
                    Thread.sleep(1);
                */            
                if (diff>5)
                    Thread.sleep(5);
                else
                    Thread.sleep(1);            
            } catch (InterruptedException ex) {}                
        }      
    }
}
```

Alle "GameController.timePerFrame" Millisekunden soll ein Repaint erzwungen werden (geschieht in der Funktion redraw().
Allerdings möchte ich zwischenzeitlich ein bißchen Rechenzeit freigeben. Ganz ohne "Thread.sleep()" verbraucht das Spiel einen deutlichen Anteil der CPU-Ressourcen, mit Sleep sinkt das in den kaum noch meßbaren Bereich. Deshalb rechnen ich dann, wenn kein Redraw erfolgen muß, die Zeit bis zum nächsten Redraw aus und lege mich dann solange schlafen.
Kurioserweise führt diese Variante (im Beispiel auskommentiert) dazu, daß die in einem zweiten Thread abgespielte Musik (MOD-Player) stottert. 

Wohlbemerkt: wenn mein Hauptthread sich "zu lange" schlafen legt, stottert die Musik aus dem zweiten Thread. Beschneide ich die Zeit, die ich den Haupt-Thread maximal schlafen lege auf einen kleineren Wert, dann scheint alles wunderbar zu funktionieren. Der zweite Thread blockiert übrigens immer dann, wenn in die "Line" keine Sounddaten mehr geschrieben werden können. Er verbraucht daher auch ohne Sleep kaum Rechenzeit und sein Aufrufraster ist durch die internen Puffer der Line und den zusätzlichen 2k-Puffer des Modplayers eigentlich unkritisch.
Mir ist nur absolut nicht klar, was eigentlich das Problem ist. Ich habe ewig mit Prioritäten und Sleep/Yield in beiden Threads rumprobiert, aber ich komme immer wieder darauf zurück, daß das Problem genau dann auftaucht, wenn ich meinen Haupt-Thread zu lange schlafen lege. Wobei mir nicht ersichtlich ist, was für den zweiten Thread oder die JVM der Unterschied ist, ob ich meinen Thread einmal für 30ms oder 6mnal für 5ms schlafen lege...

Hat jemand ähnliche Erfahrungen oder kann mir sagen, was da eigentlich genau das Problem ist? Ich kann jetzt natürlich den "Grenzwert" für die maximale Sleep-Periode irgendwie festlegen, habe aber die Befürchtung, daß das Problem auf anderen Rechnern trotzdem wieder auftritt...


----------



## Redfrettchen (19. Feb 2006)

Hi,
hast du dir mal das (PDF auf der Seite) durchgelesen?
Ich denke das darin vorgestellte Konzept ist ganz brauchbar.


----------



## 0xdeadbeef (19. Feb 2006)

Das ist zwar nicht uninteressant, aber mehr für die Einhaltung einer exakten Framerate und Spielgeschwindigkeit. Das wäre zwar auch noch ein Thema, aber da würde mir meine Methode für den Moment reichen. Zumal ich eigentlich weder eine undokumentierte Sun-Klasse noch JRE1.5-Features noch J3D nutzen will.

Mein eigentliches Problem, nämlich daß der zweite Thread bzw. sogar eher die Soundverarbeitung im System aus dem Tritt gerät, wenn ich Sleep mit zu großen oder auch nur stark variierenden Werten aufrufe, wird dadurch aber auch nicht verständlich.
Der Autor argumentiert lediglich, man sollte nicht zu kleine Werte oder gar kein Sleep verwenden, damit das System mit den Repaints nachkommt. Das ist nachvollziehbar und leicht zu beheben. Sein Ansatz geht aber auch dahin, einen variierenden und nicht nach oben begrenzten Sleep-Wert zu benutzen und genau unter diesen Voraussetzungen bekomme ich die geschilderten Probleme.


----------



## 0xdeadbeef (20. Feb 2006)

Wird immer mysteriöser. Habe mein Programm heute auf meinem Arbeits-PC laufen lassen und da läuft es mehr als doppelt so schnell (und dadurch wiederum ruckelig). Habe eine Zeit lange gebraucht um zu begreifen, daß der harmlos wirkende Code dazu führt, daß die Systemuhr des PCs beschleunigt wird.
Kein Witz: auf meinem Arbeits-PC kann man zweifellos beobachten, wie die Systemuhr beschleunigt, sobald mein Spiel läuft und wieder langsamer wird, wenn ich es beende. Nach ein paar Minuten ging meine Systemuhr bereits um 20 Minuten vor...
Bei mir zuhause läuft es etwas zu schnell, aber in einem Rahmen, der noch recht unauffällig ist. Wenn man's aber weiß, kann man aber auch bei mir beobachten, wie sich die Systemzeit beschleunigt. Bei einer Messung über eine Minute gibt es daran keine Zweifel mehr...

Tja, da ist wohl so einiges völlig im Eimer in der neuesten JRE...

Muß jetzt wohl doch auf einen präziseren Timer ausweichen - schon alleine, um die Systemzeit nicht völlig zu verstellen.


----------



## Illuvatar (20. Feb 2006)

Lol das is ja mal was  Irgendeine wirkliche Idee hab ich jetzt nicht, bloß zu dem mit dem Zeit-Verstellen: meinst du mit der neuesten JRE 6.0 Beta? Wenn ja: Hast du schon mal eine ältere Stable-Version, also 1.4 oder 1.5 getestet?


----------



## 0xdeadbeef (20. Feb 2006)

Ok, weitere Tests und Recherche haben gezeigt, daß es das ein altbekanntes Problem ist. Und zwar keines von currentTimeMillis, sondern eines von Thread.sleep(). Wenn man Thread.sleep() mit "kleinen" Werten (also kleiner als 10ms) aufruft, dann driftet die Systemzeit!!! War offensichtlich schon bei 1.4 so und ist definitiv in den neuesten 1.5er-Versionen immer noch so (ich verwende die neueste 1.5er).
Das ist einigermaßen erschütternd und hebelt alle Versuche aus, eine konstante Framerate zu bekommen ohne dabei volle Systemlast zu erzeugen. So eine Kacke :autsch:  !


----------



## 0xdeadbeef (20. Feb 2006)

Es wird immer besser. Nachdem sich bereits Sleep() als Schrott-Implementierung erwiesen hat, ist jetzt doch auch noch currentTimeMillis buggy: der zurückgegebene Wert ist von Zeit zu Zeit inkonsistent und bringt damit obige Implementierung aus dem Tritt. Nach ca. 10 Minuten Spielzeit oder so springt der Wert zurück in die Vergangenheit. Dadurch friert der Bildschirm für den Differenzwert ein. Habe gerade einen Fall beim Debugging "gefangen", beim der der Timer um über 43000 Millisekunden in die Vergangenheit gesprungen ist. Also bleibt der Bidlschirm für 43 Sekunden eingefroren, bevor der Timer "t" wieder größer als der letzte gespeicherte Wert "timeBaseRepaint" wird.
Mir ist echt ein Rätsel, wie man solch elementare Funktionen derart versauen kann. In dieser Form kann man beide eigentlich nicht einsetzen...
Nur wegen currentTimeMillis muß ich jetzt wohl doch den nanoTimer aus der 1.5 benutzen, obwohl ich alle möglichen Verrenkungen gemacht habe, um mit der 1.4 kompatibel zu bleiben


----------



## EgonOlsen (20. Feb 2006)

sleep() ist sowieso niemals exakt. Es unterscheidet sich z.B. bei Single-Core-CPUs zu Dual-Core-/HT-CPUs in der minimal möglichen sleep()-Dauer, die auf Windows-Kisten noch exakt ist (10ms bei Single, 15ms bei HT/Dual-CPUs). currentTimeMillis() "sollte" aber ok sein. Bist du sicher, dass du das nicht irgendwo nach (int) castest, oder ähnliches damit anstellst?


----------



## 0xdeadbeef (20. Feb 2006)

Daß Sleep nicht exakt ist, ist eine Sache. Damit kann man leben. Daß es die Systemuhr beeinflußt, ist aber ja wohl ein ziemlicher Hammer.

Den Code für meine Hauptschleife habe ich ja oben gepostet. Sowohl "t" als auch "timeBaseRePaint" sind long und werden nie gecastet. Hatte kurz vor dem Posting den Fall, daß mein Bildschirm nicht mehr neu gezeichnet wurde. Habe also in der Routine einen Breakpoint gesetzt und folgende Werte notiert:
    timeBaseRepaint = 1140463633573
    t                        = 1140463591140
"t" ist also 42433 Inkremente kleiner als timeBase. Und zum Zeitpunkt des Debuggings waren bereits mehrere Sekunden vergangen. Das kann eigentlich nur bedeuten, daß der Timer in die Vergangenheit gesprungen ist.
Falls es nicht schlicht ein Bug ist, könnte es z.B. ein Update der Systemzeit auf einen Timeserver sein...
Das wird natürlich durch eine mittels "sleep" vertrimmte Systemzeit begünstigt...
Vermutlich ein weiterer Grund, einen "Tick"-basierten Timer zu verwenden.
Ich werde aber nochmal explizit eine Testausgabe einbauen, um die Fälle auch "live" zu fangen.

Man kann die Sprünge in die Vergangenheit natürlich durch Plausibilisierung entdecken - wenn man denn damit rechnet. Genau das mache ich jetzt als Workaround. 
Es bleibt aber das Problem, daß man durch die Inkonsistenzen eigentlich überhaupt keine Zeiten mit currentTimeMillis zuverlässig ausmessen kann, denn man weiß ja nie, wie der Timer gerade im Kreis herumhüpft.
Dazu kommt, daß man ja nicht mal genau weiß, ob der Systemtimer nicht gerade ausgeflipp ist, weil man einen Rechner erwischt hat, bei dem bereits 10/15/20 ms Sleep-Periode die Systemzeit beschleunigt wird...
Vor allem die Kombination aus beiden Effekten ist spaßig.


----------



## EgonOlsen (20. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Vermutlich ein weiterer Grund, einen "Tick"-basierten Timer zu verwenden.


Das Problem dabei ist: Auf Dual-Core-/HT-/Multi-CPU-Maschinen sind die Ticks auch nicht zwingend aufsteigend, da verschiedene Cores verschiedene Ticks liefern könnten...AMDs Dualcore-CPUs fixen dies meines Wissens nach z.B. erst in einem späteren Stepping...frühere CPUs liefern da den Wert der jeweiligen (Teil-)CPU.

P.S.: Wenn currentTimeMillis() springt, dann kann das eigentlich wirklich nur an einer externen Umstellung der Uhr liegen. Eine Möglichkeit, dem zu begegnen wäre: Ignorieren! Wenn es auftritt, tu einfach so, als wäre gar keine Zeit vergangen (oder z.B. eine Zeiteinheit). Das führt zwar zu einem leichten "Schluckauf" im Ablauf, aber wenn der nur selten vorkommt, sollte er nicht stören bzw. wahrnehmbar sein.


----------



## 0xdeadbeef (20. Feb 2006)

EgonOlsen hat gesagt.:
			
		

> 0xdeadbeef hat gesagt.:
> 
> 
> 
> ...


Auf HT-Systemen sollte das kein Problem sein und für DualCores gibt es den Fix "/usepmtimer" in die Boot.ini einzutragen ... was man auch tunlichst machen sollte (zumindest wenn man Cool'n'Quiet benutzt), denn ansonsten läuft das ganze Threadhandling von XP SP2 kreuz und quer und der Playback von diversen Mediendateien macht Probleme. Insofern würde ich das jetzt nicht als so schwerwiegendes Problem sehen. Ich habe selber ein DualCore System und schon lange den XP Hotfix für DualCores installiert, der genau die genannte Option einträgt.




> P.S.: Wenn currentTimeMillis() springt, dann kann das eigentlich wirklich nur an einer externen Umstellung der Uhr liegen. Eine Möglichkeit, dem zu begegnen wäre: Ignorieren! Wenn es auftritt, tu einfach so, als wäre gar keine Zeit vergangen (oder z.B. eine Zeiteinheit). Das führt zwar zu einem leichten "Schluckauf" im Ablauf, aber wenn der nur selten vorkommt, sollte er nicht stören bzw. wahrnehmbar sein.


Mache ich jetzt ja auch so. Allerdings muß ich noch mehrere andere Stellen anpassen, an denen ich Zeiten ausmesse und "blind" darauf vertraue, daß der "neue" Timerwert größer ist als der zuvor gespeicherte.


----------



## EgonOlsen (20. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Auf HT-Systemen sollte das kein Problem sein und für DualCores gibt es den Fix "/usepmtimer" in die Boot.ini einzutragen ...


Von HT kenne ich das auch nur gerüchteweise...halte ich auch für unwahrscheinlich. Das mit der Boot.ini ist nett, aber wer macht das schon? Man kann ja schlecht sagen: "Wenn du das hier spielen willst, frickel erstmal an der Boot.ini herum"...


----------



## MPW (21. Feb 2006)

Moin,

also bei mir springt da garnix:


```
import java.io.*;


public class TimeTaker extends Thread {
	public static void main(String args[]) {
		long l[][] = new long[10000][7];
		long summMillis = 0;
		long summNanos = 0;
		int negativCounter = 0;
		for (int c = 0; c < l.length; c++) {
			try {
				l[c][0] = System.currentTimeMillis();
				l[c][1] = System.nanoTime();
				l[c][2] = (int)(Math.random()*10);
				Thread.sleep(l[c][2]);
				l[c][3] = System.currentTimeMillis();
				l[c][4] = System.nanoTime();
				l[c][5] = l[c][3]-l[c][0];
				l[c][6] = l[c][4]-l[c][1];
				if (l[c][5] < 0) {
					negativCounter++;
				}
				if (l[c][6] < 0) {
					negativCounter++;
				}
				summMillis += l[c][5];
				summNanos += l[c][6];
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
		System.out.println("Durschnittliche Abweichung zwischen den Millis: " + summMillis/l.length);
		System.out.println("Durschnittliche Abweichung zwischen den Nanos: " + summNanos/l.length);
		System.out.println("Anzahl negativer Ergebnisse: " + negativCounter);



	}
}
```

Die Durschnittswerte stimmen bei mir bei ungefaehr bei 5 und die Anzhal negativer Abweichungen liegt bei 0.

edit: aktuellste 5er JRE und Compiler benutzt.


----------



## 0xdeadbeef (21. Feb 2006)

@EgonOlsen
Na ja, Leute die Probleme mit dem Spiel wegen hüpfendem TSC haben, werden auch Problem mit Sounddateien, Filmen, anderen Spielen usw. haben. Insofern ist das ja nicht unbedingt ein Gefrickel für ein Spiel, sondern ein systemweiter Bugfix. Und wie gesagt: wenn men den Microsoft Hotfix für DualCore-Systeme installiert, ändert der die Boot.ini, man muß also gar nicht selber frickeln, sondern nur auf den Patch verweisen. Wobei der etwa schwierig zu bekommen ist...
Außerdem tritt es wohl selbst bei Athlon DualCore Systemen nur unter bestimmten Rahmenbedingungen auf (Cool'n'Quiet aktiviert, kein HPET, TSC aktiv usw.).

@MPW:
Wie schon oben gesagt: es kann durchaus sein, daß das ein Update der Systemzeit von "außen" war. In der Firma wird die Zeit auf die Server synchronisiert, bei mir zuhause auf einen Timeserver. Die große Zeitdifferenz kam vermutlich durch die von "Sleep" verstellte Systemzeit zustande.
Das Sleep-Problem sehe ich ohnehin als den dickeren Brocken an, weil es da keinen sauberen Workarounds gibt.

Ich habe jetzt erst mal alle Timerfunktionen in eine Klasse MicrosecondTimer gepackt. Die basiert im Augenblick auf currentTimeMillis mit automatischer Plausibilisierung, aber wenn es mich packt, kann ich sie jederzeit in einen Tick-Timer ändern...


----------



## MPW (21. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> @MPW:
> Wie schon oben gesagt: es kann durchaus sein, daß das ein Update der Systemzeit von "außen" war. In der Firma wird die Zeit auf die Server synchronisiert, bei mir zuhause auf einen Timeserver. Die große Zeitdifferenz kam vermutlich durch die von "Sleep" verstellte Systemzeit zustande.
> Das Sleep-Problem sehe ich ohnehin als den dickeren Brocken an, weil es da keinen sauberen Workarounds gibt.



Du weisst aber schon, dass Timeserver die Zeit nicht ueberschreiben, sondern stueckweise anpassen, aus Sicherheitsgruenden? 43 Sec kann nie und nimmer von einem serioesen Timeserver her gekommen sein.

Ich glaube dir ausserdem nicht so wirklich, dass die sleep die Systemzeit irgendwie vorstellen soll oder sowas, das ist doch quatsch, die Funktion ist nicht sauber implementiert, dass ich allgemein bekannt, aber sie hat doch keinen Einfluss auf die Systemzeit, unter Linux kann man das glaube ich ohne Adminrechte sowieso nicht aendern und unter Windows glaube ich das trotzdem nicht, das muesste ja ins Bios geschrieben werden und ich glaube nicht....das muss eine andere Ursache haben....


----------



## Illuvatar (21. Feb 2006)

Äh hallo?

Kunde: "Ich habe folgendes Problem: ..."
Hotline: "Das glaube ich ihnen nicht" 0o


----------



## 0xdeadbeef (21. Feb 2006)

Tja, was soll man dazu sagen :roll: ?
Es ist halt schlicht und einfach so, ob Du es jetzt glaubst oder nicht. Probier's aus, recherchiere im Internet oder glaub' es  von mir aus einfach nicht. Ändert alles nichts...

Gleiches gilt für den Timerserver. Wenn ich meine Uhr unter XP von 17:59 Uhr auf 17:00 stelle und dann per "Internetzeit: jetzt aktualisieren" die Zeit von einem Zeitserver hole, wird diese sofort übernommen. Die Systemzeit springt also um 59 Minuten. Warum sollte sie also nicht um 40 Sekunden springen können??? Fakt ist: sie tut genau das.


----------



## MPW (21. Feb 2006)

Finde ich komisch, aber ist halt mal wieder einer von diesen Sicherheitsmaengeln von Windows. (Das mit dem Zeitserver)


----------



## sparrow (22. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Gleiches gilt für den Timerserver. Wenn ich meine Uhr unter XP von 17:59 Uhr auf 17:00 stelle und dann per "Internetzeit: jetzt aktualisieren" die Zeit von einem Zeitserver hole, wird diese sofort übernommen. Die Systemzeit springt also um 59 Minuten. Warum sollte sie also nicht um 40 Sekunden springen können??? Fakt ist: sie tut genau das.



Das ist richtig, der TimeServer hat mit der ganzen Geschiche auch nichts zu tun, der sendet nämlich _immer_ die jetztige, aktuelle Zeit.
Windows stellt tatsächlich direkt auf dise Zeit um während Linux dabei um einiges vorsichtiger vorgeht und diese Umstellung in kleinen "Etappen" durchgeht. Auf diese Weise wird sichergestellt, dass nicht vershentlich ein cron-job (zeitlich geplanter Lauf eines Programms) übergangen oder vergessen wird.

Ich habe gerade bei mir auf dem System mal einen Test durchlaufen lassen, zumindest hier konnte ich keine Veranderung der Systemzeit durch den Einsatz von sehr kurzen sleep-intervallen feststellen.
Die Verbindung zum Zeitserver war in dieser Zeit natürlich getrennt.
Prozessor: Intel Pentium 4 3 Ghz mit aktiven HyperThreading
Versionen:


			
				Konsole hat gesagt.:
			
		

> sparrow@spacetux:~$ cat /proc/cpuinfo
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> ...


----------



## 0xdeadbeef (22. Feb 2006)

Du hast unter Linux getestet und da ist das vermutlich kein Problem -  unter Windows aber definitiv. Es gibt dazu auch diverse Referenzen im Internet (nach "Thread.sleep() clock drift" suchen)...

Also ich habe das Problem auf einem P4 3GHz mit aktiviertem HT und einem DualCore AMD X2, wobei die Abeichung auf dem P4 wesentlich höher ist. Da kann man wirklich sehen, wie die Analoguhr vom Windows Desktop doppelt so schnell rennt, wenn man andauernd Thread.sleep(1) benutzt. Zuhause habe ich mit einer DCF77 Funkuhr verglichen und hatte unter gleichen Bedingungen einen Drift von ein paar Sekunden pro 30s. Aber auch da kann man bei den entsprechenden Sleep-Werten <= 10ms sehen, daß die Analoguhr nicht mehr konstant läuft, sondern zweimal schnell vorrückt, dann einmal langsam usw.


----------



## Illuvatar (22. Feb 2006)

Also ich konnte hier:

```
public class ClockDrift {

  public static void main(String[] args) {
     for (int i = 0; i < 100000; i++){
       try{
         Thread.sleep(1);
       }catch (Exception ex){

       }
     }
  }
}
```
auf einer halben Minute, vergleichen mit einer Funkuhr, keine Abweichung feststellen. (AMD Athlon XP 2500+; XP SP2) ???:L


----------



## 0xdeadbeef (22. Feb 2006)

Der Bug wurde in Suns Bug Batabase bereits in der 1.3er (2001) erwähnt und ist immer nicht behoben, obwohl er fälschlich auf "fixed" gesetzt wurde.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388

Gegen Ende findet man eine recht hilfreiche Analyse:


> A Java program which calls in a loop first sleep with
> 9ms and then with 10ms causes the system clock to
> run on our computer at double speed.
> The problem only occures if the HAL 'halaacpi'
> ...



Anscheinend hat das was mit dem "ACPI power management timer" zu tun und ist damit systemabhängig.


----------



## Roar (22. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Na ja, Leute die Probleme mit dem Spiel wegen hüpfendem TSC haben, werden auch Problem mit Sounddateien, Filmen, anderen Spielen usw. haben.


sorry füt OT: kann das das problem sein, dass bei mir (amd64 3400+ :? bei manchen videos das video schneller als der sound abgespielt wird? wird das behoben wenn ich ein /usepmtimer in die boot.ini einfüge :?:

danke


----------



## MPW (22. Feb 2006)

Illuvatar hat gesagt.:
			
		

> Also ich konnte hier:
> 
> ```
> public class ClockDrift {
> ...



Joa, ich hab ja auch schon einen Test gemacht, aber mir hat ja keiner geglaubt, dass die Zeit nicht driftet...ueberlegt euch das doch mal rational, um die Zeit zu veraendern, muss man ins Bios schreiben, das passiert nicht mal so ausversehen.....


----------



## 0xdeadbeef (22. Feb 2006)

MPW hat gesagt.:
			
		

> Illuvatar hat gesagt.:
> 
> 
> 
> ...



Äh? Hallo? Erstens hast Du unter Linux getestet, obwohl es ein Windows-Problem ist, zweitens habe ich gerade die Sun Bug Database und einen Artikel aus der Microsoft Knowledge Base zitiert, die das Problem nicht nur bestätigen, sondern auch die technischen Hintergründe erläutern.
Und obwohl das mit dem Thema sowieso nichts zu tun hat: warum man ins BIOS schreiben können muß, um die Uhrzeit zu ändern, bleibt wohl auch Dein Geheimnis...


----------



## 0xdeadbeef (22. Feb 2006)

Roar hat gesagt.:
			
		

> 0xdeadbeef hat gesagt.:
> 
> 
> 
> ...


Eher nicht. Das TSC-Problem sollte eigentlich nur bei DualCores (X2) auftreten, nicht bei normalen AMD64ern.


----------



## MPW (23. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Äh? Hallo? Erstens hast Du unter Linux getestet, obwohl es ein Windows-Problem ist, zweitens habe ich gerade die Sun Bug Database und einen Artikel aus der Microsoft Knowledge Base zitiert, die das Problem nicht nur bestätigen, sondern auch die technischen Hintergründe erläutern.
> Und obwohl das mit dem Thema sowieso nichts zu tun hat: warum man ins BIOS schreiben können muß, um die Uhrzeit zu ändern, bleibt wohl auch Dein Geheimnis...



Immer schon auf dem Teppich der Fakten bleiben, *ich habe unter Windows getestet*.

Das mit dem Bios war dann wohl ein Irrtum meinerseits, aber der Kollege ueber mir hat ja schon wieder gesagt, dass das doch nicht stimmt und nur bei DualCore auftritt.


----------



## Roar (23. Feb 2006)

0xdeadbeef hat gesagt.:
			
		

> Roar hat gesagt.:
> 
> 
> 
> ...


merkwürdig, dann liegts wohl an was anderem, danke.


----------



## 0xdeadbeef (23. Feb 2006)

MPW hat gesagt.:
			
		

> Das mit dem Bios war dann wohl ein Irrtum meinerseits, aber der Kollege ueber mir hat ja schon wieder gesagt, dass das doch nicht stimmt und nur bei DualCore auftritt.


Der "Kollege" war ich und die Antwort bezog sich auf eine ganz andere Frage  :roll:


----------

