From: "Gregg N" 

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01C55BA9.F0F0A2F0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Any idea what's causing this? Someone else said he got better results =
using a non-blocking socket but I did not look at what he did or verify =
his results.

Gregg
  "Rich"  wrote in message news:428abf18{at}w3.nls.net...
     I tried one of my own tools.  With a UDP payload size of 1K I can =
get 50% network utilization of a 1GB adapter with 100% CPU utilization.  =
If I increase the payload size to 1025 bytes then I get 4% network =
utilization with around 35% CPU utilization.

  Rich

    "Gregg N"  wrote in message =
news:428a3454{at}w3.nls.net...
    We have an application that sends UDP datagrams over gigabit =
ethernet. It=20
    was not achieving the performance we expected, so we ran some tests. =
When=20
    the packet size is 1024 bytes or less, we can send 40,000 packets =
per=20
    second, or about 312.5 Mbps. Not great, but acceptable. However, =
with packet=20
    sizes greater than 1024 bytes, we could not send more than about =
3700=20
    packets per second, or about 28.9 Mbps (note this is on a 1Gb =
interface!).=20
    The process is not CPU bound, so that is not what is causing the =
limitation.

    We verified this using the iperf tool from this location:

    http://www.noc.ucf.edu/Tools/Iperf/default.htm

    which you can try yourself. Use the command

    iperf -u -l 1024 -c dummytarget -i 1 -b 500m -w 256k

    and see what it shows with -l 1024 and -l 1025. You can substitute a =
smaller=20
    value for -b (bandwidth) on a 100 Mb interface.

    Apparently, this has been encountered by others. For example, see

    =
http://groups.google.co.uk/group/comp.protocols.tcp-ip/browse_frm/thread/=
7ec2673b5471490f/409197bb36320ace?hl=3Den&lr=3D&ie=3DUTF-8&oe=
=3DUTF-8&safe=3Doff&rnum=3D1&prev=3D/groups%3Fhl%3Den%26lr%3D=
%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26selm%3D2003-01-27-01-42.0%2540c=
hch.demon.co.uk#409197bb36320ace

    and

    =
http://groups.google.co.uk/group/alt.winsock.programming/browse_frm/threa=
d/f05890d2b6b71452/8d8873987d71893b?tvc=3D1&q=3Dalanjmcf+1024&hl=3D=
en#8d8873987d71893b

    and

    http://www.chch.demon.co.uk/wintest/wintest.html

    However, I could not find anything about this on the MS web site. =
Does=20
    anyone have any idea what is causing this?

    Thanks.

    Gregg

------=_NextPart_000_0030_01C55BA9.F0F0A2F0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Any idea what's causing this? Someone else said he =
got better=20
results using a non-blocking socket but I did not look at what he did or = verify=20
his results.
 
Gregg

  "Rich" <{at}> wrote in message news:428abf18{at}w3.nls.net...
     I tried
one of my own =
tools. =20
  With a UDP payload size of 1K I can get 50% network utilization of a =
1GB=20
  adapter with 100% CPU utilization.  If I increase the payload =
size to=20
  1025 bytes then I get 4% network utilization with around 35% CPU=20
  utilization.
   
  Rich
   
  
    "Gregg N" <invalid{at}invalid.invalid>">mailto:invalid{at}invalid.invalid">invalid{at}invalid.invalid>
= wrote=20
    in message news:428a3454{at}w3.nls.net...We=
 have=20
    an application that sends UDP datagrams over gigabit ethernet. It =
was=20
    not achieving the performance we expected, so we ran some tests. =
When=20
    the packet size is 1024 bytes or less, we can send 40,000 =
packets per=20
    second, or about 312.5 Mbps. Not great, but acceptable. However, =
with=20
    packet sizes greater than 1024 bytes, we could not send more =
than about=20
    3700 packets per second, or about 28.9 Mbps (note this is on a =
1Gb=20
    interface!). The process is not CPU bound, so that is not what =
is=20
    causing the limitation.We verified this using the
iperf tool =
from=20
    this location:http://www.noc.uc" target="new">http://www.noc.uc=">http://www.noc.ucf.edu/Tools/Iperf/default.htm">http://www.noc.uc=
f.edu/Tools/Iperf/default.htmwhich=20
    you can try yourself. Use the commandiperf -u -l 1024 -c =
dummytarget=20
    -i 1 -b 500m -w 256kand see what it shows with -l 1024 and =
-l 1025.=20
    You can substitute a smaller value for -b (bandwidth) on a 100 =
Mb=20
    interface.Apparently, this has been encountered by others. =
For=20
    example, seehttp://groups.google.co.uk/group/comp.protocols.tcp-ip/browse_frm=
/thread/7ec2673b5471490f/409197bb36320ace?hl=3Den&amp;lr=3D&amp;i=
e=3DUTF-8&amp;oe=3DUTF-8&amp;safe=3Doff&amp;rnum=3D1&amp;=
prev=3D/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%2=
6selm%3D2003-01-27-01-42.0%2540chch.demon.co.uk#409197bb36320ace">http://=
groups.google.co.uk/group/comp.protocols.tcp-ip/browse_frm/thread/7ec2673=
b5471490f/409197bb36320ace?hl=3Den&amp;lr=3D&amp;ie=3DUTF-8&a=
mp;oe=3DUTF-8&amp;safe=3Doff&amp;rnum=3D1&amp;prev=3D/groups%=
3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3Doff%26selm%3D2003-01=
-27-01-42.0%2540chch.demon.co.uk#409197bb36320aceand<=
A=20
    =
href=3D"http://groups.google.co.uk/group/alt.winsock.programming/browse_f=
rm/thread/f05890d2b6b71452/8d8873987d71893b?tvc=3D1&amp;q=3Dalanjmcf+=
1024&amp;hl=3Den#8d8873987d71893b">http://groups.google.co.uk/group/a=
lt.winsock.programming/browse_frm/thread/f05890d2b6b71452/8d8873987d71893=
b?tvc=3D1&amp;q=3Dalanjmcf+1024&amp;hl=3Den#8d8873987d71893b<=
BR>andhttp://www.chch" target="new">http://www.chch=">http://www.chch.demon.co.uk/wintest/wintest.html">http://www.chch=
.demon.co.uk/wintest/wintest.htmlHowever,=20
    I could not find anything about this on the MS web site. Does =
anyone=20
    have any idea what is causing=20
  =
this?Thanks.Gregg

------=_NextPart_000_0030_01C55BA9.F0F0A2F0--

--- BBBS/NT v4.01 Flag-5