g*********n
发帖数: 43 | 1 我想测试一下用UDP的SENDTO 最快能够以多大速率发送数据。用了下面的程序：
for(i=0;i
sendto(..........);
问题是，当LOOPCOUNT是比较小的数(1000)时，程序能够很快 结束。但是当LOOPCOUNT比
较大时， 程序需要的时间极长极长。应该不是合理的情况。
我作了一点改动，
for(i=0;i
{
sendto(..........);
printf(""); //add some delay
}
在这种情况下程序能够较快的结束。
为什么会有这种情况发生？
不应该是collision of Ethernet,因为LOOPCOUNT=1000时碰撞也可能发生。
有没有这种可能，系统内部有缓冲区，
快速发送时，来不及从网卡上发走的数据存在缓冲区。
如果LOOPCOUNT比较小的话， 缓冲区能够容纳；
如果LOOPCOUNT很大， 在某个时刻缓冲区溢出，导致速度下降。
如果加上DELAY， 则可以保证缓冲区不会溢出。
请各位大侠指教。 |
m*****e
发帖数: 4193 | 2
buffer used up, and you sleep.
【在 g*********n 的大作中提到】
: 我想测试一下用UDP的SENDTO 最快能够以多大速率发送数据。用了下面的程序：
: for(i=0;i: sendto(..........);
: 问题是，当LOOPCOUNT是比较小的数(1000)时，程序能够很快 结束。但是当LOOPCOUNT比
: 较大时， 程序需要的时间极长极长。应该不是合理的情况。
: 我作了一点改动，
: for(i=0;i: {
: sendto(..........);
: printf(""); //add some delay
|
p******f
发帖数: 162 | 3
Then why adding a printf can reduce the total time?
Is is due to avoid sleep and wakeup a process too frequently?
【在 m*****e 的大作中提到】
:
: buffer used up, and you sleep.
|
m*****e
发帖数: 4193 | 4 his analysis is correct
【在 p******f 的大作中提到】
:
: Then why adding a printf can reduce the total time?
: Is is due to avoid sleep and wakeup a process too frequently?
|
p******f
发帖数: 162 | 5
You mean my analysis?
By the way, I don't feel comfortable with top-post.
But it seems everybody is top-posting.
【在 m*****e 的大作中提到】
: his analysis is correct
|
n******t
发帖数: 4406 | 6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这个程序是没有意义的.UDP的sendto完全不管有没有收到的.
基本上等于一个copy调用,仅仅copy到buffer就算高定.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
这个可以通过监查sendto的返回直看出来.
【在 g*********n 的大作中提到】
: 我想测试一下用UDP的SENDTO 最快能够以多大速率发送数据。用了下面的程序：
: for(i=0;i: sendto(..........);
: 问题是，当LOOPCOUNT是比较小的数(1000)时，程序能够很快 结束。但是当LOOPCOUNT比
: 较大时， 程序需要的时间极长极长。应该不是合理的情况。
: 我作了一点改动，
: for(i=0;i: {
: sendto(..........);
: printf(""); //add some delay
|
m******e
发帖数: 1244 | 7
Right, this program actually shows how soon the buffer becomes full.
I think he didn't set the O_NONBLOCK flag, so sendto will block until there is
space in the buffer.
【在 n******t 的大作中提到】
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 这个程序是没有意义的.UDP的sendto完全不管有没有收到的.
: 基本上等于一个copy调用,仅仅copy到buffer就算高定.
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: 这个可以通过监查sendto的返回直看出来.
|
w*****n
发帖数: 94 | 8
When the buffer becomes full, how soon the buffer can be emptied should
depend on the speed of output interface.
IMHO, O_NOBLOCK should not be enabled, reason as above.
This program seems reasonable, as long as the author knows what he is
measuring.
【在 m******e 的大作中提到】
:
: Right, this program actually shows how soon the buffer becomes full.
: I think he didn't set the O_NONBLOCK flag, so sendto will block until there is
: space in the buffer.
|
m******e
发帖数: 1244 | 9
Let's see where you will set the measure points and what you can get from your
measurement.
there is
My point is since he couldn't set NONBLOCK for his test, he couldn't use
the return value to decide whether the sendto operation has succeeded or not.
Next time please read carefully before make your comment.
【在 w*****n 的大作中提到】
:
: When the buffer becomes full, how soon the buffer can be emptied should
: depend on the speed of output interface.
: IMHO, O_NOBLOCK should not be enabled, reason as above.
: This program seems reasonable, as long as the author knows what he is
: measuring.
|
n******t
发帖数: 4406 | 10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This should not necesorily be true even the call would be blocked.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UDP socket never blocks on writing.the byte number return
are neither the number received by other end or going through
the NIC.
~~~~~~~~~~~~~~~~~~~~~~~
Of course it measures somthing, but almost nothing with network performace.
And what I am doubting is that his strange result. I do not
think he do the test acurately.
【在 w*****n 的大作中提到】
:
: When the buffer becomes full, how soon the buffer can be emptied should
: depend on the speed of output interface.
: IMHO, O_NOBLOCK should not be enabled, reason as above.
: This program seems reasonable, as long as the author knows what he is
: measuring.
|
