Les tics sont toctocs

Tu as raison, il faut également vérifier la qualité des bougies reçues.
Mais comme on change d'échelle et qu'il y a beaucoup moins de données dans le cas des bougies, ça devrait aller.
Dès que je peux, je ferais ces tests.

Dans mon cas, le FCE avait atteind mon Stop, mais pas le flux ig, donc le système de suivi des position a fait son boulot alors que la partie tick/flux/graphe, (je ne sais pas comment ig gère cette partie) a décide de squeezer/ne pas enviyer des bougies.
Donc entre le graphes que j'avais sous les yeux et la réalité du trade j'avais un écart. C'est tout.
Tout ça pour dire qu'il ne faut surtout pas prendre les bougies d'ig comme étant 100% fiable. Mon propos s'arrête là.

Phrase que l'on pourrait appliquer à 100% des brocker/fournisseur de flux.

Je maintiens donc qu'il est décevant que les 4 infos d'historique nécessaires à la construction des bougies ne soient pas fiables : je ne comprends pas quelle limitation technique peut être derrière.

Je peux t'en donner une toute simple :

Les serveurs d'ig sont Akamaïsé, donc en fonction de ton opérateur local et du "peering" entre celui-ci et Akamaï tu n'auras pas les mêmes performance d'accès à ig.

ça va se jouer entre 0,1 et 10ms.

---

APrès si on réchléchit Architecture IT chez ig :
Grosso modo on sait (ou on se doute) que :
1) ig est connecté chez NYSE, Eurex, LIFE, CME, CBOT, ... et toute une série de plateforme comme CHIX BATS pour récupérer et agreger les flux.
2) ils doivent en permanence faire un calcul de spread entre le sous-jacent et ce qu'il vont proposer à leur client
3) tu imagines un système de BdD au milieux pour faire un minimum de stockage
4) puis toute une archi de push dudit flux.
4') une autre arhcitecture va gerer les trades en allant piocher dans le flux (lequel ? en tout cas pas celui qui est poussé vers les clients)
Tu consolides tout ça, tu externalises "all around the world" ...

Et tu comprendras très facilement que le niveau de flux que nous avons en face pour un coût presque nulle est d'une qualité dingue. Je ne suis pas sur que nombre de pro ai un flux aussi riche ...

Je ne sais pas combien de serveurs ils doivent gérer mais ça doit bien se conpter en Milier réparti entre l'Europe, les USA et l'asie.

Merci Falex pour ces pistes de réflexions. Ceci dit, la taille est aussi une économie d'échelle, et surtout ton point 3) mentionne une BdD qui stock en principe toutes les valeurs de ticks auxquels des trades client ont pu être exécutés. Il semble trivial au programmeur du dimanche que je suis de faire une requête pour extraire de cette BdB les 4 points "extrêmes" qui vont construire la Bougie... Mais j'admets volontiers que le programmeur du dimanche ignore bien des aspects liés aux problématiques de charge des serveurs, etc.

Oui, tout cela est très complexe et les tests ne sont pas là pour alimenter une critique simpliste.
Il s'agit simplement de bien connaître les limites de cet environnement pour mieux adapter nos outils et nos stratégies.

Il s'agit simplement de bien connaître les limites de cet environnement pour mieux adapter nos outils et nos stratégies.

Tu as mille fois raison takapoto.
J'espère que cette file ne va pas dériver vers une litanie larmoyante envers et contre ig avec son concert habituel de pleureuses, mais restera une analyse la plus pragmatique possible de la situation et de ce que nous pouvons attendre des api.

Par exemple, depuis 9h, il y a une différence de 30 points entre les cours CAC démo et réel.

Actuellement :
Démo : 4770 avec un spread de 5
Réel : 4803 avec un spread de 1

Edit :
Vers 11h00, tout est rentré dans l'ordre.

Spoiler:

C'est utile de constater ce genre de chose quand on écrit un outil de récupération des cours...

plataxis, si le système qui intégre et "créer" le cours ig décide de ne retenir que une Bougie sur trois, et quelle celle retenue n'est pas la plus haute, alors la Bougie que je vais recevoir va être tronqué.

Dans mon cas précis, l'erreur vient de l'écretage du sytème avant la partie stockage et push vers moi.

Rien n'est "simple" en IT, et si c'était simple des boites comme Atos, Capgemini ou Steria n'existerai pas.

Bien d'accord avec les pleureuses alors que c'est un travail précis et de qualité que vous êtes en train de faire. Comme je le disais même un flux pro renommé CQG coûtant 2000€ par an / trader (100.000€ par an pour le Hedge Fund) m'a fait la semaine dernière le même chose que falex. Exécuté et pas visible sur le graphique.

Pour info Numericable Tours visiblement 29 30 ms avec Akamai (2 connexions fibres différentes localisées sur deux centraux différents donnent ces résultats). Orange vdsl2+ 9 ms (technologie inférieure normalement à la fibre). Voilà comment Numericable fait des économies. Prochain déménagement sur Tours aussi près du central mais avec la fibre d'Orange là impossible accord pour l'immeuble

De mes tests (somme toute très empirique) je dirais que c'est SFR qui est le plus "près" d'Akamai.

Après Orange et Free = mouchoir de poche

NC et Bougyges : pas testé.

Tours est cablé en FTTH par orange, après est-ce que SFR ou Free y ont déployé leur fibre ? aucue idée.
Quand un immeuble est raccordé il y a une plaque signalétique en pied d'immeuble (souvent près des BaL), "Votre immeuble est raccordé au r&éseau fibre d'Orange" ou un truc comme ça. Je ne sais pas sir SFR et Free pose le même de genre.

Le mieux c'est de prendre l'adresse de l'immeuble et d'aller sur un site et de voir quel(s) opérateur est/sont présent(s) en FTTH dans l'immeuble.

---

Tiens je viens de refaire le test avec un immeuble qui a Orange, SFR, Free en FTTH et NC en FTTB.
Alros Free ne fait plus partie des sites d'eligibilité. donc faut tester sur leur propres sites.
Pour SFR, c'est le méga basard car comme il priviligie les raccordement via le cable je ne sais pas si pour mon adresse "test" il serait possible de demander un raccordement FTTH et non FTTB ...

J'ai un copain qui est chez NC fibre à Tours actuellement (même résultat que moi) et il va pouvoir basculer sur Orange dans quelques temps, dès qu'il peut c'est en cours dans sa rue. On pourra avoir un comparatif puisqu'en plus il reste au même endroit !

Bonsoir -,

Très intéressant ce que tu as écrit. Cela mérite une réponse précise et détaillée.

...

Et bien dans mon cas je dirais, pas tout à fait. C'est oui et non, ma réponse. Mais je ne veux pas rentrer dans les détails.

...

... Mais sur ce sujet je ne peux vraiment pas continuer à développer, car on risque être borderline.

... etc...
La tournure que prend ce fil me déplaît. Pour tout dire, j'ai vraiment du mal à te suivre. On dirait que tu ramènes tout à toi et que tu en fais une affaire personnelle. Franchement, je n'ai ni le temps ni l'envie de polémiquer, et surtout je n'en vois pas l'intérêt. J'en suis à regretter d'avoir précisé que c'est suite à tes posts du nombre de ticks quotidiens que je me suis posé des questions, non pas sur ta personne ou tes méthodes, mais sur ce qu'est la notion de flux de ticks obtenus par les api.

Donc pour ma part je refuse de me lancer dans tel un débat, de peur qu'il ne tourne au vinaigre. Je préfère rester avec un goût de bon vin dans le gosier, surtout une année exceptionnelle où même le beaujolais nouveau est presque bon, et ce serait avec plaisir que je trinquerais avec toi.

Bref bilan de la journée du 07/12 des ticks collectés avec les api sur le dax (mode chart).
Les ticks sont récupérés par 6 connexions : 3 en mode réel et 3 en mode démo, avec à chaque fois le dax mini lots et le dax lots pleins.
Les codes 1 2 3 correspondent à :
1 et 2 : programmes qui tournent en // sur le même serveur, donc la même ip mais avec des connexions à lightstreamer séparées. Serveur très peu chargé.
3 : programme qui tourne sur un autre serveur, avec une autre ip. Donc connexion complètement indépendante de 1 et 2. Ce serveur est plus sollicité, mais il est costaud (6 coeurs, 12go de mémoire, disque ssd).
Ces 2 serveurs ont une bonne connectivité réseau (ping de 3ms vers ig.com).

Résultats bruts pour la période 8h 22h en heures de france:
1/real/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74199 ticks : min=10804.5 max=10993.3
2/real/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74218 ticks : min=10804.5 max=10993.3
3/real/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74036 ticks : min=10804.5 max=10993.3

1/real/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 58215 ticks : min=10805 max=10993.3
2/real/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 58161 ticks : min=10805 max=10993.3
3/real/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 58096 ticks : min=10805 max=10993.3

1/demo/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74028 ticks : min=10804.5 max=10993.3
2/demo/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74242 ticks : min=10804.5 max=10993.3
3/demo/DAXmini_2015-12-07.txt: 07:00-20:59 UTC : 74296 ticks : min=10804.5 max=10993.3

1/demo/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 57607 ticks : min=10805 max=10993.3
2/demo/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 57232 ticks : min=10805 max=10993.3
3/demo/DAXfull_2015-12-07.txt: 07:00-20:59 UTC : 56999 ticks : min=10805 max=10993.3

Conclusion sommaire : le nombre de ticks varie d'une connexion à l'autre, et surtout il y a beaucoup plus de ticks sur le dax mini lots que sur le dax lots pleins, et ça vraiment ça me surprend.
Je n'ai pas le temps ce soir de détailler plus.

Oui je vois que ca carie de 200 à 600 ticks.
Quel FAI derrière chaque serveur ?

Peut-être est-ce dû au fait que entre le mini et le plein il y a plus d'échange sur le mini et que cette diffèrence s'explique, peut-être ?, par le fait que nous voyons les transactions cfd à risque limité en plus des mouvements du fdax ?

Maintenant ce qui m'intéressait, ce serait de voir sur les hauts et les bas sont les mêmes.

---

-, je rejoins jized, le début de ta dernière réponse me laisse sans voix... Soit tu développes soit tu ne dis rien

@falex : les serveurs avec un ping de 3ms sont hébergés chez 1and1

Petit bilan du 08/12/2015

Aujourd'hui j'ai refait le même genre d'essais, mais sur un autre réseau, avec un ping vers ig qui oscille entre 18 et 20 ms, uniquement pendant 3 heures car je ne suis pas sensé me servir de ce serveur pour des trucs perso :roll:

Le constat est exactement le même qu'hier : le nombre de ticks varie un peu selon les connexions, et surtout il y a beaucoup plus de ticks sur le dax mini que sur le dax plein, et les ticks qui coïncident sont séparés de quelques ms (très peu).

Entre 11h40 et 13h40, sur un compte réel avec les api, il y a eu :
DAX mini : 18735 ticks
DAX plein : 14080 ticks

En images :
A grande échelle, les 2 courbes se superposent pas mal (heureusement) :

zoom1.png (58.42 Kio) Vu 712 fois

Mais en zoomant, c'est une autre histoire :

zoom2.png (57.56 Kio) Vu 712 fois

Il y a un pic à 10810 à 11h10'51.917" UTC sur le dax mini, alors que le dax plein a plafonné à 10809.2.
En faisant défiler les courbes on en trouve plein d'autres, mais j'ai la flemme de chercher le plus fort décalage.

Je joins les fichiers de ticks de ces 3 heures pour les curieux.
Format des lignes : heure_UTC bid spread

./download/file.php?id=28846&sid=102b2fc6ccf6374a7873f62eef955e63

(165.33 Kio) Téléchargé 361 fois

Ce ne sont que des constats. Chacun en tire les conclusions qu'il veut.

Pour info ig réplique les cours des futures.

Depuis quelques mois il existe un futures dax lots pleins et mais aussi un futures dax mini lots qui a fait son apparition donc deux cours differents.

Ils ne varient pas pareil sur futures car c'est un Carnet d'ordres et leur pas de cotation ne sont pas les mêmes doc il n'y a pas le même nombre de ticks et les hauts bas pas les mêmes. Même chose sur cac dow nasdaq etc le Dax était l'un des rares indices (le dernier ?) à ne pas avoir de mini

Donc tu as deux cours légèrement differents sur futures donc tu les retrouves sur cfds à risque limité. Normal. ig réplique le sous jacent futures.