Something strange going on with Windows X64 Pro and Nvidia Network Controller.

  • Thread starter Thread starter Skybuck Flying
  • Start date Start date
S

Skybuck Flying

Guest
Hello,

When trying to send udp packets with a random payload size between 0 and
65000 windows only sends little packets ?

The udp packets are not fragmented properly... at least according to
ethereal...

Could be a windows x64 stack bug, an ethereal/winpcap bug or maybe it's my
program at fault.

Really weird.

Windows x64 Pro also the most crashy operating system so far, haven't tried
vista yet though... only in virtual pc and even that was bad he ! ;)

Bye,
Skybuck
 
Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Hello,

Tested the following:

Random UDP Sizes 0 to 65000.

Rapid packets after each other.

Windows XP x64 and Windows XP 32 bit.

Program seems to work normally.

Sender and receiver more or less report the same size as well as ethereal.

It seems windows does not allow sending many random udp sizes right after
each other ?

Or could it be some kind of strange threading bug ?

Very strange.

When sending fixed size large udp packets ip fragmentation does work and
large udp packets get through.

But random udp sizes not ??????? Very very very very very strange ?!

(Only little packets arrive huh ?)

Bye,
Skybuck.
 
Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

On Oct 16, 9:16 am, "Skybuck Flying" <s...@hotmail.com> wrote:
> Hello,
>
> Tested the following:
>
> Random UDP Sizes 0 to 65000.
>
> Rapid packets after each other.
>
> Windows XP x64 and Windows XP 32 bit.
>
> Program seems to work normally.
>
> Sender and receiver more or less report the same size as well as ethereal.
>
> It seems windows does not allow sending many random udp sizes right after
> each other ?
>
> Or could it be some kind of strange threading bug ?
>
> Very strange.
>
> When sending fixed size large udp packets ip fragmentation does work and
> large udp packets get through.
>
> But random udp sizes not ??????? Very very very very very strange ?!
>
> (Only little packets arrive huh ?)


No such issues exist, although you may be running out of buffers on
either or both sides. The default behavior of basically all TCP/IP
stacks is to discard UDP packets when out of space.

The default buffer allocated by Windows to a UDP socket is 8K (which
is smaller than on many system), which would correspond to five 1400
bytes packets plus a bit. Try increasing it with setsockopt()/
SO_RCVBUF.
 
Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Yeah I dug up my old c/cpp code for winsock and converted it to winsock 2.

Sending random udp sizes there does not create any bugs.

So it must be some kind of weird bug in my delphi application which uses
threads and dynamically loads the library.

Driving me nuts.

But I am gonna find it hopefully ;)

Bye,
Skybuck :)
 
Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Ok,

It seems to be some kind of timing bug.

Could be overflow or maybe it's a bug in QueryPerformanceCounter.

For now I'll assume it's a bug in my timing code.

Still how a timing bug leads to little packets confuses me ?

It seems impossible.

Maybe it's an operating system bug after all, not sure though ;)

Very strange.

More investigation will need to be done ;)

Bye,
Skybuck.
 
Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Re: Windows XP:Quick Random UDP Sizes with winsock not allowed ?

Oh, now I understand !

It's an algorithm bug !

Kinda funny.

The data size is randomized.

And the speed limit is checked to see if bytes are available.

If not then a new data size is randomized.

So big data sizes never make it... because the thread runs so fast... the
bucket didn't have time to get full for a larger packet.

So that's why only smaller packets get through..

Hehe !

So algorithm has to change a little bit.

Initialize a random data size or so... keep trying to reserve the bytes from
the speed limit, when it's allowed to send... try to send it... and then it
doesn't matter if it was sent or not... because it passed the speed limit...
so then it's ok to initialize a new random data size.

This prevents illegal data size from holding things up as well... since a
new one would be generated ;)

Bye,
Skybuck.
 
Back
Top