Em Wednesday, 7 de February de 2007 18:55, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Hello to all.
> >
> > I'm runnig an RT apllication using RTAI 3.4 and rtnet 0.9.8.
> >
> >
> > I've found two different types of dropping packtes messages during the
> > execution of my application:
> >
> > "memory squeeze: dropping packet"
> > and
> > "dropping packet in rtnetif_rx"
>
> What comes first?
this is the result of the messages file (the first lines):
Feb 8 10:33:18 nav-aft kernel: Task CLogManagerRT start. 0xe0488220
Feb 8 10:53:16 nav-aft kernel: rteth0: Memory squeeze, dropping packet.
Feb 8 10:53:16 nav-aft kernel: rteth0: Memory squeeze, dropping packet.
Feb 8 10:53:16 nav-aft kernel: RTnet: dropping packet in rtnetif_rx()
Feb 8 10:53:16 nav-aft kernel: rteth0: Memory squeeze, dropping packet.
Feb 8 10:53:17 nav-aft kernel: rteth0: Memory squeeze, dropping packet.
Feb 8 10:53:17 nav-aft kernel: RTnet: dropping packet in rtnetif_rx
.............
>
> >
> >
> > I have one hard rt_task reading in a RAW socket. And 3 hard rt_task to
write
> > for different lans.
> >
> > And several different other rt_tasks to do some things in the application.
> > Several are in hard real time and others are in soft realtime.
> >
> > One thing that i've found strange is that when these errors (dropping
packet)
> > occur the hard real time tasks are stoped.
>
> Hmm, maybe they stop first and _then_ RTnet runs into troubles
> delivering packets. Where/on what do they block then?
>
> > The most part of they are periodic, and should be running anyway.
> >
> > The soft tasks still run with the correct period.
> > Theres any known malfunction with the hard real-time scheduler of RTAI??
> >
> > Or problem with RTnet framework that can cause this strange behaviour??
>
> You run into an overload situation /wrt incoming frames. To find out if
> this is application-driven or due to a bug in what subsystem soever, we
> have to analyse your priority setup first: are the receiver task
> together with RTnet's stack manager task the highest ones? Furthermore,
> can you run your scenario without further RT tasks except the receiver
> to reduce potential trouble sources?
My priority setup for all the task in the application is the following:
#define REAL_TIME_TASK_PRIORITY_NAV 4
#define REAL_TIME_TASK_PRIORITY_LOG 3
#define REAL_TIME_TASK_PRIORITY_LOG_MANAGER 8
#define REAL_TIME_TASK_PRIORITY_ETHERNET_MANAGER_READER 10
#define REAL_TIME_TASK_PRIORITY_GYRO_NAV_MANAGER 12
#define REAL_TIME_TASK_PRIORITY_TIME_MANAGER_READER 9
#define REAL_TIME_TASK_PRIORITY_TIME_MANAGER_WRITER 11
#define REAL_TIME_TASK_PRIORITY_ETHERNET_MANAGER_WRITER 13
#define REAL_TIME_TASK_PRIORITY_ANALOGIC_STATE 7
#define REAL_TIME_TASK_PRIORITY_MONITORING 8
#define REAL_TIME_TASK_PRIORITY_MANAGEMENT 8
#define REAL_TIME_TASK_PRIORITY_NAV_VALUES_SIMULATION 4
#define REAL_TIME_TASK_PRIORITY_NAV_SIMULATION_MANAGER 6
#define REAL_TIME_TASK_PRIORITY_FAILOVER_MANAGER 10
But presently are running:
TASK LOG (blocked in semaphore)
TASK ETHERNET_MANAGER_READER (blocked in the rt_recv_msg)
3 x TASK ETHERNET_MANAGER_WRITER (blocked in queue semaphores)
TASK GYRO_NAV_MANAGER (this task sends 1 message to LAN A and LAN B every 5 ms
interval (Periodic))
RTAI LXRT Real Time Task Scheduler.
Calibrated CPU Frequency: 2791143000 Hz
Calibrated interrupt to scheduler latency: 2943 ns
Calibrated oneshot timer setup_to_firing time: 999 ns
Number of RT CPUs in system: 1
Real time kthreads in resorvoir (cpu/#): (0/6)
Number of forced hard/soft/hard transitions: traps 0, syscalls 0
Priority Period(ns) FPU Sig State CPU Task HD/SF PID RT_TASK * TIME
------------------------------------------------------------------------------
1 1 Yes No 0x9 0:1 1 1 2610 e0698180 6
999999999 1 Yes No 0x9 0:1 2 1 2606 e0698c80 6
999999999 1 Yes No 0x9 0:1 3 1 2848 e005d500 6
1000000004 1 Yes No 0x0 0:1 4 0 4865 e0485220 0
1000000003 1 Yes No 0x9 0:1 5 0 4866 e0485a20 0
1000000008 1 Yes No 0x0 0:1 6 0 4878 e0486220 0
10 1 Yes No 0x9 0:1 7 1 4873 e0486a20 8
12 5000001 Yes No 0x5 0:1 8 1 4877 e0487220 8
13 1 Yes No 0x9 0:1 9 1 4874 e0487a20 8
13 1 Yes No 0x9 0:1 10 1 4875 e0488220 8
13 1 Yes No 0x9 0:1 11 1 4876 e0488a20 8
TIMED
> e0487220
READY
>
> [BTW, what packet burst to you expect at maximum? Check if
> CONFIG_RTNET_RX_FIFO_SIZE is large enough.]
CONFIG_RTNET_RX_FIFO_SIZE = 32 the default value.
I'm running in promisc mode and with ETH_P_ALL and made some SCP sessions to
other machine in the same network and no problem arises.
My application can take care of burst with no problems.
Jorge
>
> Jan
>
>
--
Jorge Almeida
[EMAIL PROTECTED]
DISCLAIMER: This message may contain confidential information or privileged
material and is intended only for the individual(s) named. If you are not a
named addressee and mistakenly received this message you should not copy or
otherwise disseminate it: please delete this e-mail from your system and notify
the sender immediately. E-mail transmissions are not guaranteed to be secure or
without errors as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete or contain viruses. Therefore, the sender does not
accept liability for any errors or omissions in the contents of this message
that arise as a result of e-mail transmissions. Please request a hard copy
version if verification is required. Critical Software, SA.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
RTnet-users mailing list
RTnet-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rtnet-users
