This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FreeBSD TCP/IP stack , time to send ?


On Tue, Feb 22, 2005 at 09:09:32AM -0700, Gary Thomas wrote:
> On Tue, 2005-02-22 at 17:14 +0100, sebastien Couret wrote:
> > Hi guyz,
> > 
> > I would like to know if the time to send a packet on an ethernet network with 
> > an ecos device could be bounded.
> >   
> > Let's imagine we have a perfectly silent ethernet network (no packets are 
> > currently transmitted) to avoid CSMA-CD retransmissions.
> > We have choosed to use FreeBSD TCP/IP stack port.
> > 
> > As TCP/IP stack work as two separated threads, i imagine that the scheduler 
> > must first pass control to one of those threads which could take a fixed time 
> > as ecOS is "realtime".
> > 
> > Can we garantee a maximal amount of time for sending and UDP datagram with 
> > eCOS or not ? 
> > 
> > If so, Is it realistic to believe it is possible to send it in 10ms ? 1ms ? 
> > 0.5 ms ? with a MPC8270 CPU on the embedded device. 
> 
> Packets are sent directly by the issuing thread unless the device
> is already busy/saturated.  Thus, the "time to send" is as fast
> as the processor can get it ready, which should be less than your
> smallest number of 0.5ms
> 
> The network stack only uses the auxiliary threads for processing
> incoming packets, not sending packets.

You can use this as a rule of thumb, but its no garentee. Just to list
a few things that can cause problems:

1) You have received a source quench from the device you are sending
the UDP packets to.

2) Your serial port is being bombarded by characters so generating
lots of interrupts, which means ISR & DSR it taking up large amounts
of CPU time.

3) Some other thread is currently sending a packet, so has the network
stack locked. You then need to wait for this sender to finish/sleep
before you can send anything.

4) Some higher priority thread has taken control of the CPU and does
not give it back again for a long time.

There is no such thing as a garentee in a soft real time OS.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]