tags:

views:

25

answers:

0
+2  Q: 

16 millisecond quantization when sending/receivingtcp packets

Hi,

I have a C++ application running on windows xp 32 system sending and receiving short tcp/ip packets.

Measuring (accurately) the arrival time I see a quantization of the arrival time to 16 millisecond time units. (Meaning all packets arriving are at (16 )xN milliseconds separated from each other)

To avoid packet aggregation I tried to disable the NAGLE algorithm by setting the IPPROTO_TCP option to TCP_NODELAY in the socket variables but it did not help

I suspect that the problem is related to the windows schedular which also have a 16 millisecond clock.. Any idea of a solution to this problem ? Thanks

related questions

Exceptions vs Result Codes for a socket client class.
Find the next TCP port in .Net
How should one go about choosing a default TCP/IP port for a new service?
Need to run a TCP server besides a Rails app
Checking IP Port State Remotely
Tool to monitor HTTP, TCP, etc. Web Service traffic
Manualy choose an interface on TCP to send data
How do you specify a port range for Java sockets?
What is the largest TCP/IP network port number allowable for IPv4?
Read divert sockets in java?
What do you use when you need reliable UDP?
TCP send queue depth
Scalable socket event queue processing
WCF netTCPBinding - Is transport encryption enough?
What's the best way to send a file over a network using C#?
What kind of issues are there in implementing realtime multiplayer games
Best way to open a socket in Python
Hooking into the TCP Stack in C
Recovering from a broken TCP socket in Ruby when in gets()
Where do the Linux TCP/IP hackers 'live'?
Track down where packets are being blocked/droped
UDP vs TCP, how much faster is it?
How do you minimize the number of threads used in a tcp server application?
Broadcast like UDP with the reliability of TCP
Default Routes