in reply to sleep and timing?

Why, if you want two actions to happen within a specified time of each other, are you putting them in threads? Especially as the actions are SNMP traps, which are UDP messages for which there is no reply, so no IO wait for the second event to overlap.

You are trying to arrange for two threads to synchronise, which whilst possible if your running on a multiprocessor system, is a very hard (and pointless) exercise.

Even if you are running on multi-processor hardware, unless it is multi-homed also, your carefully synchronised traps will be serialised at the network stack.

And if ir is multi-homed, unless the destination hardware, and every node in between is also multi-processor and multi-homed, one of them will serialise the traps as they pass through.

Finally, if any other traffic is using any of the cable runs or any of the intervening nodes, it will almost certainly delay one trap relative to the other. Even if you succeed in causing the traps to be passed onto the network with specific timing, there is no guarentee, and absolutely no chance(*) that they will arrive at their destination(s) with that same timing.

Two dual-processor, dual-homed systems connected back to back in complete isolation might maintain the timing, but even that is unlikely.

Finally, with UDP messages, if you just sent them serially from a single thread, it is almost unthinkable that they would not be transmitted within one second of each other. Even if your outbound connection was via 1200 baud modem, unless your data packets are pretty big, you could expect to transmit many more than two UDP messages serially, from a single thread within 1 second.

There just doesn't seem to be any good reason for doing what you are trying to do. Please correct me if I am not seeing the whole picture?


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: sleep and timing?
by Anonymous Monk on Nov 23, 2005 at 15:27 UTC
    My objective (crazy or not) is to send N number of traps in a specific amount of time. I'm trying to do some performance testing so I'm not concerned about the destination or the arrival time at the other end.

      Then rather than trying to send for an exact time period and count how many you succeeded in transmitting, do it the other way around. Transmit a set number of traps and time how long it took. Set the number to send relatively high and divide that number by the number of seconds taken to arrive at an average throughput per second.

      This is a simulation.

      Although each "trap" delays at least 10 ms and an average of 30 millseconds, threading allows those delays to overlap, so the ultimate cost per trap is under 4 ms.

      HTH


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Ah...good idea. That's a much better aproach. Thanks for all your help!