Re: Windows 2000 problems
Thanks for the test code. I get similar results and the Win32 SDK states
that you are going to get results of granularity of 10ms. So if you want
to have better performance then you are going to need to use
QueryPerformanceFrequency and QueryPerformanceCounter. I will look at
replacing delay_loop with these win32 functions in the future, but that is
going to be your best bet, sorry.
Kevin
On Sat, 22 Feb 2003, Vinay Chandrasekhar wrote:
> 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.
> > > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>