site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Mar 28, 2008, at 12:05 PM, darwin-dev-request@lists.apple.com wrote: I'm not really sure what more I can say. I have a tight loop which sends packets at various user defined intervals. Speeds range from quite slow (a few packets/second) to quite fast (beyond 150K/sec). I'm hoping to send packets at equal distant intervals for an even distribution rather then time-slicing it (send a bunch of packets at once and sleeping for longer periods of time), but I suppose I may be asking too much. HTH. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... If I understood what you were actually trying to do, I might have some better ideas... Given that the packets are going to be clustered up by the time they hit the wire due to queueing and scheduling latencies in both the network stack and the MAC, I believe you are trying a bit too hard. Pick a quantum that's not too coarse (a millisecond is probably a good place to start) and barf out a bunch of packets each time it ticks over. You can tune the actual quantum number up or down based on a bunch of factors, but bear in mind that you're talking to a networking stack designed for user applications, not a SmartBits. 8) It would probably be educational to watch the actual timing of the resulting wire traffic (or if you're doing end-to-end work, timestamps on the received packets) to see how adjusting the quantum affects what you're actually trying to achieve. If you are worried about beat effects, consider using a balanced PRNG to jitter your quantum around by a significant factor (I'd start at maybe +/- 30%). Then you can either leave the ppq value the same and get non-constant short term packet rates (but keeping the same long- term rate), or scale the ppq with the jitter factor to keep the short term packet rate constant but moving the bursts around to avoid e.g. scheduling quantum boundaries in whatever you're talking to. If it's critical that your quantum be particularly small, you might also want to consider using code inside the kernel; this can save you on the per-packet overheads you're currently paying for pushing them into the kernel. In the most extreme case, you could steal an interface from the network stack completely, again depending on what your ultimate goals might be. This email sent to site_archiver@lists.apple.com