Re: Windows 2000 problems
I am not using representative streams. I am trying to test the delay_loop
function in the following way on windows 2000 (test code uses
gettimeofday.c, Timestamp.hpp, delay.cpp, delay.hpp):
----------------------------------------------------
Timestamp start, end;
start.setnow();
// test a delay of 500 microseconds
delay_loop(500);
end.setnow();
printf("start time is %f\n", start.get());
printf("end time is %f\n", end.get());
----------------------------------------------------
The output for the above code on win2k is:
----------------------------------------------------
start time is 1045946946.637292
end time is 1045946946.647306
----------------------------------------------------
I tested the above code on a sun sparc 5.6 (here test code uses only
Timestamp.hpp, delay.cpp/hpp, but does not use Iperf's implementation of
gettimeofday.c) and I get a perfect delay of 500 usecs, as shown
below:
----------------------------------------------------
start time is 1045946809.586408
end time is 1045946809.586908
----------------------------------------------------
In fact, on sun sparc 5.6, I tested a smaller delay of 50 usecs, and it still seems to work very well (It gave me a delay of 50 usecs with +/- 1 microsecond error).
Thus, for win2k, the updates seem to occur only at about 10 msec intervals. Is there a setting in win2k that I might be missing? What could be the problem?
I sincerely appreciate your help,
Vinay.
> Are you using representative streams? AKA are you using data from disk? If
> you are then I would say your problem is disk access, but if
> getSysTimeasFileTime really only reported 10ms granularity then you could
> never get more than 14Mb/s on a Win2K machine using UDP. I know this is
> not the case. I have not taken the time to try to determine the resolution
> of delay_loop but the comment says that the previous developers got it
> into a few usecs which is a big diffference from msec. Once again I ask
> how are you measuring this accuracy and are you sure you are not doing
> something that is increasing the time? IO in general takes close to 10ms
> so if you are doing any printf's or reading from disk then I would say
> that is your problem not Win2k. Like I said I have not tested it myself
> but I can not believe that 10ms is the best that can be done since that
> would severely limit bandwidth possible (below 14Mb/s).
>
> Kevin
>
> On Fri, 21 Feb 2003, Vinay Chandrasekhar wrote:
>
> > Thank you for your response. I apologize, my description of the delay_loop
> > problem might have been misleading. Hope this one gives a better picture:
> >
> > Say I want to send UDP datagrams at bit rates which require a delay of
> > 200 microseconds between successive datagrams. The environment in which
> > I am trying this experiment (Windows 2000 v5 sp2 on NT FAT32, and I am
> > compiling using Visual Studio 6.0) provides me with a resolution of 10
> > milliseconds for file times. delay_loop function uses getTimeofday function,
> > which in turn uses getSysTimeasFileTime (the resolution of which is 10 ms).
> > So after the first datagram is sent, instead of 200 microseconds, I get 10
> > milliseconds of delay from the delay_loop before the next datagram
> > can be sent.
> >
> > I dont know whether I can get better resolutions on NTFS. I am working on that
> > right now and will let you know. If you have any suggestions, or know that
> > I might be missing something, please let me know.
> >
> > Thanks,
> > Vinay.
> >
> > > I have no experience with the cygwin environment so I can not help you
> > > out. I use Visual Studio .Net to compile win32 versions and the next
> > > release will include a .vcproj that can be used with VS .NET.
> > >
> > > How are you measuring the resolution of delay_loop? I am not sure how you
> > > are deciding that the gettimeofday granularity is some how based on the
> > > delay_loop function since it is not. A time of day function is completely
> > > OS specific and I would doubt they would allow tweaking of its
> > > responsiveness. Also there are some floating point to long conversions
> > > that may be removing some of the detail you are looking for.
> > >
> > > Kevin
> > >
> > > On Fri, 14 Feb 2003, Vinay Chandrasekhar wrote:
> > >
> > > > hello,
> > > > I have a couple of questions, and would greatly appreciate any suggestions
> > > > or advice ..
> > > > 1. I am unable to compile the latest version (1.6.5) of iPerf on Windows 2000. I
> > > > am trying to compile the source code in a cygwin window - I have
> > > > installed the base cygwin and accompanying gcc - and I get the following
> > > > error:
> > > >
> > > > In file included from gnu_getopt.c:75:
> > > > gnu_getopt.h:95: redefinition of `struct option'
> > > > make[1]: *** [gnu_getopt.o] Error 1
> > > > make[1]: Leaving directory `/cygdrive/c/vinay/thesis/snmp/software/traffic/compi
> > > > le/lib'
> > > > make: *** [lib/libdast.a] Error 2
> > > >
> > > > What am I doing wrong? Is there any other way to compile iPerf in windows 2000?
> > > > I also have MS Visual Studio... I tried finding the answers to this
> > > > elsewhere, but havent had success so far.
> > > >
> > > > 2. I am trying to test whether it is possible to send UDP datagrams at different
> > > > time instants(VBR, to some extent) using iPerf. The maximum resolution
> > > > that windows is currently giving me for the delay_loop() function, and
> > > > consequently the gettimeofday() function is about 10015 microseconds
> > > > (about 10 mSecs). Is there a setting that I could change somewhere, and
> > > > make it work better?
> > > >
> > > > Thank you,
> > > > Vinay.
> > > >
> > >
> > >
> > >
> >
>
>
>