Je dois faire des mesures d'intervalle de temps qui doivent être insensibles
à la modification de la date système. Actuellement j'utilise une méthode
'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel
système renvoie le nombre de millisecondes écoulé depuis le démarrage de la
machine, et il ne varie pas lorsqu'on change la date système. Je préférerais
pourtant utiliser une méthode plus portable et, pour l'instant, je ne
connais que la méthode currentTimeMillis de la classe System. Cette méthode
ne me va pas du tout car son résultat est modifié en fonction de la date
système - c'est même la date système. Est-ce que quelqu'un aurait une idée ?
Suis-je trop bigleux lorsque je lis la doc ?
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une
bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne
trouve pas dans la doc ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Bruno
dans l'article bkrl9j$s32$, narberd à a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
Actuellement j'utilise une méthode 'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel système renvoie le nombre de millisecondes écoulé depuis le démarrage de la machine, et il ne varie pas lorsqu'on change la date système.
pas portable
Je préférerais pourtant utiliser une méthode plus portable et, pour l'instant, je ne connais que la méthode currentTimeMillis de la classe System. Cette méthode ne me va pas du tout car son résultat est modifié en fonction de la date système - c'est même la date système. Est-ce que quelqu'un aurait une idée ? Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne trouve pas dans la doc ?
Merci d'avance,
de rien
Narberd.
-- Bruno Causse http://perso.wanadoo.fr/othello
dans l'article bkrl9j$s32$1@news-reader5.wanadoo.fr, narberd à
tatin.dsatec@wanadoo.fr a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
Actuellement j'utilise une méthode
'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel
système renvoie le nombre de millisecondes écoulé depuis le démarrage de la
machine, et il ne varie pas lorsqu'on change la date système.
pas portable
Je préférerais
pourtant utiliser une méthode plus portable et, pour l'instant, je ne
connais que la méthode currentTimeMillis de la classe System. Cette méthode
ne me va pas du tout car son résultat est modifié en fonction de la date
système - c'est même la date système. Est-ce que quelqu'un aurait une idée ?
Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une
bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne
trouve pas dans la doc ?
dans l'article bkrl9j$s32$, narberd à a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
Actuellement j'utilise une méthode 'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel système renvoie le nombre de millisecondes écoulé depuis le démarrage de la machine, et il ne varie pas lorsqu'on change la date système.
pas portable
Je préférerais pourtant utiliser une méthode plus portable et, pour l'instant, je ne connais que la méthode currentTimeMillis de la classe System. Cette méthode ne me va pas du tout car son résultat est modifié en fonction de la date système - c'est même la date système. Est-ce que quelqu'un aurait une idée ? Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne trouve pas dans la doc ?
Merci d'avance,
de rien
Narberd.
-- Bruno Causse http://perso.wanadoo.fr/othello
narberd
"Bruno" a écrit dans le message news: BB97319C.AD1B%
dans l'article bkrl9j$s32$, narberd à a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
parce que je suis un utilisateur maladroit ... Plus sérieusement, le comptage de temps, s'il n'a pas besoin d'une précision à la milliseconde, il doit être "régulier" et insensible à toute variation du système. Lorsqu'un utilisateur intempestif et ponctuel compare l'heure système avec celle de sa montre ou de sa radio, plein de bonne volonté il remet le PC à la bonne heure.
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
donc ce système ne marche pas car mon application ne sait pas que Raymond
Ponctuel vient de modifier la date et l'heure.
Actuellement j'utilise une méthode 'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel
système renvoie le nombre de millisecondes écoulé depuis le démarrage de la
machine, et il ne varie pas lorsqu'on change la date système.
pas portable
ben ouais, cependant, c'est pas un grand boulot de faire un portage vers un Unix quelconque.
Je préférerais pourtant utiliser une méthode plus portable et, pour l'instant, je ne connais que la méthode currentTimeMillis de la classe System. Cette méthode
ne me va pas du tout car son résultat est modifié en fonction de la date système - c'est même la date système. Est-ce que quelqu'un aurait une idée ?
Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
currentTimeMillis est la date système exprimée en millsecondes depuis le 01/01/1970 (je crois). Juste avant la modif de la date système, il me renvoie T. J'avance l'heure du PC depuis 12:00 à 12:05 avec les bêtes outils de base de Windows (l'horloge de la barre des tâches), j'ajoute 5 minutes, donc après mon intervention, currentTimeMillis me renvoie T + 5 * 60 * 1000. Cette manipulation n'a pas durée 5 minutes, mais au plus (après le click sur le bouton OK) quelques millisecondes. Je mesure pourtant un intervalle de temps de 5 minutes, ce qui est faux. C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x millisecondes (ça doit dépendre du PC) indépendament de toute date et heure système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par une dll.
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une
bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne trouve pas dans la doc ?
J'aimerais faire un changement de date/heure depuis Java pour, entre autre, me soumettre à une horloge externe - pas forcément un PC. Actuellement, je fais la manip depuis ma dll. Java veut pas m'aider un peu ?
Narberd.
"Bruno" <bcausse@lepoint.tm.fr> a écrit dans le message news:
BB97319C.AD1B%bcausse@lepoint.tm.fr...
dans l'article bkrl9j$s32$1@news-reader5.wanadoo.fr, narberd à
tatin.dsatec@wanadoo.fr a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
parce que je suis un utilisateur maladroit ... Plus sérieusement, le
comptage de temps, s'il n'a pas besoin d'une précision à la milliseconde, il
doit être "régulier" et insensible à toute variation du système. Lorsqu'un
utilisateur intempestif et ponctuel compare l'heure système avec celle de sa
montre ou de sa radio, plein de bonne volonté il remet le PC à la bonne
heure.
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
donc ce système ne marche pas car mon application ne sait pas que Raymond
Ponctuel vient de modifier la date et l'heure.
Actuellement j'utilise une méthode
'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet
appel
système renvoie le nombre de millisecondes écoulé depuis le démarrage de
la
machine, et il ne varie pas lorsqu'on change la date système.
pas portable
ben ouais, cependant, c'est pas un grand boulot de faire un portage vers un
Unix quelconque.
Je préférerais
pourtant utiliser une méthode plus portable et, pour l'instant, je ne
connais que la méthode currentTimeMillis de la classe System. Cette
méthode
ne me va pas du tout car son résultat est modifié en fonction de la date
système - c'est même la date système. Est-ce que quelqu'un aurait une
idée ?
Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
currentTimeMillis est la date système exprimée en millsecondes depuis le
01/01/1970 (je crois). Juste avant la modif de la date système, il me
renvoie T. J'avance l'heure du PC depuis 12:00 à 12:05 avec les bêtes outils
de base de Windows (l'horloge de la barre des tâches), j'ajoute 5 minutes,
donc après mon intervention, currentTimeMillis me renvoie T + 5 * 60 * 1000.
Cette manipulation n'a pas durée 5 minutes, mais au plus (après le click sur
le bouton OK) quelques millisecondes. Je mesure pourtant un intervalle de
temps de 5 minutes, ce qui est faux. C'est pour cela que le GetTickCount de
Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x
millisecondes (ça doit dépendre du PC) indépendament de toute date et heure
système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par
une dll.
Ensuite, il me faut modifier la date système. Suis-je obligé de faire
une
bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne
trouve pas dans la doc ?
J'aimerais faire un changement de date/heure depuis Java pour, entre autre,
me soumettre à une horloge externe - pas forcément un PC. Actuellement, je
fais la manip depuis ma dll. Java veut pas m'aider un peu ?
"Bruno" a écrit dans le message news: BB97319C.AD1B%
dans l'article bkrl9j$s32$, narberd à a écrit le 24/09/2003 10:40 :
Bonjour,
Je dois faire des mesures d'intervalle de temps
une soustraction de date :)
qui doivent être insensibles à la modification de la date système.
pourquoi entre le debut et la fin de la mesure tu modifis la date systeme?
parce que je suis un utilisateur maladroit ... Plus sérieusement, le comptage de temps, s'il n'a pas besoin d'une précision à la milliseconde, il doit être "régulier" et insensible à toute variation du système. Lorsqu'un utilisateur intempestif et ponctuel compare l'heure système avec celle de sa montre ou de sa radio, plein de bonne volonté il remet le PC à la bonne heure.
dans ce cas on peut toujours faire des additions de date
intervale totale = intervale avant modif + intervale apres modif :)
donc ce système ne marche pas car mon application ne sait pas que Raymond
Ponctuel vient de modifier la date et l'heure.
Actuellement j'utilise une méthode 'native' d'une dll à moi qui appelle GetTickCount sous Windows. Cet appel
système renvoie le nombre de millisecondes écoulé depuis le démarrage de la
machine, et il ne varie pas lorsqu'on change la date système.
pas portable
ben ouais, cependant, c'est pas un grand boulot de faire un portage vers un Unix quelconque.
Je préférerais pourtant utiliser une méthode plus portable et, pour l'instant, je ne connais que la méthode currentTimeMillis de la classe System. Cette méthode
ne me va pas du tout car son résultat est modifié en fonction de la date système - c'est même la date système. Est-ce que quelqu'un aurait une idée ?
Suis-je trop bigleux lorsque je lis la doc ?
precises pourquoi currentTimeMillis ne te va pas
currentTimeMillis est la date système exprimée en millsecondes depuis le 01/01/1970 (je crois). Juste avant la modif de la date système, il me renvoie T. J'avance l'heure du PC depuis 12:00 à 12:05 avec les bêtes outils de base de Windows (l'horloge de la barre des tâches), j'ajoute 5 minutes, donc après mon intervention, currentTimeMillis me renvoie T + 5 * 60 * 1000. Cette manipulation n'a pas durée 5 minutes, mais au plus (après le click sur le bouton OK) quelques millisecondes. Je mesure pourtant un intervalle de temps de 5 minutes, ce qui est faux. C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x millisecondes (ça doit dépendre du PC) indépendament de toute date et heure système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par une dll.
Ensuite, il me faut modifier la date système. Suis-je obligé de faire une
bistouille par dll interposée ou y-a-t-il un moyen sans dll et que je ne trouve pas dans la doc ?
J'aimerais faire un changement de date/heure depuis Java pour, entre autre, me soumettre à une horloge externe - pas forcément un PC. Actuellement, je fais la manip depuis ma dll. Java veut pas m'aider un peu ?
Narberd.
Bruno
dans l'article bkrqbu$da7$, narberd à a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x millisecondes (ça doit dépendre du PC) indépendament de toute date et heure système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
si ok implementé un thread prioritaire "compteur de temps"
mais ce n'est pas trop top -- Bruno Causse http://perso.wanadoo.fr/othello
dans l'article bkrqbu$da7$1@news-reader5.wanadoo.fr, narberd à
tatin.dsatec@wanadoo.fr a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de
Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x
millisecondes (ça doit dépendre du PC) indépendament de toute date et heure
système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par
une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
si ok implementé un thread prioritaire "compteur de temps"
mais ce n'est pas trop top
--
Bruno Causse
http://perso.wanadoo.fr/othello
dans l'article bkrqbu$da7$, narberd à a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x millisecondes (ça doit dépendre du PC) indépendament de toute date et heure système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
si ok implementé un thread prioritaire "compteur de temps"
mais ce n'est pas trop top -- Bruno Causse http://perso.wanadoo.fr/othello
narberd
"Bruno" a écrit dans le message news: BB9742C7.AD34%
dans l'article bkrqbu$da7$, narberd à a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x
millisecondes (ça doit dépendre du PC) indépendament de toute date et heure
système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par
une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
Au vu de mes expérimentations, s'il l'était j'aurais eu - je pense - beaucoup plus de problèmes. Je vais quand même le vérifier.
si ok implementé un thread prioritaire "compteur de temps"
J'y ai pensé. Ce qui m'a freiné dans son utilisation c'est qu'un notifyAll maladroit peut l'en faire sortir trop tôt. Ensuite, et c'est aussi pour cela que je n'ai pas utilisé non plus sleep, sur un système très chargé, lorsque j'en sors est-ce que j'ai bien laissé passer mes 100 ms ou un peu plus ? En fin de journée, cela risque d'être extrêmement pénalisant sur certains calculs d'intervalles de temps.
En fait, c'est une solution que j'avais essayé - pour d'autres raisons - avec un Lisp et que j'avais abandonné car, même si la précision demandée n'est pas énorme, elle est largement insuffisante avec ce genre de solution. Par exemple, lors de fortes sollicitations du système, avec un compteur mis à jour toutes les 20 ms, sur des intervalles de 1 seconde (mesuré avec l'horloge système) le compteur indiquait moins de 800 millisecondes. Cela signifie que j'ai raté plus de 10 incrémentations du compteur. Ou qu'au lieu de dormir pendant 20 ms, le thread dormait plus de 30 millisecondes. C'est pour cela que je ne me suis pas empressé de l'utiliser.
mais ce n'est pas trop top -- Bruno Causse http://perso.wanadoo.fr/othello
Narberd.
"Bruno" <bcausse@lepoint.tm.fr> a écrit dans le message news:
BB9742C7.AD34%bcausse@lepoint.tm.fr...
dans l'article bkrqbu$da7$1@news-reader5.wanadoo.fr, narberd à
tatin.dsatec@wanadoo.fr a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de
Windows est une bonne chose. Le compteur est en fait incrémenté toutes
les x
millisecondes (ça doit dépendre du PC) indépendament de toute date et
heure
système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer
par
une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
Au vu de mes expérimentations, s'il l'était j'aurais eu - je pense -
beaucoup plus de problèmes. Je vais quand même le vérifier.
si ok implementé un thread prioritaire "compteur de temps"
J'y ai pensé. Ce qui m'a freiné dans son utilisation c'est qu'un notifyAll
maladroit peut l'en faire sortir trop tôt. Ensuite, et c'est aussi pour cela
que je n'ai pas utilisé non plus sleep, sur un système très chargé, lorsque
j'en sors est-ce que j'ai bien laissé passer mes 100 ms ou un peu plus ? En
fin de journée, cela risque d'être extrêmement pénalisant sur certains
calculs d'intervalles de temps.
En fait, c'est une solution que j'avais essayé - pour d'autres raisons -
avec un Lisp et que j'avais abandonné car, même si la précision demandée
n'est pas énorme, elle est largement insuffisante avec ce genre de solution.
Par exemple, lors de fortes sollicitations du système, avec un compteur mis
à jour toutes les 20 ms, sur des intervalles de 1 seconde (mesuré avec
l'horloge système) le compteur indiquait moins de 800 millisecondes. Cela
signifie que j'ai raté plus de 10 incrémentations du compteur. Ou qu'au lieu
de dormir pendant 20 ms, le thread dormait plus de 30 millisecondes. C'est
pour cela que je ne me suis pas empressé de l'utiliser.
mais ce n'est pas trop top
--
Bruno Causse
http://perso.wanadoo.fr/othello
"Bruno" a écrit dans le message news: BB9742C7.AD34%
dans l'article bkrqbu$da7$, narberd à a écrit le 24/09/2003 12:08 :
C'est pour cela que le GetTickCount de Windows est une bonne chose. Le compteur est en fait incrémenté toutes les x
millisecondes (ça doit dépendre du PC) indépendament de toute date et heure
système.
J'aurais espéré que Java puisse me donner une telle valeur sans passer par
une dll.
une idee a verifier
wait(long) est il independent de la date systeme?
Au vu de mes expérimentations, s'il l'était j'aurais eu - je pense - beaucoup plus de problèmes. Je vais quand même le vérifier.
si ok implementé un thread prioritaire "compteur de temps"
J'y ai pensé. Ce qui m'a freiné dans son utilisation c'est qu'un notifyAll maladroit peut l'en faire sortir trop tôt. Ensuite, et c'est aussi pour cela que je n'ai pas utilisé non plus sleep, sur un système très chargé, lorsque j'en sors est-ce que j'ai bien laissé passer mes 100 ms ou un peu plus ? En fin de journée, cela risque d'être extrêmement pénalisant sur certains calculs d'intervalles de temps.
En fait, c'est une solution que j'avais essayé - pour d'autres raisons - avec un Lisp et que j'avais abandonné car, même si la précision demandée n'est pas énorme, elle est largement insuffisante avec ce genre de solution. Par exemple, lors de fortes sollicitations du système, avec un compteur mis à jour toutes les 20 ms, sur des intervalles de 1 seconde (mesuré avec l'horloge système) le compteur indiquait moins de 800 millisecondes. Cela signifie que j'ai raté plus de 10 incrémentations du compteur. Ou qu'au lieu de dormir pendant 20 ms, le thread dormait plus de 30 millisecondes. C'est pour cela que je ne me suis pas empressé de l'utiliser.
mais ce n'est pas trop top -- Bruno Causse http://perso.wanadoo.fr/othello
Narberd.
narberd
Et là je dis merci, parce que je l'ai pas encore dis. Même si je n'ai pas mes réponses, ça me fait travailler les méninges autrement.
Alors, merci.
Narberd
Et là je dis merci, parce que je l'ai pas encore dis. Même si je n'ai pas
mes réponses, ça me fait travailler les méninges autrement.
