Inter-Arrival time

Hi,

I am trying to measure the inter arrival time of the packets that I receive in one of my sockets. Basically, I ve got a socket listening for packets and each time a packet arrives I start a timer. Whenever the next packet arrives I stop the timer and store the value. Then I start a new timer until next packet arrives. The code is below.

Code:

---

...
#define IARRIVAL_DELAY 1
int Crx=0;
struct timeval tv_b_iarrival[100][7000],tv_e_iarrival[100][7000];
float AvgIarrival[100][7000];
char log_iarrival_buf[500];
FILE * fd_iarrival;
float MaxIarrival=0.0;
double SumIarrival=0.0;
char filename_iarrival[150]="log_file.dat";
...

...
nrcv=recvfrom(sockfd,buffer,buffersize, 0, (struct sockaddr *)&address,&addrlen );

if (nrcv>0){
        if (IARRIVAL_DELAY){
                if (Crx==0)start_time(&tv_b_iarrival[pair][Crx]);
                else {
                        fd_iarrival=fopen(filename_iarrival,"a");
                        if(fd_iarrival != NULL) {
                                AvgIarrival[pair][Crx-1]=stop_time(&tv_e_iarrival[pair][Crx-1],&tv_b_iarrival[pair][Crx-1]);
                                sprintf(log_iarrival_buf, "%d,%f\n", Crx,AvgIarrival[pair][Crx-1]);
                                fwrite(log_iarrival_buf,strlen(log_iarrival_buf),1,fd_iarrival);
                                fclose(fd_iarrival);
                        }       
                }
                if (Crx!=0)start_time(&tv_b_iarrival[pair][Crx]);
                Crx++;
        }
}

---

Now, I compare my values with those I record with Wireshark and they are clearly apart. While Wireshark values show sharp differences now and them my values are mainly steady and do not vary much. So I wonder if the socket buffer is playing me a hard time. In other words, Is it possible that the socket
buffer deliver the packet at a certain speed that i can not see the real difference in the arrival time? If that is the case, how could i get the values Wireshark is getting?

Thanks

For one thing, you're at the other end of the protocol stack compared to where wireshark is looking (the clue is in the name).

Secondly, you're really skewing your information with opening/closing the file for EVERY message.

Your large arrays seem to be serving no useful purpose.

Quote:

---

you're at the other end of the protocol stack

---

Yes that is right but i have no experience in comparing both sides and it strikes me such big differences.

Quote:

---

you're really skewing your information with opening/closing the file for EVERY message

---

This however should not modified the real values response time, it will actually make the longer delays longer and the shorter ones a bit larger isn't it?

Quote:

---

Your large arrays seem to be serving no useful purpose

---

This is because this is code is part of a thread that is called multiple times, 100 times exactly and 7000 is because I would like to capture 7000 times the inter-arrival time, so that i can get a good estimate. Also important to mention that at the moment I am only using single thread so yes I could actually remove the 100 from most of the arrays.

any other ideas of why the sharp changes in wireshark can not be seen at the other end of the protocol?

Thanks

> This however should not modified the real values response time, it will actually make the longer delays longer and the shorter ones a bit larger isn't it?
Consider this possibility:
Opening and closing a file takes 1 second (doesn't matter, it's just "large")
The variation between message arrival times is anything from 1mS to 10mS.
The large and near constant time to open/close the file is going to mask any fine-resolution variation in your message arrival times.

How can you have multiple threads, when you have a single scalar variable for your subscripts?

I would remove all the file I/O from your current code, and only write it out when the array is full. On a per message basis, there should be very little overhead in timing the message.

Also, how expensive is your timing code?
Is it really a timer, that will fire some event at a future time? These can be expensive.
How about just reading some convenient clock function?

Quote:

---

Opening and closing a file takes 1 second (doesn't matter, it's just "large")
The variation between message arrival times is anything from 1mS to 10mS.

---

This is actually a good point. In my case I am receiving RTP packet on my socket and they are normally around 20ms apart and although i have changed the code as you mentioned

Quote:

---

only write it out when the array is full

---

the outcome is still the same.

Quote:

---

How can you have multiple threads, when you have a single scalar variable for your subscripts?

---

I havent been completely transparent in the code, but actually these variables are global variables

struct timeval tv_b_iarrival[100][7000],tv_e_iarrival[100][7000];
float AvgIarrival[100][7000];

So I can have up to 100 threads but all write in the same array, so that then the main threat can handle all the data.

Quote:

---

Is it really a timer, that will fire some event at a future time?

---

I simply want to measure the inter arrival time of the packets nothing but that, i am not seting an event out of it.

So, my main questions whether the socket's buffer can smooth the real arrival time with sockets is still unfolded.