Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[HELP]UDP TX/RX packet mismatch problem...

311 views
Skip to first unread message

chihwankim

unread,
Jan 10, 2002, 3:02:16 AM1/10/02
to
I have two MPC8260 boards A and B. I open UDP socket both of them and try to
transmit and receive UDP packets for each size of datagram. I assume that A
is transmitting UDP datagram to B every each 10ms and B is receiving
datagram from A.

For 256/512/1024 bytes of datagram, there is no error in the receiving side.
But 64/128 bytes of datagram, there occurs missed packets in the receiving
side.

So, I added some debugging code to check every ethernet packet to count the
number of packets with specified UDP port in BSP. But results is just the
same with above.

Anyone has some ideas about this problem?
Thanks.
chkim in korea.


joe durusau

unread,
Jan 10, 2002, 6:39:18 AM1/10/02
to
Sounds like you might be having collisions. Note that UDP is dy definition
not guaranteed to work. You need either an absolutely quiet net into which
to transmit, or some higher level has to check for errors and arrange for
re-transmission if required.

Speaking only for myself,

Joe Durusau

David Laight

unread,
Jan 10, 2002, 10:32:19 AM1/10/02
to
joe durusau wrote:
>
> Sounds like you might be having collisions. Note that UDP is dy
> definition
> not guaranteed to work. You need either an absolutely quiet net into which
> to transmit, or some higher level has to check for errors and arrange for
> re-transmission if required.

Not collisions - they are completely benign. The ethernet MAC engine
will automatically retransmit them.


>
> Speaking only for myself,
>
> Joe Durusau
>
> chihwankim wrote:
>
> > I have two MPC8260 boards A and B. I open UDP socket both of them and try to
> > transmit and receive UDP packets for each size of datagram. I assume that A
> > is transmitting UDP datagram to B every each 10ms and B is receiving
> > datagram from A.

Are you sure you are sending one every 10ms?
That is only 100/sec nothing should fail at that data rate!


> >
> > For 256/512/1024 bytes of datagram, there is no error in the receiving side.
> > But 64/128 bytes of datagram, there occurs missed packets in the receiving
> > side.

So big packets are ok, but you get errors with small ones.
Mmmmmm....

If you really do have the tx rate capped properly then something is
definitely awol in the receiving system.

If you don't have the tx rate capped, then you are probably seeing
the effect of marginally different costs in transmitting and
receiving packets. (cost/byte + cost/packet)

Check with some LAN monitor software that the packets are all txed.

David

Dan Gold

unread,
Jan 10, 2002, 12:59:58 PM1/10/02
to
In article <3C3DB452...@l8s.co.uk>, David Laight says...

>
>>> chihwankim wrote:
>>
>> > I have two MPC8260 boards A and B. I open UDP socket both of them and try to
>> > transmit and receive UDP packets for each size of datagram. I assume that A
>> > is transmitting UDP datagram to B every each 10ms and B is receiving
>> > datagram from A.
>

Are these custom 8260 designs or evaluation boards ? And the software (i.e. the
drivers) ?
Did you do the port, or are they stock ? Are you sure you have the latest
drivers ? I know WRS
has fixed at least 1 or 2 bugs in the FCC driver...

I'm assuming this is Ethernet on the FCC, not SCC. And do you only have 1 FCC
active ?


>> >
>> > For 256/512/1024 bytes of datagram, there is no error in the receiving side.
>> > But 64/128 bytes of datagram, there occurs missed packets in the receiving
>> > side.
>
>So big packets are ok, but you get errors with small ones.
>Mmmmmm....
>
>If you really do have the tx rate capped properly then something is
>definitely awol in the receiving system.
>
>If you don't have the tx rate capped, then you are probably seeing
>the effect of marginally different costs in transmitting and
>receiving packets. (cost/byte + cost/packet)
>
>Check with some LAN monitor software that the packets are all txed.

The original poster said he added some code in the BSP to
count packets with the correct UDP port - was that on the Tx or Rx side ?
If it was the Rx, you might want to add code to the Tx side to make
sure all packets are getting Tx'd. Also, do you see any MAC layer
Tx or Rx errors ? If you're sure the packets are being Tx'd, you might
{ip,udp}StatShow and see if they tell you anything.

See what statistics are available to you from the driver on both Tx and
Rx sides, that may give some clue.

hth,

Dan Gold go...@ensemble.com

chihwankim

unread,
Jan 10, 2002, 10:38:04 PM1/10/02
to
Well, thanks for your comments.
To make sure that TX side successfully transmitted its packet, I made
another test. 8260 A(TX side) transmits its packet periodically(10 ms) to PC
and then PC sends to 8260 B(RX side) the same data whenever it receives from
8260 A. PC is based on window 2000 operating system.

The result shows that PC received all the datagram from 8260 A without any
missing, but 8260 B still has missed packets. The ratio is just the same
with 8260 to 8260 case.

And I added a code in BSP ethernet driver to check TX packets with specified
UDP port, and the count is just the same with
application-transmitted-packets.

For understanding, below is the result of udpstatShow() when TX count=5328,
RX count=5324(4 missing)
----------------------------------------------------------------
TX side
-> udpstatShow
UDP:
5343 total packets
15 input packets
5328 output packets
0 incomplete header
0 bad data length field
0 bad checksum
12 broadcasts received with no ports
0 full socket
3 pcb cache lookups failed
3 pcb hash lookups failed

RX side
-> udpstatShow
UDP:
5324 total packets
5324 input packets
0 output packets
0 incomplete header
0 bad data length field
0 bad checksum
1 broadcasts received with no ports
0 full socket
5323 pcb cache lookups failed
3 pcb hash lookups failed
----------------------------------------------------------------

What can I do further?
thanks.

"Dan Gold" <nos...@newsranger.com> wrote in message
news:yEk%7.11864$cD4....@www.newsranger.com...

Graham Baxter

unread,
Jan 11, 2002, 12:00:50 PM1/11/02
to
I had a similar problem when I configured the TX and RX clocks the wrong
way around.

They were close enough to each other to work most of the time!

Packet loss was 3-4%.

--


Regards,


Graham Baxter (VxWorks and pSOS BSP'S)
Freelance Software Engineer
gba...@NOSPAM.bcs.org.uk

chihwankim

unread,
Jan 16, 2002, 9:00:39 PM1/16/02
to
Oh, thanks for your comments.
Would you let me know how to solve that probelm? Did you fix BSP or
hardware?

thanks.
chkim
"Graham Baxter" <gba...@NOSPAM.bcs.org.uk> wrote in message
news:3C3F1A42...@NOSPAM.bcs.org.uk...

Graham Baxter

unread,
Jan 17, 2002, 3:56:57 AM1/17/02
to
I just had to modify the CMXFCR register to set the correct clocks for
my hardware. The BSP used CLK10 for TX and CLK9 for RX. My hardware had
the clocks the other way around.
0 new messages