Archives par mot-clé : TO2TT

DX, HAM Radio, Propagation

Retour d’une bonne propagation avec l’automne

Bien que je sois pas mal pris ces derniers jours avec la visite de mes parents et l’arrivée d’un groupe de 10 personnes composés d’oncle et tante et d’amis de la famille, j’ai réussi à placer un peu de temps pour la radio.

Capture carte WSPR XV4Y 40 mètres (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2013/10/XV4Y_WSPR_40m_15102013 NULL.png)Tout d’abord j’ai vu les conditions sur la bande des 40 mètres s’améliorer peu à peu après la dernière tempête solaire et plusieurs stations NA recevoir mes signaux. La nuit dernière c’était au tour de l’Europe de faire son retour avec une dizaine de stations annonçant la réception des 500mW de ma balise WSPR autonome. 10 stations cela peut paraître faible mais le nombre de participants sur la bande 40 mètres et très très limité en comparaison des bandes 30 mètres et 20 mètres. Je vais pour les nuits suivantes mettre la balise sur 30 mètres et ensuite la replacer sur la bande des 80 mètres pour en étudier la propagation ce qui est son objectif principal.

Ensuite, j’ai aussi pu faire quelques QSOs assez attendus comme celui sur 12 mètres avec Dimitri TU5DF (http://www NULL.qrz NULL.com/db/TU5DF) hier. Cela faisait plusieurs jours que je chaque fois que je le voyais annoncé sur le DX cluster j’allais jeter une oreille sur la bande, sans vraiment de succès. Nous avions discuté par e-mail au sujet de QScope (http://www NULL.qscope NULL.org/) et lui aussi espérait bien pouvoir compter le Viêt-Nam dans la liste de ses contrées DXCC. Hier en soirée je faisais donc une petite pause pour écouter un peu la bande et pour une fois TU5DF arrivait suffisamment fort pour espérer un QSO. Le pile-up était assez large (environ 4 KHz) et la concurrence rude, mais Dimitri faisait tourner son VFO suffisamment souvent pour entendre aussi les stations faibles, et il a donc reconnu mon indicatif au bout de quelques minutes d’appel de ma part. Par malchance, juste à ce moment le QSB devint plus fort et par 3 fois je n’ai pas entendu mon indicatif complet et je n’étais pas sûr qu’il avait bien la dernière lettre. J’ai donc du le faire répéter et “casser son rythme”… nouveau mode et nouvelle bande pour moi ainsi que nouveau pays dans l’année 2013. Dans la même demi-heure j’ai aussi contacté JY9FC sur 10 mètres et 4K9W sur 12 mètres.

Quelques jours auparavant j’avais ajouté KH0M (premiers QSOs avec les îles Mariannes cette année) et V73NS (plusieurs fois depuis le début d’année dont une fois avec 5W en portable) à mon log. Un peu plus tôt dans le mois c’était TO2TT (http://www NULL.i2ysb NULL.com/idt/) sur 17, 15 et 12 mètres (il me manque le 10 mètres) dans des conditions difficiles car leur dégagement est très mauvais dans cette direction. 3D2GC et 3D2GC/P (Rotuma, nouveau pays pour 2013) ainsi que OD5ZZ et T77C m’ont aussi permis d’afficher un large sourire en descendant du shack… Sans être exceptionnelles, j’avoue que les conditions sont suffisamment bonnes pour autoriser accrocher de jolis DX du 20 au 10 mètres. Les bandes basses sont toujours trop bruyantes à cette saison avec les typhons qui s’enchaînent dans la mer de l’Est. Comparativement à l’année dernière, le 10 et le 12 mètres offrent de moins belles ouvertures, mais j’entends parfois des stations NA appeler d’autres stations DX, preuve que la propagation est là!

Seul regret, l’impossibilité de contacter TX5D (http://www NULL.dxcoffee NULL.com/eng/2013/09/27/tx5d-raivavae-island-iota-oc-114/). Une seule fois j’aurai été en mesure de faire QSO sur 20 mètres, mais le pile-up était trop important et je suis arrivé au moment où la propagation entre nous deux commençait à faiblir et le signal se perdre dans le bruit. Leur objectif est clairement l’Amérique du Nord et la planification de leurs opérations à l’opposé de ce qui serait intéressant pour moi. Je ne peux bien entendu pas leur en vouloir, mais c’est tout de même frustrant!

Contests, Dev web, DX, Ego, Geek, le monde est geek, HAM Radio

QScope avec K9W et TO2TT

Logo QScope.org (http://xv4y NULL.radioclub NULL.asia/wp-content/uploads/2013/08/logo_qscope_b NULL.png)En ce moment j’ai peu de temps pour le blog. Mes diverses activités professionnelles prennent la première place, avec entre autres un projet d’ouverture de restaurant qui redevient d’actualité. Ensuite j’ai été pas mal sollicité sur QScope (http://www NULL.qscope NULL.org/), d’abord par des nouvelles statistiques suggérées par les utilisateurs, ensuite par les bogues à corriger puis finalement par des revues et bulletins DX qui souhaitent avoir plus de détails afin de publier un article complet sur le projet.

La bonne nouvelle c’est que les organisateurs de deux grosses Expéditions à Wake Island (K9W) (http://www NULL.wake2013 NULL.org/) et à Mayotte (TO2TT) (http://www NULL.i2ysb NULL.com/idt/) ont annoncé leur volonté d’utiliser QScope en interne pour l’organisation de leurs opérations. Les statistiques produites leur permettront d’avoir jour par jour toutes les informations pour mieux répartir les tours d’opérateurs et la répartition des activités par bandes et modes dans le temps. Le but étant de maximiser le nombre de QSOs afin de mieux “rentabiliser” le coût de ces organisations. Le nombre de QSOs pour de telles DXpeditions en fin d’opération s’élève vite à 100.000, et ces utilisateurs utiliseront les statistiques les plus coûteuses en terme de temps machine!

J’ai donc du passer du temps afin de “préparer l’avenir”. En effet, si maintenant l’application compte 600 utilisateurs enregistrés et plus de 3 millions de lignes de log téléchargées, l’effervescence des premiers jours s’est calmé en moyenne il y a 10 utilisateurs “actifs” par jour qui produisent des statistiques et 1,8 millions de lignes de log dans la base de données (les utilisateurs effacent souvent leur logs après avoir produit les statistiques). La base de données principale fait 250 Mo, et les index occupent autant. Quand on tient compte de la RAM du serveur occupée par le système, le SGBDR lui-même et les différents shared buffers, on se rend compte qu’on se rapproche vite de la capacité maximale disponible de 1 Go actuelle sur le serveur. Rapidement, au lieu de lire les données dans la mémoire cache rapide, c’est sur le disque dur très lent que le SGBDR ira chercher ses informations à traiter. Les temps de calcul seront multiplié par 10 au moins…

Deux solutions à cela : augmenter la RAM du serveur ou mieux répartir les données. La première solution est la plus rapide à mettre en oeuvre, le problème c’est que chez le fournisseur que j’ai choisi c’est aussi la plus coûteuse. Les prix sont très attractif pour l’entrée de gamme, mais ensuite on grimpe très vite. L’autre solution est donc beaucoup plus intéressante sur le long terme. La réponse que je souhaitais mettre en place s’appliquait en trois phases :

  1. Mettre en place le mécanisme de Paritionnement de Tables de PostgreSQL. Simple à mettre en place en théorie, même si entièrement manuel contrairement aux SGBDR commerciaux comme Oracle ou Sybase, il permet de diminuer la taille de chaque table à charger en RAM et la taille des index. Je pensais donc répartir mes utilisateurs sur 27 tables (les 26 lettres de l’alphabet plus un “fourre-tout”) en fonction de la première lettre de leur indicatif. Après quelques tâtonnements (une maquette avec 2 utilisateurs est bien plus facile qu’une base de production avec 600 comptes) tout fonctionnait parfaitement. Les tables les plus grosses faisaient 40 Mo et les index avaient bien diminué en taille. Le “hic” c’est que les performances étaient pires qu’avant!!! Le problème venait de la fonction choisie pour répartir les utilisateurs sur les différentes tables. Celle-ci était coûteuse en temps machine et la pénalité se paye à chaque requête. J’ai donc du faire marche arrière… Le partitionnement reste intéressant, mais pour une répartition plus légère à calculer (simple comparaison) comme celle sur une date.
  2. Donner la possibilité d’attribuer à chaque utilisateur une base de données différente. Là, le travail se résumait à pas mal de réécriture du code existant pour permettre de se connecter sur différentes base de données “à la volée”. Rien d’insurmontable surtout que j’avais envisagé la chose assez tôt. En pratique ça me permet d’isoler facilement les “gros” utilisateurs comme les DXpeditions. Ils feront leurs calculs gourmands sur une base de taille plus petite que la base principale, diminuant les temps de traitement. La compartimentation au niveau du serveur aidera aussi les utilisateurs de la base principale à être moins impactés puisque ce seront deux emplacements mémoire et deux emplacements disques différent qui seront consultés, limitant les phénomènes de “lock“.
  3. Permettre d’utiliser plusieurs petits serveurs plutôt qu’un gros. Techniquement la solution est la même que la précédente, sauf que cette fois-ci au lieu d’interroger une autre base de données du même serveur je vais la chercher sur une autre machine. Cela est très intéressant car en répartissant les utilisateurs sur plusieurs bases on évite que celles-ci grossissent de trop et deviennent trop lourdes à gérer. Du point de vue financier, c’est aussi le plus intéressant car en doublant le coût, on double réellement la capacité (CPU, RAM et disque) alors que dans la grille tarifaire du fournisseur, doubler le prix payé pour le serveur ne faisait que doubler la RAM. Le contrecoup c’est que ça fait deux systèmes à gérer et donc plus de temps à passer. Toutefois, si les deux systèmes sont identiques et disposent de bonnes procédures automatisées, cette maintenance reste limitée.

Comme vous le voyez, je suis assez satisfait du temps passé sur QScope car cela me permettra de répondre plus facilement à l’augmentation de la demande qui va venir avec la saison des concours et des DXpeditions. L’échec de la mise en place du paritionnement n’est que partiel, et dans la réalité le serveur se comporte mieux que je ne l’avais craint. En effet, en plus de la RAM physique de 1 Go qui est allouée, 4 Go de disque SSD très rapide sont vus par le système comme de la RAM et permettent de diminuer les temps de réponse du disque tant qu’on reste dans des limites acceptables.