Re: Windows 2000 problems
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.
> > >
> >
> >
> >
>