Re: high accuracy timing options?
Re: high accuracy timing options?
- Subject: Re: high accuracy timing options?
- From: "Aaron Turner" <email@hidden>
- Date: Sat, 29 Mar 2008 20:50:01 -0700
On Fri, Mar 28, 2008 at 10:12 PM, Michael Smith <email@hidden> wrote:
>
> On Mar 28, 2008, at 12:05 PM, email@hidden wrote:
>
> >> 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.
Reasonable theory... Honestly, something I've given some thought to,
but frankly, it's painfully hard to measure how much better/worse it
would work. Putting a sniffer on the wire doesn't help since the
receiving box is going to queue up the reads and I know pcap
timestamps are inaccurate (It's not that uncommon to see sequential
packet timestamps go backwards). At some point, you just have to do
your best and be done with it.
> 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.
One issue I'm dealing with is that I sometimes generate traffic
*through* devices- meaning both client & server side of the
connection. Beat effects are definitely an issue here and I'm not
sure adding some jitter is a workable solution. Probably worth
looking into sometime though. Using such a mechanisim could possibly
allow higher packet rates.
> 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.
Cross platform is probably one of the biggest goals. I develop on OS
X and most of my users use Linux, with some Solaris and *BSD thrown in
for good measure. Maybe one of these days I'll do kernel modules, but
for now I've got higher priorities. Right now my plan is to use
weighted averaging to simulate sub 1usec accuracy. Ie, if the rate
should be 7.7usec, I'll send 7 packets @ 8usec and 3 at 7usec.
> HTH.
Definitely... always appreciate some ideas.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden