On 2011-06-20 19:32, Oussama Hammami wrote:
Salut,
J’ai lancé le teste avec une durée de SLEEP variable sur astrad5 :
TEST astrad5: ------------- Ngrep PID : 19379 START : 2011-06-20 19:10 IP : 91.121.178.108 NB. Customers: 191 +---------------------+---------------------+-----------+-----------+ | START | STOP | COUNT = 1 | COUNT > 1 | +---------------------+---------------------+-----------+-----------+ | 2011-06-20 18:00:00 | 2011-06-20 18:30:00 | 178 | 13 | | 2011-06-20 18:30:00 | 2011-06-20 19:00:00 | 180 | 11 | +---------------------+---------------------+-----------+-----------+
On a commencé avec une durée de 3600s, une fois arrivé a une durée de 30s le script tournera 10 fois avec cette valeur et il s’arrête.
TIME - COUNT - INTERVAL 2011-06-20 20:10:00 - 10 - 3600 -> START 2011-06-20 20:50:00 - 10 - 2400 2011-06-20 21:16:40 - 10 - 1600 2011-06-20 21:34:27 - 10 - 1067 2011-06-20 21:46:19 - 10 - 712 2011-06-20 21:54:14 - 10 - 475 2011-06-20 21:59:31 - 10 - 317 2011-06-20 22:03:03 - 10 - 212 2011-06-20 22:05:25 - 10 - 142 2011-06-20 22:07:00 - 10 - 95 2011-06-20 22:08:04 - 10 - 64 2011-06-20 22:08:47 - 10 - 43 2011-06-20 22:09:17 - 09 - 30 2011-06-20 22:09:47 - 08 - 30 2011-06-20 22:10:17 - 07 - 30 2011-06-20 22:10:47 - 06 - 30 2011-06-20 22:11:17 - 05 - 30 2011-06-20 22:11:47 - 04 - 30 2011-06-20 22:12:17 - 03 - 30 2011-06-20 22:12:47 - 02 - 30 2011-06-20 22:13:17 - 01 - 30 -> EXIT
On 2011-06-20 18:17, Emin Gabrielyan wrote:Now it looks logic
Here is a conclusion of this experience:
Here is the chart:on astrad5.switzernet.com the NAT routers of certain customers change or expire the port mapping of the SIP port more frequently than the registration frequency of the UA. As a result after a certain time the UA is not reachable. In this experience we send notify messages to all UA registered on the SIP server and we register the rate of replies sent back by UA. If the port mapping of a user is gone, the UA will not respond. However, as we keep sending the notify messages, as soon as the UA sends us a new register and updates its port value, the flow of notify messages will keep the port open until the next registration irrespectively of the delay it will take to come. This means that we have to observe high rate of losses, which will drop gradually as a result of reception of the updated registrations of slow UAs. We are sending notifies to all users with intervals between the waves of notifies equal to 30 seconds. The wave itself takes about 5 seconds. Thus, the periodicity is of approximately 35 seconds.
The Excel file is attached
On 2011-06-20 17:40, Oussama Hammami wrote:Yes = GREEN
On 2011-06-20 12:41, Task-By Emin Gabrielyan wrote:
Do you work on this?
Emin Gabrielyan
Le Jun 17, 2011 à 17:24, Emin Gabrielyan <emin.gabrielyan@switzernet.com <mailto:emin.gabrielyan@switzernet.com>> a écrit :
Below is a chart showing, contrary to all expectations, the increase of reply losses to notify methods.
We were expecting to have 0% losses after a while.
This increase is probably due to an error in the script that collected the data.
The script must be done again. BTW it must not consume 90% of CPU (and the reason is probably in the same error).
<moz-screenshot-48.png>
Attached you will find the Excel file computing this chart.
Emin
On 2011-06-17 16:21, Task-by Oussama Hammami wrote:
Ci-joint les fichiers Excel représentant les résultats des testes d’envoi de Notify.<110616-astrad6-notify-ngrep.xlsx>
*/Astrad6 :/*
Sur ce serveur on a lancé le script d’envoi de notify ainsi que ngrep à 2011-06-16 16:02
On a arrêté le script ngrep à 2011-06-16 18:36
_Notify ngrep:_ 110616-astrad6-notify-ngrep.xls
_Location history: _110616+1-astrad6-location-history.xls
/*Astrad7:*/
On a uniquement lancé le script d’envoi de notify à 2011-06-16 16:11
_Location history:_ 110616+1-astrad7-location-history.xls
