NetBurner Community Forum

Hi I am new to netburner. I am working on a project that I need very fast serial to serial connection. I need to send about 8 byte of message stream coming to one serial RX every 15 msec to another serial TX less than 1 msec. and occasionally I need to add some other longer messages.

Before working on a code for serial to serial, I just want to see the response time of the board.
So I did the followings.
Connected my laptop directly to MOD5270 dev kit via ethernet cable.
Manually changed mod5270 IP to 10.1.1.1 using MTTY using nb> CLI
And assigned 10.1.1.3 to laptop
I loaded MOD5270factirydemo image using NBeclipse and confirmed image is working.

And then, I did continuously ping from my laptop to MD5270
Somehow, ping response time slow down periodically
My application has nothing to do with Ethernet as it involves serial.
but I am a little concerned with slow response time of ping.

Reply from 10.1.1.1: bytes=32 time=370ms TTL=60
Reply from 10.1.1.1: bytes=32 time=570ms TTL=60
Reply from 10.1.1.1: bytes=32 time=9ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=159ms TTL=60
Reply from 10.1.1.1: bytes=32 time=290ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=100ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=349ms TTL=60
Reply from 10.1.1.1: bytes=32 time=539ms TTL=60
Reply from 10.1.1.1: bytes=32 time=130ms TTL=60
Reply from 10.1.1.1: bytes=32 time=330ms TTL=60
Reply from 10.1.1.1: bytes=32 time=529ms TTL=60
Reply from 10.1.1.1: bytes=32 time=120ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=520ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=320ms TTL=60
Reply from 10.1.1.1: bytes=32 time=520ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=320ms TTL=60
Reply from 10.1.1.1: bytes=32 time=530ms TTL=60
Reply from 10.1.1.1: bytes=32 time=10ms TTL=60
Reply from 10.1.1.1: bytes=32 time=9ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=6ms TTL=60


I would like to know if MOD5270 is right board for my application.
( as repeated, I am working on a project that I need very fast serial to serial connection. I need to send about 8 byte of message stream coming to one serial RX every 15 msec to another serial TX less than 1 msec. and occasionally I need to add some other longer messages. )

Not sure I understand your post, but serial to serial does not involve the network. So what is the purpose of that test? I think the normal time is less than 1ms, which is pretty darn fast. The longer ones may be due to your PC doing an ARP request.

I just wanted to see the response time of the board as i can not measure serial to serial. Arp request is sent for the first time to resolve mac and IP address. But once it is resolved, there is no need to send arp request... If you ping any directly connected normal network device, you don't see this kind of ping delay. I am wondering if it has anything to do with priority, when I activate debug, the response time get faster.

Which version of the tools are you using? You can see this information in c:/nburn/release_tag

2.7.5

For comparison I ran a ping test on the same factory demo code and got the following results:


Pinging 10.1.1.107 with 32 bytes of data:
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60
Reply from 10.1.1.107: bytes=32 time<1ms TTL=60

Ping statistics for 10.1.1.107:
Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Connection is direct connection.

laptop (10.1.1.6) ------ MOD5270(10.1.1.1)

ping 10.1.1.1 -t (from 10.1.1.6)

I used wireshark to see what is going on and I did see periodic arp request from laptop. But it doesn't seem arp table update delays any traffic flow. It shouldn't affect echo reply response time (by MOD5270) for echo request (by laptop). Even if arp update delays traffic flow, it may delay intervals between echo requests not shouldn't affect echo reply time by MOD5270 for echo request sent by PC.

Anyway, in order to rule out any possibility of arp cache, I added static arp entry and confirmed (with wireshark) there is no more periodic arp update.
C:\Users\JK>arp -a
Interface: 10.1.1.6 --- 0x11
Internet Address Physical Address Type
10.1.1.1 00-03-f4-09-dd-02 static
10.1.1.255 ff-ff-ff-ff-ff-ff static

After static arp, continuous ping restarted and same periodic delays observed.
C:\Users\JK>ping 10.1.1.1 -t

Pinging 10.1.1.1 with 32 bytes of data:
Reply from 10.1.1.1: bytes=32 time=42ms TTL=60
Reply from 10.1.1.1: bytes=32 time=239ms TTL=60
Reply from 10.1.1.1: bytes=32 time=439ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=230ms TTL=60
Reply from 10.1.1.1: bytes=32 time=430ms TTL=60
Reply from 10.1.1.1: bytes=32 time=29ms TTL=60
Reply from 10.1.1.1: bytes=32 time=220ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=420ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=220ms TTL=60
Reply from 10.1.1.1: bytes=32 time=419ms TTL=60
Reply from 10.1.1.1: bytes=32 time=9ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=599ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time=389ms TTL=60
Reply from 10.1.1.1: bytes=32 time=589ms TTL=60
Reply from 10.1.1.1: bytes=32 time=179ms TTL=60
Reply from 10.1.1.1: bytes=32 time=372ms TTL=60
Reply from 10.1.1.1: bytes=32 time=570ms TTL=60
Reply from 10.1.1.1: bytes=32 time=170ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60
Reply from 10.1.1.1: bytes=32 time<1ms TTL=60

With wireshark, I confirmed the delays are caused by MOD5270

Same seq number is a pair of echo request/reply
the response time is less than 1ms for packet pairs of 62/63, 64/65, 66/67, 68/69
But it becomes around 500ms for packet pair of 70/71
and it becomes less than 1 ms for 72/73
And then there are constant longs delays for the following packet pairs... My main focus is serial link and I am not sure if this delay on ICMP packet means anything to serial link.
I would appreciate any explanation if this kind of delay won't occurs on serial to serial (read and write) .

Thank You

Do you have more than one network interface, such as wired and wifi? If so, are they on different subnets? What is the IP address and mask for each interface?

Guys

I found out what the cause was...It is not MOD5270. (also not arp update, not subnet/mask,...)
I almost went wrong direction. I had 100% of packets being around 1 ms response when I have my laptop ping a linux pc (with direct connection)... So I almost pointed my finger to MOD5270 because ping delays seemed to only occur when my laptop ping MOD5270.

But just in case, I added Netgear Hub between MOD5270 and laptop so that there is no direct connection between MOD5270 and laptop(win7). And all ping results were less than 1ms. (in fact, MOD5270 response time seems faster than linux PC...which is supposed to be as RTOS is faster than debian linux)

Maybe, I should've used cross-over ethernet cable Vs straight???(If that is the case, it shouldn't work at all???)

As I confirmed MOD5270 is fast, I am no longer interested in further digging into the problem.

However, any further comments are appreciated.