If I understood what you were actually trying to do, I might have
some
better ideas...
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.
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.
HTH.
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
