I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running into
is that upon the return of the recvfrom system call, the data may not always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes a
long time, about 160 usec. For our application, 160 usec was not acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less. Has
anyone run into a similiar problem ? and what was your solution ?
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running
into
is that upon the return of the recvfrom system call, the data may not
always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes
a
long time, about 160 usec. For our application, 160 usec was not
acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less.
Has
anyone run into a similiar problem ? and what was your solution ?
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running
into
is that upon the return of the recvfrom system call, the data may not
always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes
a
long time, about 160 usec. For our application, 160 usec was not
acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less.
Has
anyone run into a similiar problem ? and what was your solution ?
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
I am sending/receiving UDP messages using the standard sendto/recvfrom
socket API using the non-blocking option. The problem that I am running
into
is that upon the return of the recvfrom system call, the data may not
always
be in the received buffer even though the returned value from recvfrom was
greater than zero. To patch this problem, I called recvfrom with the PEEK
option turned ON to make sure my data was there before fetching it. This
patch works fine except that the recvfrom call with the PEEK option takes
a
long time, about 160 usec. For our application, 160 usec was not
acceptable.
I verified the socket is non-blocking and the option RECV_TIMEOUT is zero.
Without the PEEK option, the recvfrom takes only a couple usec or less.
Has
anyone run into a similiar problem ? and what was your solution ?
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
On my Dual Athlon 1800 (single threaded app - running the large stack on QNX
6.2NC) I get a worst case time of ~140 usec (out of 1000000 calls). The
average call takes 7 usec. If your application needs a certain throughput
over a larger timespan, then the 7 usec average might be ok for you. If
you can’t tolerate a ~160 usec worst-case, then you might want to investigate
doing your own protocol (as you probably know, the typical tcp/ip stack
isn’t really designed for demanding real-time).
Mike Lee wrote:
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
On my Dual Athlon 1800 (single threaded app - running the large stack on
QNX
6.2NC) I get a worst case time of ~140 usec (out of 1000000 calls). The
average call takes 7 usec. If your application needs a certain throughput
over a larger timespan, then the 7 usec average might be ok for you. If
you can’t tolerate a ~160 usec worst-case, then you might want to
investigate
doing your own protocol (as you probably know, the typical tcp/ip stack
isn’t really designed for demanding real-time).
Yes, and the ethernet itself does not guarantee any timeframe for delivery
(worst case delivery time is infinity). Applications that need deterministic
delivery time have to use more suitable transport. Look at something like
Profibus for example…
I made a mistake on my measurement. The recvfrom call takes 160 usec
regardless of the
state of the option. You could set the flag to zero or MSG_PEEK, and it
would still take
160 usec to complete. I am using a MIPS 5000 series CPU with 256 MB ram.
Have anyone done any timing measurement on these socket calls ?
On my Dual Athlon 1800 (single threaded app - running the large stack on
QNX
6.2NC) I get a worst case time of ~140 usec (out of 1000000 calls). The
average call takes 7 usec. If your application needs a certain throughput
over a larger timespan, then the 7 usec average might be ok for you. If
you can’t tolerate a ~160 usec worst-case, then you might want to
investigate
doing your own protocol (as you probably know, the typical tcp/ip stack
No … Mike is using UDP and not TCP/IP … so this is off topic.
The problem seems to be the priority of the network client … at least
in your case. The worst case can only be created by pre-empting of your
driver thread of the network driver.