Re: [ECOS] Loss frames In UDP, full Duplex asynchronous mode

["Roy E Richardson" <eng_at_play at cox dot net>]

I don't know if this applies in this instances, but older MPC platform did 
have noted "data caching"  macro issues
when attempting to use "HAL_DCACHE_FLUSH()" to ensure the buffer'd area is 
forced to ram before the I/O operation occurs.  With the errors, if the base 
address and length of the buffer are not both multpiles of 16. (cache 
segment size), then the transmission could be outputting stale DRam values 
(all cached write values not delivered as one expects).

The primary liability in 
\packages\hal\powerpc\...\current\include\var_cache.h, is the assumption 
that the base address is a multiple of the cache sement size - not 
necessarily true...

Granted this is an "off the wall" potential, but it is one that could occur. 
We'd believed to have experienced it, though it's difficult to prove. One 
requires the ability to capture the outbound strem, rather large amounts 
thereof, and then trying to parse same is a pain. .

----- Original Message ----- 
From: <e.coullien@faiveley.com>
To: <ecos-discuss@sources.redhat.com>
Sent: Monday, September 05, 2005 4:00 AM
Subject: [ECOS] Loss frames In UDP, full Duplex asynchronous mode


> Hi,
>
> We lost UDP frames in full Duplex and asynchronous Send/Receive mode but 
> not in
> an Receive/Answer mode.
>
> We tried 2 tests :
>
> 1) Synchronous mode : a PC send frames to the board every 20ms, and when
> receiving a frame, the board send an answer frame. In this synchronous
> configuration no problem was found. It works find !
>
> 2) Asynchronous mode : a board send frames to the PC every 20ms, and the 
> PC send
> a frame every second without synchronisation on the reception.
> As the frame contains an incremental counter, we add some tests in the 
> file
> IF_FCC ("fcc_eth_int" and "fcc_eth_RxEvent" fonctions ) to detect a 
> missing
> frame. Then we saw that we lost some frames. We are sure that the PC send 
> the
> frame by analysing the communication with the Ethereal ethernet analyser.
>
> We just tested it on a PowerPC board because we don't have other board.
> Does someone ever find this kind of problem on an other board or have you 
> an
> idea how to search an explanation ?
>
>
> Thanks,
>
> E. Coullien
>
>
>
> NOTE : CE COURRIER ELECTRONIQUE EST DESTINE EXCLUSIVEMENT AU(X) 
> DESTINATAIRE(S) MENTIONNE(S) CI-DESSUS ET PEUT CONTENIR DES INFORMATIONS 
> PRIVILEGIEES, CONFIDENTIELLES ET/OU ET/OU NON SOUMISES A DIVULGATION AUX 
> TERMES DES LOIS APPLICABLES .  SI VOUS AVEZ RECU CE MESSAGE PAR ERREUR , 
> OU S'IL NE VOUS EST PAS DESTINE, VEUILLEZ  LES SIGNALER IMMEDIATEMENT A 
> L'EXPEDITEUR ET EFFACER CE COURRIER ELECTRONIQUE.
>
> NOTE: This e-mail message is intended only for the named recipient(s) 
> above and may contain information that is privileged, confidential and/or 
> exempt from disclosure under applicable law.  If you have received this 
> message in error, or are not the named recipient(s), please immediately 
> notify the sender and delete this e-mail message.
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



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