Surely, an attached debugger is going to use some CPU time, however
small even if nothing triggers it, therefore, the debugged program cycle
timing will change somehow, however small.

Plus, however the debugger works, it could be forcing some other process
(in the kernel) to do it's job more often, so keeping something
up-to-date, that might otherwise slip a bit without that constant

I've also seen similar things (with other high speed I/O) in the past,
it's 99% of the time, a timing problem.  Somethings on the ragged edge,
and any attached process (Debugger or ???) just helps that little bit by
sneeking in a few extra nS somewhere.     Multi core CPU's or
HyperThreading seem to provoke this sort of mayhem more than most..
Can you dedicate your program to one core, and one core only?

You did say TCP works OK, the extra overhead of that stack probably
add's some time, and/or forces some data table updating, helping things

Remember, Windows is not a real time system.  Plus, it's not entirely
unknown for MS to do things in not quite the right way.  (As the rest of
the world sees it anyway...)

It could of course, be "something completely different", to quote Monty

I'll get me coat......

Dave B.

> -----Original Message-----
> From: Francois PIETTE [] 
> > I think that if you consider what I suggested before, might 
> help you...
> > It maybe has to do with extra process time the debugger gives
> Thanks for insisting.
> Which extra process time do you mean ? The debugger has just 
> to be attached. 
> No need to set any breakpoint nor single step. Just attach. 
> IMO, when a debugger is attached, the process is not slowed down.
> I would also add that there is definetely no CPU time issue, 
> nor network I/O issue with the application. Every second, it 
> send a single UDP datagram (A SNMP get request) and expect a 
> single UDP datagram (A SNMP get reply). A single socket is 
> used for both send and receive and datagram fits in winsock 
> receive buffer.
> -- 

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to