PC386 Clock Tick Driver

[Tim Cussins]

Hi SAeeD,

On 18/07/13 23:30, SAeeD wrote:
> Hi Tim,
> 
>     10us per system tick seems incredibly low. If your processor is handling
>     a tick every 10us, are you sure there's enough cycles left to do
>     meaningful work?
> 
> It is very low tick, I agree. We have a system which generates a burst
> of packets up to 12900 #packet/s and this is why we need 10 us clock tick.
> The system has only one task which is responsible for sending packets so
> there is no concern about servicing other tasks.
> And by the way, I want to find out why this value for clock_tick causes
> this error, I'm afraid it may happen in other circumstances as well.
> 

I'm still not convinced you *need* a 10us tick. It sounds like the
software architecture could use a fresh set of eyes :) More on this in a
second...

The tick rates you'll see in the real world are orders of magnitude
higher than this. However, you point out that you have only 1 thread (an
idle task too, I presume?). So it's understandable that you've been
getting away with it.

So your high tick rate is probably enough, as Joel has pointed out, to
stress the interrupt handling code, and expose a real bug. If you can
fix it, then you'll get a high-five from me :D

(12900 packets later...)

That said, I strongly recommend running your architecture past another
engineer to get their thoughts: Perhaps even a friend or loved-one.

1. Can I assume that your 10us figure is related to the minimum packet
interval at 12900p/s i.e. 77.5us?

What about a tick period of 77.5us? OK, so I'm not serious about that
figure, but choosing 10us seems like a conveniently 'round' number. You
might not have the processor/memory/interrupt bandwidth to support 10us.
How about 20us? 40us? That could get you out of jail without any other
software changes.

2. Packet throughput vs jitter. Perhaps your packet sending/receiving
hardware is more tolerant of packet jitter than you think. Send/Recv
buffers are everywhere. Why not send, for example, a maximum of 2
packets every 100us?

[edit] To make this point a little more strongly: Are you only trying to
manage packet bandwidth, or is packet jitter a concern too?

3. My way. Personally, I would queue the packets for transmission in a
thread, but have them sent from within a timer (dedicated) interrupt
handler. Packet jitter will be more bounded, perhaps even beautiful to
some...



You've asserted that a 3.3GHz machine should be cool. Bear in mind that
the NXP device you've mentioned probably has better interrupt latency
[the time from interrupt line assertion until the first instruction of
the interrupt handler]: There's more to it than pure CPU clock speed.
The scheduler has to run, decide to schedule your transmitter thread, do
the context switch, and return from interrupt *before* the next tick.
And that's not even leaving time for your thread to run :)

I think Joel is suggesting that you might be getting another interrupt
before the tick handler has returned. Check that.

Maybe go back to the NXP platform, use a GPIO pin to show what
proportion of your time is spent within the tick handler. It's probably
more than you realise :)

As you've probably realised by now, blah blah blah.

Anyway, HTH.
Tim