FORTS. Questions relatives à l'application de la loi - page 10

 
Renat:

Les dates de début et de fin doivent être fixées en tenant compte des erreurs possibles et en prévoyant une marge obligatoire. C'est-à-dire moins N secondes et plus N secondes au minimum.

TimeTradeServer() n'est pas une heure exacte, mais est mis à jour uniquement par les ticks de prix entrant dans l'aperçu du marché.


Si vous n'avez soudainement aucune donnée dans l'échantillon historique, cela signifie que 99 % de l'erreur se trouve dans les limites de la requête.

Étrange, mais dans l'aide, il est indiqué que TimeTradeServer -Renvoie l'heure actuelle estimée du serveur de commerce.

mais TimeCurrent() - Renvoie la dernière heure connue du serveur, l'heure d'arrivée de la dernière cotation par un des symboles sélectionnés dans Market Watch.

 

Enfin, Discovery a publié une démo (partie serveur 1060).

Renat, je tiens à vous féliciter, vous et votre équipe, pour votre bon travail.

Si le réel fonctionne aussi bien que sur Demo, c'est un grand progrès !

Avez-vous réussi à réparer l'incompréhensible retard unique ?

Désolé de vous " torturer ", mais l'essentiel est le résultat !

 

Oui, cela a réussi dans une large mesure dans la nouvelle version, qui sera publiée ce vendredi.

Le travail d'optimisation est toujours en cours. Maintenant, nous nous battons pour des microsecondes.

 
Renat:

Oui, cela a réussi dans une large mesure dans la nouvelle version, qui sera publiée ce vendredi.

Le travail d'optimisation est toujours en cours. Maintenant, nous nous battons pour des microsecondes.

C'est bon à entendre (mks) - "baume pour l'âme" :)

Bonne chance !

 

Bonjour, Renat !

Dans servicedex, depuis longtemps maintenant (2 nouvelles versions ont été publiées), ma plainte est "le mensonge",

sur la suppression des variables globales du terminal.

Ce bogue n'a pas encore été résolu.

Le Service Desk ne répond pas.

Pouvez-vous me dire quand la correction de ce bogue est prévue ?

 

Bonjour, Renat !

Vous avez dit que dans la version 1085 vous avez corrigé le bug du délai "unique".

Mais vous pouvez voir sur la capture d'écran que ce n'est pas le cas.

P/S Peut-être pourriez-vous envisager d'introduire une fonction ServerInfoInteger( SERVER_BUILD ) ?

Après tout, ce n'est pas comme si c'était une information secrète.

 
Mikalas:

Bonjour, Renat !

Vous avez dit que dans la version 1085 vous avez corrigé le bug du délai "unique".

Mais vous pouvez voir sur la capture d'écran que ce n'est pas le cas.

La version 1085 est sur votre ordinateur. Et quelle version de la partie serveur se trouve à l'organisation commerciale, l'avez-vous découvert ? Ou est-ce que vous vous précipitez dans le combat sans le savoir ?
 
barabashkakvn:
La version 1085 est sur votre ordinateur. Et quelle version du côté serveur utilise l'organisation de vente au détail, l'avez-vous découvert ? Ou est-ce que vous vous précipitez dans le combat sans le savoir ?

Je ne me jette pas dans la mêlée, ma chère, je demande juste.....

P/S Et si vous n'aviez pas demandé, nous serions tous assis avec une latence de 300 ms - au lieu des 8 ms actuelles.

 
Mikalas:

Je ne me jette pas dans la mêlée, ma chère, je demande juste.....

P/S Et si vous n'aviez pas demandé, nous serions tous assis avec une latence de 300ms - au lieu des 8ms actuels.

Le problème est que leur serveur réel est toujours à 1035, alors que la démo est passée à 1060. Toutes les améliorations de la latence dépendent de l'infrastructure du serveur, et non du terminal client.

Attendez la version 1085 sur le marché réel - vous verrez des améliorations étonnantes.

 
Renat:

Le problème, c'est que leur serveur réel est toujours en 1035 à ce jour, mais que la démo est passée en 1060. Toutes les améliorations de la latence dépendent de l'infrastructure du serveur, et non du terminal client.

Attendez la version 1085 sur le marché réel - vous verrez des améliorations étonnantes.

Merci beaucoup !
Raison: