On 25/02/10 02:56 AM, Rasmus Nielsen wrote:
> Hi all,
>
> I have a project where I need to transmit ethernet frames very deterministic, every 200us +/- 10%.
> I have tried using a bpf device which transmits packets via io-pkt. I call the write function from a pulse event timer
 (at priority 200) that is set to fire every 2 tics (I have set the tick rate to 100us).
> I have made some measurents on this, which shows that I get a mean time between frames transmitions of very close to 
200us, but I also see that the max time between frames is around 250us and the minimum time is around 150us, which is 
not quite good enough for my application.
> I have tried with other combinations of tick rate and tics per pulse event, but I cannot find a combination that 
performs better than the 100us/2 tics combination.
>    
You should first of all check the docs to see what precision you can 
expect from a pulse event timer you're using.

PS. I think somebody was asking a similar question in the one  of the 
networking forums earlier. You may be able to search it out again.

> My HW is a 600 MHz MPC8377 processor with integrated ethernet controllers.
>
> Does any one have an idea where this jitter comes from, and how I can minimize it?
>
> Wold it be posible to transmit frames from a interrupt routine?
> (I have a 200us HW interrupt to the processor)
>    
Probably, you've got to be careful what you do inside an ISR though.

You'd probably want to load your app into io-pkt as an lsm. That way 
you're also "closer" to the actual transmitting code, i.e. you eliminate 
the step from app to io-pkt. See wiki about lsms and the code has 
examples how do write an lsm, e.g. autoip, nraw, qnet.

/P

> where this jitter comes from

Have you looked at a kernel trace yet?  You should find
out what other interrupts are firing in the system, and
what other (eg high priority) processes might be pre-empting
you.

Also, ensure that periodic MDI PHY probing in your 
ethernet driver is turned off.  It should be by default, 
but if it is occurring, it can cause these sorts of problems.

Also, ensure in the driver devctl that when an application
collects statistics (eg shelf) that it does not do an unnecessary
amount of processing with the mutex held.  IIRC the speedo
driver had a PR about this a while back.

I wouldn't jump headfirst into putting everything in the
ISR until you have exhausted all of the above.  It might 
be something simple.

Historical note:  when I was young and foolish, I wrote
the entire QNX 4.0 arcnet driver in thousands of lines
of assembly.  In the quest for wire rate, it did far more
than it really needed to in the isr!

--
aboyd