Re: cpu usage on the client!
There is no numerical accuracy margin between delay_loop() and sleep(),
becuase sleep is implemented extremely differently on different platforms.
Sleep()'s definition is that it will wait _atleast_ the specified number
of millseconds. Depending on the workload of the machine you can get a
delay in excess of 1 sec beyond the time you wanted to wait for. This is
obviously unacceptable for CBR streams. However, the delay_loop relies on
gettimeofday to function. This function also differs greatly between
platforms. delay is used because on a vast majority of the platforms it
has a resolution of about 10usecs. Sleep by definition can not be better
than 1msec but most are much worse. However on Win32 gettimeofday is not
implemented so Iperf does a conversation between GetSystemTimeAsFileTime
and what would be the result of a call to gettimeofday. This Win32
function only has a accuracy of 10msecs. So with a Win32 client you might
get better accuracy with Sleep than with delay_loop, but only on Win32
clients. However on a moderate-heavily loaded machine Win32 or otherwise
you will likely get better accuracy with delay_loop than sleep.
Kevin
On Tue, 18 Nov 2003, Sinada, Yasir wrote:
> Hi,
> I had UDP packets drops when I run unicast or multicast traffic on an
> isolated network (100 Mbps), the server and client in unicast case are
> srv: iperf -s -u
> clnt: iperf -c <ip> -u -l 1K -b 4.4M
>
> I changed the source file PerfSocket_UDP.cpp:188 from
> delay_loop( delay )
> to
> Sleep(delay/1000); //win32
> just to see the effect of getting rid of the CPU maxage*, and the packet
> droppage** was much more less (or even 0 dropped packets). I know it is been
> mentioned that sleep is not an accurate measure of time, but what's the
> accuracy margin when sleep is used compared to the "delay for loop"
> scenario? +/- 3% or similar?
>
> Thanx,
> Yasir
>
> * CPU utilization ~ 100%
> ** rate of dropped packets
>