Sign in
Search AT91SAM
Subscribe to AT91SAM
Sponsor
Ads
Discussion Groups
See Also
Discussion Groups | AT91SAM ARM | performance guesstimate for TCP/IP stack
For users of the Atmel AT91SAM7 and AT91SAM9 ARM CPU chips. Atmel has taken a new direction by combining on chip flash and ram with the ARM CPU on a single die. This provides low cost devices for small systems using the ARM CPU. This group is to exchange information to help users get started and learn how to use the devices.
performance guesstimate for TCP/IP stack - elso...@pico-systems.com - Jul 16 2:06:06 2009
I have an application that looks like the AT91SAM7Xnnn would be a good fit, but I have no
idea whatsoever on the performance. It is a real time motion control system, so it has to
meet the requirements or it is a waste of time to even begin. So, here is what I'm trying
to do :
A PC running real time Linux will ask for encoder position say, 1000 times a second. The PC sends a request to the ARM via 100 Mbit Ethernet containing a list of register ranges to read. The ARM unpacks the packet and does the I/O to the attached FPGA through a bi-directional 8-bit port. I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as the ARM will only be a couple inches away. The ARM builds a response packet and sends it to the PC. The PC computes new velocities and sends another packet to the ARM, which requires no reply. I would think UDMP would be OK for this, and less overhead. The communication to the attached FPGA should be VERY simple code, a loop that executes a couple hundred instructions total, so that shouldn't take much time at all, maybe 10-25 us. I would hope to avoid using an RTOS for such a simple task, but maybe the TCP/IP stack depends on it, I know so little about this environment.
So, my question is, how long will it take the ARM to handle the Ethernet protocol? If the answer is tens of us, then this is great! if it is hundreds of us, it won't work, as we have to receive 2 packets and send one, every millisecond. And, we would like to be able to turn up the rate in some cases. We do this now using the PC parallel port in EPP mode, and can go to 2-5 KHz servo update rate, depending on the CPU, whether the par port is MoBo or PCI and the number of registers to be read/written.
Thanks in advance for any hard performance data that anyone can offer.
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
A PC running real time Linux will ask for encoder position say, 1000 times a second. The PC sends a request to the ARM via 100 Mbit Ethernet containing a list of register ranges to read. The ARM unpacks the packet and does the I/O to the attached FPGA through a bi-directional 8-bit port. I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as the ARM will only be a couple inches away. The ARM builds a response packet and sends it to the PC. The PC computes new velocities and sends another packet to the ARM, which requires no reply. I would think UDMP would be OK for this, and less overhead. The communication to the attached FPGA should be VERY simple code, a loop that executes a couple hundred instructions total, so that shouldn't take much time at all, maybe 10-25 us. I would hope to avoid using an RTOS for such a simple task, but maybe the TCP/IP stack depends on it, I know so little about this environment.
So, my question is, how long will it take the ARM to handle the Ethernet protocol? If the answer is tens of us, then this is great! if it is hundreds of us, it won't work, as we have to receive 2 packets and send one, every millisecond. And, we would like to be able to turn up the rate in some cases. We do this now using the PC parallel port in EPP mode, and can go to 2-5 KHz servo update rate, depending on the CPU, whether the par port is MoBo or PCI and the number of registers to be read/written.
Thanks in advance for any hard performance data that anyone can offer.
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - Caglar Akyuz - Jul 16 2:59:37 2009
On Thursday 16 July 2009 09:02:49 e...@pico-systems.com wrote:
> I have an application that looks like the AT91SAM7Xnnn would be a good
> fit, but I have no idea whatsoever on the performance. It is a real time
> motion control system, so it has to meet the requirements or it is a waste
> of time to even begin. So, here is what I'm trying to do :
>
> A PC running real time Linux will ask for encoder position say, 1000 times
> a second. The PC sends a request to the ARM via 100 Mbit Ethernet
> containing a list of register ranges to read. The ARM unpacks the packet
> and does the I/O to the attached FPGA through a bi-directional 8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as
> the ARM will only be a couple inches away. The ARM builds a response
> packet and sends it to the PC. The PC computes new velocities and sends
> another packet to the ARM, which requires no reply. I would think UDMP
> would be OK for this, and less overhead. The communication to the attached
> FPGA should be VERY simple code, a loop that executes a couple hundred
> instructions total, so that shouldn't take much time at all, maybe 10-25
> us. I would hope to avoid using an RTOS for such a simple task, but maybe
> the TCP/IP stack depends on it, I know so little about this environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet
> protocol? If the answer is tens of us, then this is great! if it is
> hundreds of us, it won't work, as we have to receive 2 packets and send
> one, every millisecond. And, we would like to be able to turn up the rate
> in some cases. We do this now using the PC parallel port in EPP mode, and
> can go to 2-5 KHz servo update rate, depending on the CPU, whether the par
> port is MoBo or PCI and the number of registers to be read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
SAM7x can do 5-7 Mbps easly on ethernet port,
can reach 10Mbps with an optimized stack. I can't say anything on the latency
for sure, but I guess tens of usec is a little bit optimistic. In the end
ethernet is not a real time protocol and it will fail to meet this time
constraint on the marginals even it may on the average.
You can run TCP/IP stack with or without an RTOS.
Regards,
Caglar
> Jon
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> I have an application that looks like the AT91SAM7Xnnn would be a good
> fit, but I have no idea whatsoever on the performance. It is a real time
> motion control system, so it has to meet the requirements or it is a waste
> of time to even begin. So, here is what I'm trying to do :
>
> A PC running real time Linux will ask for encoder position say, 1000 times
> a second. The PC sends a request to the ARM via 100 Mbit Ethernet
> containing a list of register ranges to read. The ARM unpacks the packet
> and does the I/O to the attached FPGA through a bi-directional 8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as
> the ARM will only be a couple inches away. The ARM builds a response
> packet and sends it to the PC. The PC computes new velocities and sends
> another packet to the ARM, which requires no reply. I would think UDMP
> would be OK for this, and less overhead. The communication to the attached
> FPGA should be VERY simple code, a loop that executes a couple hundred
> instructions total, so that shouldn't take much time at all, maybe 10-25
> us. I would hope to avoid using an RTOS for such a simple task, but maybe
> the TCP/IP stack depends on it, I know so little about this environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet
> protocol? If the answer is tens of us, then this is great! if it is
> hundreds of us, it won't work, as we have to receive 2 packets and send
> one, every millisecond. And, we would like to be able to turn up the rate
> in some cases. We do this now using the PC parallel port in EPP mode, and
> can go to 2-5 KHz servo update rate, depending on the CPU, whether the par
> port is MoBo or PCI and the number of registers to be read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
SAM7x can do 5-7 Mbps easly on ethernet port,
can reach 10Mbps with an optimized stack. I can't say anything on the latency
for sure, but I guess tens of usec is a little bit optimistic. In the end
ethernet is not a real time protocol and it will fail to meet this time
constraint on the marginals even it may on the average.
You can run TCP/IP stack with or without an RTOS.
Regards,
Caglar
> Jon
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
RE: performance guesstimate for TCP/IP stack - Microbit_P43000 - Jul 16 3:14:17 2009
Hi,
I can't offer any 'hard' data (well, it's actually pretty limp, to quote 'True Lies :-),
but just a couple of suggestions :
Is this motion control loop only for velocity, or also for positioning?
If it's just velocity, I would proceed with peace of mind, regardless of Ethernet
performance.
If you need position, I would (but that's me) shy away from an Ethernet link.
Finally, still bear in mind that the trajectory generation algorithm "steers" the loop,
while
the PID (invariably running in an Interrupt) "lags" behind, constantly trying to correct
velocity
or whatever parameter(s) is/are controlled.
So basically, if there's some lag, I wouldn't worry too much. The PID lags anyway.
What I _would worry about is a _inconsistent_ lag for the control loop feedback.
Probably not much help, but perhaps some input to give more food for thought ?
For example, perhaps you could use lower size MTUs, and then always pad out the UDP
packets,
in an attempt to get a reasonably consistent overhead ?
It will also depend on whether this link is private between control unit and controlled
device, or whether you need to set up more parties on that Ethernet link, I guess...
HTH
Best Regards,
Kris
> -----Original Message-----
> From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
> e...@pico-systems.com
> Sent: Thursday, 16 July 2009 4:03 PM
> To: A...@yahoogroups.com
> Subject: [AT91SAM] performance guesstimate for TCP/IP stack
>
> I have an application that looks like the AT91SAM7Xnnn would be a good fit, but I have
no idea
> whatsoever on the performance. It is a real time motion control system, so it has to
meet the
> requirements or it is a waste of time to even begin. So, here is what I'm trying to do
:
>
> A PC running real time Linux will ask for encoder position say, 1000 times a second.
The PC
> sends a request to the ARM via 100 Mbit Ethernet containing a list of register ranges to
read. The
> ARM unpacks the packet and does the I/O to the attached FPGA through a bi-directional
8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as the ARM will
only be a
> couple inches away. The ARM builds a response packet and sends it to the PC. The PC
> computes new velocities and sends another packet to the ARM, which requires no reply. I
would
> think UDMP would be OK for this, and less overhead. The communication to the attached
FPGA
> should be VERY simple code, a loop that executes a couple hundred instructions total, so
that
> shouldn't take much time at all, maybe 10-25 us. I would hope to avoid using an RTOS
for such a
> simple task, but maybe the TCP/IP stack depends on it, I know so little about this
environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet protocol? If
the answer is
> tens of us, then this is great! if it is hundreds of us, it won't work, as we have to
receive 2 packets
> and send one, every millisecond. And, we would like to be able to turn up the rate in
some cases.
> We do this now using the PC parallel port in EPP mode, and can go to 2-5 KHz servo
update rate,
> depending on the CPU, whether the par port is MoBo or PCI and the number of registers to
be
> read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
> Jon
> ------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
I can't offer any 'hard' data (well, it's actually pretty limp, to quote 'True Lies :-),
but just a couple of suggestions :
Is this motion control loop only for velocity, or also for positioning?
If it's just velocity, I would proceed with peace of mind, regardless of Ethernet
performance.
If you need position, I would (but that's me) shy away from an Ethernet link.
Finally, still bear in mind that the trajectory generation algorithm "steers" the loop,
while
the PID (invariably running in an Interrupt) "lags" behind, constantly trying to correct
velocity
or whatever parameter(s) is/are controlled.
So basically, if there's some lag, I wouldn't worry too much. The PID lags anyway.
What I _would worry about is a _inconsistent_ lag for the control loop feedback.
Probably not much help, but perhaps some input to give more food for thought ?
For example, perhaps you could use lower size MTUs, and then always pad out the UDP
packets,
in an attempt to get a reasonably consistent overhead ?
It will also depend on whether this link is private between control unit and controlled
device, or whether you need to set up more parties on that Ethernet link, I guess...
HTH
Best Regards,
Kris
> -----Original Message-----
> From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
> e...@pico-systems.com
> Sent: Thursday, 16 July 2009 4:03 PM
> To: A...@yahoogroups.com
> Subject: [AT91SAM] performance guesstimate for TCP/IP stack
>
> I have an application that looks like the AT91SAM7Xnnn would be a good fit, but I have
no idea
> whatsoever on the performance. It is a real time motion control system, so it has to
meet the
> requirements or it is a waste of time to even begin. So, here is what I'm trying to do
:
>
> A PC running real time Linux will ask for encoder position say, 1000 times a second.
The PC
> sends a request to the ARM via 100 Mbit Ethernet containing a list of register ranges to
read. The
> ARM unpacks the packet and does the I/O to the attached FPGA through a bi-directional
8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as the ARM will
only be a
> couple inches away. The ARM builds a response packet and sends it to the PC. The PC
> computes new velocities and sends another packet to the ARM, which requires no reply. I
would
> think UDMP would be OK for this, and less overhead. The communication to the attached
FPGA
> should be VERY simple code, a loop that executes a couple hundred instructions total, so
that
> shouldn't take much time at all, maybe 10-25 us. I would hope to avoid using an RTOS
for such a
> simple task, but maybe the TCP/IP stack depends on it, I know so little about this
environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet protocol? If
the answer is
> tens of us, then this is great! if it is hundreds of us, it won't work, as we have to
receive 2 packets
> and send one, every millisecond. And, we would like to be able to turn up the rate in
some cases.
> We do this now using the PC parallel port in EPP mode, and can go to 2-5 KHz servo
update rate,
> depending on the CPU, whether the par port is MoBo or PCI and the number of registers to
be
> read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
> Jon
> ------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - 42Bastian - Jul 16 3:27:22 2009
e...@pico-systems.com schrieb:
> So, my question is, how long will it take the ARM to handle the
> Ethernet protocol? If the answer is tens of us, then this is great!
> if it is hundreds of us, it won't work, as we have to receive 2
> packets and send one, every millisecond. And, we would like to be
> able to turn up the rate in some cases. We do this now using the PC
> parallel port in EPP mode, and can go to 2-5 KHz servo update rate,
I doubt that you can do faster with a ARM via Ethernet.
Even if you go down to the bare metal and handling UDP w/o a stack (what
I would do).
But I would move more of the computation into the ARM instead of using
it simply as I/O expander.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> So, my question is, how long will it take the ARM to handle the
> Ethernet protocol? If the answer is tens of us, then this is great!
> if it is hundreds of us, it won't work, as we have to receive 2
> packets and send one, every millisecond. And, we would like to be
> able to turn up the rate in some cases. We do this now using the PC
> parallel port in EPP mode, and can go to 2-5 KHz servo update rate,
I doubt that you can do faster with a ARM via Ethernet.
Even if you go down to the bare metal and handling UDP w/o a stack (what
I would do).
But I would move more of the computation into the ARM instead of using
it simply as I/O expander.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - Chris DeLise - Jul 16 8:22:21 2009
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing
about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much
tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus
overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I
think 100uS should be very attainable.
----- Original Message -----
From: Caglar Akyuz
To: A...@yahoogroups.com
Sent: Thursday, July 16, 2009 2:58 AM
Subject: Re: [AT91SAM] performance guesstimate for TCP/IP stack
On Thursday 16 July 2009 09:02:49 e...@pico-systems.com wrote:
> I have an application that looks like the AT91SAM7Xnnn would be a good
> fit, but I have no idea whatsoever on the performance. It is a real time
> motion control system, so it has to meet the requirements or it is a waste
> of time to even begin. So, here is what I'm trying to do :
>
> A PC running real time Linux will ask for encoder position say, 1000 times
> a second. The PC sends a request to the ARM via 100 Mbit Ethernet
> containing a list of register ranges to read. The ARM unpacks the packet
> and does the I/O to the attached FPGA through a bi-directional 8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as
> the ARM will only be a couple inches away. The ARM builds a response
> packet and sends it to the PC. The PC computes new velocities and sends
> another packet to the ARM, which requires no reply. I would think UDMP
> would be OK for this, and less overhead. The communication to the attached
> FPGA should be VERY simple code, a loop that executes a couple hundred
> instructions total, so that shouldn't take much time at all, maybe 10-25
> us. I would hope to avoid using an RTOS for such a simple task, but maybe
> the TCP/IP stack depends on it, I know so little about this environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet
> protocol? If the answer is tens of us, then this is great! if it is
> hundreds of us, it won't work, as we have to receive 2 packets and send
> one, every millisecond. And, we would like to be able to turn up the rate
> in some cases. We do this now using the PC parallel port in EPP mode, and
> can go to 2-5 KHz servo update rate, depending on the CPU, whether the par
> port is MoBo or PCI and the number of registers to be read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
SAM7x can do 5-7 Mbps easly on ethernet port,
can reach 10Mbps with an optimized stack. I can't say anything on the latency for sure, but I guess tens of usec is a little bit optimistic. In the end ethernet is not a real time protocol and it will fail to meet this time constraint on the marginals even it may on the average.
You can run TCP/IP stack with or without an RTOS.
Regards,
Caglar
> Jon
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.387 / Virus Database: 270.13.15/2239 - Release Date: 07/15/09 06:07:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
----- Original Message -----
From: Caglar Akyuz
To: A...@yahoogroups.com
Sent: Thursday, July 16, 2009 2:58 AM
Subject: Re: [AT91SAM] performance guesstimate for TCP/IP stack
On Thursday 16 July 2009 09:02:49 e...@pico-systems.com wrote:
> I have an application that looks like the AT91SAM7Xnnn would be a good
> fit, but I have no idea whatsoever on the performance. It is a real time
> motion control system, so it has to meet the requirements or it is a waste
> of time to even begin. So, here is what I'm trying to do :
>
> A PC running real time Linux will ask for encoder position say, 1000 times
> a second. The PC sends a request to the ARM via 100 Mbit Ethernet
> containing a list of register ranges to read. The ARM unpacks the packet
> and does the I/O to the attached FPGA through a bi-directional 8-bit port.
> I can speed up what is now an IEEE-1284 (parallel port EPP-mode) port as
> the ARM will only be a couple inches away. The ARM builds a response
> packet and sends it to the PC. The PC computes new velocities and sends
> another packet to the ARM, which requires no reply. I would think UDMP
> would be OK for this, and less overhead. The communication to the attached
> FPGA should be VERY simple code, a loop that executes a couple hundred
> instructions total, so that shouldn't take much time at all, maybe 10-25
> us. I would hope to avoid using an RTOS for such a simple task, but maybe
> the TCP/IP stack depends on it, I know so little about this environment.
>
> So, my question is, how long will it take the ARM to handle the Ethernet
> protocol? If the answer is tens of us, then this is great! if it is
> hundreds of us, it won't work, as we have to receive 2 packets and send
> one, every millisecond. And, we would like to be able to turn up the rate
> in some cases. We do this now using the PC parallel port in EPP mode, and
> can go to 2-5 KHz servo update rate, depending on the CPU, whether the par
> port is MoBo or PCI and the number of registers to be read/written.
>
> Thanks in advance for any hard performance data that anyone can offer.
>
SAM7x can do 5-7 Mbps easly on ethernet port,
can reach 10Mbps with an optimized stack. I can't say anything on the latency for sure, but I guess tens of usec is a little bit optimistic. In the end ethernet is not a real time protocol and it will fail to meet this time constraint on the marginals even it may on the average.
You can run TCP/IP stack with or without an RTOS.
Regards,
Caglar
> Jon
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.387 / Virus Database: 270.13.15/2239 - Release Date: 07/15/09 06:07:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - elso...@pico-systems.com - Jul 17 12:34:41 2009
Chris DeLise wrote:
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: performance guesstimate for TCP/IP stack - Chris DeLise - Jul 17 12:46:25 2009
Hi Jon,
The only reason I ran at 10 Mbit was that was the only hub I had. A switch wouldn't let me "tap" into the signal. But even at 10Mb/s a nominal 64-byte packet takes 6.4uS of air time, add this both directions and you're talking an extra 12uS more than running at 100Mb/s. In my case the goal was to handle 1000 packets/s which was easily attained. Your goal will be a bit harder....
I agree with your running on a dedicated segment. If windows is part of it, make sure to disable all the bindings for Netbios, NetBeui, Wins, etc. as these add a bunch of junk packets your atmel doesn't want to see. I found the Atmel sample ethernet driver was helpful as well.
Hope it helps, and have fun! It's pretty cool to do tcp at the device level...
Chris
----- Original Message -----
From: e...@pico-systems.com
To: A...@yahoogroups.com
Sent: Friday, July 17, 2009 12:33 PM
Subject: [AT91SAM] Re: performance guesstimate for TCP/IP stack
Chris DeLise wrote:
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.18/2243 - Release Date: 07/17/09 06:08:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
The only reason I ran at 10 Mbit was that was the only hub I had. A switch wouldn't let me "tap" into the signal. But even at 10Mb/s a nominal 64-byte packet takes 6.4uS of air time, add this both directions and you're talking an extra 12uS more than running at 100Mb/s. In my case the goal was to handle 1000 packets/s which was easily attained. Your goal will be a bit harder....
I agree with your running on a dedicated segment. If windows is part of it, make sure to disable all the bindings for Netbios, NetBeui, Wins, etc. as these add a bunch of junk packets your atmel doesn't want to see. I found the Atmel sample ethernet driver was helpful as well.
Hope it helps, and have fun! It's pretty cool to do tcp at the device level...
Chris
----- Original Message -----
From: e...@pico-systems.com
To: A...@yahoogroups.com
Sent: Friday, July 17, 2009 12:33 PM
Subject: [AT91SAM] Re: performance guesstimate for TCP/IP stack
Chris DeLise wrote:
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.18/2243 - Release Date: 07/17/09 06:08:00
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: performance guesstimate for TCP/IP stack - ChuaLaiTi - Jul 18 15:25:11 2009
Hi Jon,
If your application does not need to be part of TCP/IP network, I think you just need to have ethernet frame with your application header. If I were you, I would get two sam7 evaluation boards and modify its ethernet sample codes. One of the board transmit and recevie in the ethernet frames and another board loop back the frames. The 1st board would toggle the GPIO whenever it receives the packet. You could analyze the performance by using Oscilloscope that probes the GPIO.
You could further optimize the speed by running the codes out of sram and compile the codes at high optimization.
Best Regards,
LaiTi
________________________________
From: "e...@pico-systems.com"
To: A...@yahoogroups.com
Sent: Saturday, July 18, 2009 12:33:31 AM
Subject: [AT91SAM] Re: performance guesstimate for TCP/IP stack
Chris DeLise wrote:
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
If your application does not need to be part of TCP/IP network, I think you just need to have ethernet frame with your application header. If I were you, I would get two sam7 evaluation boards and modify its ethernet sample codes. One of the board transmit and recevie in the ethernet frames and another board loop back the frames. The 1st board would toggle the GPIO whenever it receives the packet. You could analyze the performance by using Oscilloscope that probes the GPIO.
You could further optimize the speed by running the codes out of sram and compile the codes at high optimization.
Best Regards,
LaiTi
________________________________
From: "e...@pico-systems.com"
To: A...@yahoogroups.com
Sent: Saturday, July 18, 2009 12:33:31 AM
Subject: [AT91SAM] Re: performance guesstimate for TCP/IP stack
Chris DeLise wrote:
With a '7Xc256 at 48 MHz, uC/OS, and a Modbus/TCP client based on UIP, I've been observing about 400-500uS round trip (as measured by a packet sniffer on a 10 Mbit hub) without much tuning. This was using TCP, not UDP, a very simplistic stack, and includes the Modbus overhead. If you use UDP, or better yet, drop down to ethernet and a custom protocol, I think 100uS should be very attainable.
OK, that's the first hard numbers I've seen, thanks a great deal. But, this was all with a 10 mBit/second ethernet? I think my whole plan depends on 100 MBit/sec and no switch between the PC and the device. So, add a dedicated ethernet card to the PC and use a crossover cable to directly connect the Atmel device to the PC. The packets will be very short, something like a 32 byte payload. I plan on using part of RtNet for the PC end, just enough of it to do plain UDP from the reat-time linux environment. I have very limited resources here, just me, and I have to do everything, hardware & software design, board layout and manufacturing, etc. so I don't have the time to engage in major software development. I was hoping to use mostly off-the-shelf software components to do this.
Thanks again,
Jon
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - elso...@pico-systems.com - Jul 20 22:07:50 2009
Lai Ti,
This does sound like the proper approach. The host needs to be a PC running real-time Linux, and the communications need to be from the real time environment. There is a package RTnet that allows TCP and UDP packets to be processed from RT, it might allow me to go down to raw packets (there has to be a driver down at that level, but I have no idea what the interface looks like).
Does anyone have an idea what the overhead and latency is like on the AT91SAM7X handling short Ethernet packets in this mode?
(If anyone has worked with RTnet and has any idea what the overhead and latency there is, I'd sure appreciate the data, too, but that is OT for this group.)
Using the parallel port in EPP mode, I can transfer a byte every 800 ns with an on-mobo port, and maybe down to 600 ns with a good PCI card. I have it set up to automatically increment the register address on each data transfer, so you send one address command and then can transfer a dozen or more bytes at the above mentioned rate. These transfers are handled very close to the CPU instruction level (I think the real time environment may still virtualize these INB and OUTB instructions, but they are done pretty efficiently). So, if I can't beat the speed of the EPP parallel port, there is no sense in doing this. Right now I can do the whole servo update cycle (read position, calculate PID, send new velocity) in somewhere between 80 and 200 us depending on port and CPU speed, including the I/O transfer time.
Thanks,
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
This does sound like the proper approach. The host needs to be a PC running real-time Linux, and the communications need to be from the real time environment. There is a package RTnet that allows TCP and UDP packets to be processed from RT, it might allow me to go down to raw packets (there has to be a driver down at that level, but I have no idea what the interface looks like).
Does anyone have an idea what the overhead and latency is like on the AT91SAM7X handling short Ethernet packets in this mode?
(If anyone has worked with RTnet and has any idea what the overhead and latency there is, I'd sure appreciate the data, too, but that is OT for this group.)
Using the parallel port in EPP mode, I can transfer a byte every 800 ns with an on-mobo port, and maybe down to 600 ns with a good PCI card. I have it set up to automatically increment the register address on each data transfer, so you send one address command and then can transfer a dozen or more bytes at the above mentioned rate. These transfers are handled very close to the CPU instruction level (I think the real time environment may still virtualize these INB and OUTB instructions, but they are done pretty efficiently). So, if I can't beat the speed of the EPP parallel port, there is no sense in doing this. Right now I can do the whole servo update cycle (read position, calculate PID, send new velocity) in somewhere between 80 and 200 us depending on port and CPU speed, including the I/O transfer time.
Thanks,
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: performance guesstimate for TCP/IP stack - 42Bastian - Jul 21 8:53:12 2009
Jon
> Does anyone have an idea what the overhead and latency is like on the
> AT91SAM7X handling short Ethernet packets in this mode?
>
> ..
>
> Using the parallel port in EPP mode, I can transfer a byte every 800
> ns with an on-mobo port, and maybe down to 600 ns with a good PCI
> card. I have it set up to automatically increment the register
Did you check how fast the SAM7 can output your data to the GPIOs ?
I am not sure, but reaching the 600ns would mean at max. 30cycles per
8bit data which sounds rather impossible (running at 48MHz).
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> Does anyone have an idea what the overhead and latency is like on the
> AT91SAM7X handling short Ethernet packets in this mode?
>
> ..
>
> Using the parallel port in EPP mode, I can transfer a byte every 800
> ns with an on-mobo port, and maybe down to 600 ns with a good PCI
> card. I have it set up to automatically increment the register
Did you check how fast the SAM7 can output your data to the GPIOs ?
I am not sure, but reaching the 600ns would mean at max. 30cycles per
8bit data which sounds rather impossible (running at 48MHz).
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - elso...@pico-systems.com - Jul 22 15:22:38 2009
Did you check how fast the SAM7 can output your data to the GPIOs ?
I am not sure, but reaching the 600ns would mean at max. 30cycles per
8bit data which sounds rather impossible (running at 48MHz).
--
42Bastian
---------------
Hmmm, that seems odd. If I am sending multiple bytes of data to the same port, I should be able to pull the data byte out of an array (bump pointer, load byte@pointer to reg), write reg to GPIO data port, write status byte to control register GPIO port, clear status byte to control GPIO reg, and repeat as needed (loop). The basic operation really shouldn't take more than a 6 instructions. I know that when changing the address pointer in the target device or turning around the direction of the GPIO port there would be more overhead.
Anyway, I am also looking at some of the ARM9 CPUs that run a good deal faster. I was afraid that with all the Ethernet overhead, too, the ARM7 might be too slow to be worthwhile.
Anybody know of a good ARM9 board that just has 10/100 Ethernet and not too much else, like LCDs, touch screens, etc.? I'm looking for something with as much integration as possible, for just the Ethernet and GPIO pins, and that uses a hand-solderable package, not a ball-grid-array.
Thanks in advance for any tips!
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
I am not sure, but reaching the 600ns would mean at max. 30cycles per
8bit data which sounds rather impossible (running at 48MHz).
--
42Bastian
---------------
Hmmm, that seems odd. If I am sending multiple bytes of data to the same port, I should be able to pull the data byte out of an array (bump pointer, load byte@pointer to reg), write reg to GPIO data port, write status byte to control register GPIO port, clear status byte to control GPIO reg, and repeat as needed (loop). The basic operation really shouldn't take more than a 6 instructions. I know that when changing the address pointer in the target device or turning around the direction of the GPIO port there would be more overhead.
Anyway, I am also looking at some of the ARM9 CPUs that run a good deal faster. I was afraid that with all the Ethernet overhead, too, the ARM7 might be too slow to be worthwhile.
Anybody know of a good ARM9 board that just has 10/100 Ethernet and not too much else, like LCDs, touch screens, etc.? I'm looking for something with as much integration as possible, for just the Ethernet and GPIO pins, and that uses a hand-solderable package, not a ball-grid-array.
Thanks in advance for any tips!
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: performance guesstimate for TCP/IP stack - 42Bastian - Jul 22 15:58:44 2009
Jon
did you check Olimex ?
BTW: "-- " is used as endmark for the email-contents. A decent
email-client cut everything after this.
So if yours doesn't you should do it by hand.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
did you check Olimex ?
BTW: "-- " is used as endmark for the email-contents. A decent
email-client cut everything after this.
So if yours doesn't you should do it by hand.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: Re: performance guesstimate for TCP/IP stack - 42Bastian - Jul 22 16:02:59 2009
e...@pico-systems.com schrieb:
> mmm, that seems odd. If I am sending multiple bytes of data to the
> same port, I should be able to pull the data byte out of an array
> (bump pointer, load byte@pointer to reg),
1 cycle of increment.
3 cycles (if no stall due to the bus) for load
>write reg to GPIO data port
2 cycles (if no stall)
> write status byte to control register GPIO port, clear status
> byte to control GPIO reg, and repeat as needed (loop).
Increment counter, compare counter, jump: At least 6 cycles.
>> I am not sure, but reaching the 600ns would mean at max. 30cycles per
>> 8bit data which sounds rather impossible (running at 48MHz).
So its 12cycles only for output. Remain 18cycles to get the byte in via
Ethernet.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
> mmm, that seems odd. If I am sending multiple bytes of data to the
> same port, I should be able to pull the data byte out of an array
> (bump pointer, load byte@pointer to reg),
1 cycle of increment.
3 cycles (if no stall due to the bus) for load
>write reg to GPIO data port
2 cycles (if no stall)
> write status byte to control register GPIO port, clear status
> byte to control GPIO reg, and repeat as needed (loop).
Increment counter, compare counter, jump: At least 6 cycles.
>> I am not sure, but reaching the 600ns would mean at max. 30cycles per
>> 8bit data which sounds rather impossible (running at 48MHz).
So its 12cycles only for output. Remain 18cycles to get the byte in via
Ethernet.
--
42Bastian
------------------
Parts of this email are written with invisible ink.
Note: SPAM-only account, direct mail to bs42@...
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - elso...@pico-systems.com - Jul 24 0:19:22 2009
So its 12cycles only for output. Remain 18cycles to get the byte in via
Ethernet.
--
42Bastian
Thanks, I thought that this was about what I would get, and it should be no problem even for the ARM7 - at 55 MHz 30 cycles is 550 ns, which sounds pretty good. Reading a burst of 12 consecutive registers would take 6.5 us, comparable to the 100 MBit Ethernet transmission of a minimum-size packet. If I go to a SAM9260 running at 200 MHz it could go even faster, I might have to put some slight delays in there to hold the ARM back a bit.
This certainly will not be the bottleneck. So, I still think the handling of the Ethernet packets is the area where I don't KNOW what to expect.
Anyway, after more research, I am leaning toward the SAM9260, and have found microcontrollershop.com's EDDY-S1-PIN-V2.0 set to be pretty inexpensive and it looks like what I need, but their public info is a bit thin. Looking at the photos, it looks like all the EDDY board's pins come through the bottom of the lower board that has the net and serial connectors on it. So, it looks like I could just adapt to that to bring out the dozen or so wires I need. Has anyone here used their EDDY board, and what do you think about it? They talk all about their RTOS, but the EDDY board only has 4 MB of flash. Maybe that is enough to hold their kernel.
Thanks,
Jon
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )
Re: performance guesstimate for TCP/IP stack - Mark Butcher - Jul 31 5:37:06 2009
> Thanks in advance for any hard performance data that anyone can offer.
>
> Jon
>
Hi Jon
You can get some info here:
http://www.utasker.com/forum/index.php?topic=20.0
Check the benchmarks linked there (these are not on the SAM7X but equivalent speed processor and similar results).
Note that check sum calculation (can be disabled in UDP) and memory copies are main overhead. SAM7X has 128 byte rx/tx buffers and keeping Ethernet rx frames below 128bytes helps since the receptions fragments no longer need to be collected.
With full TCP/IP the overhead is fairly high (mainly due to various check sums that need to be calculated) and frame length is critical (the smaller the faster). Raw Ethernet (relying on Ethernet II CRC-32 only) can of course operate much more efficiently.
Regards
Mark
http://www.uTasker.com
------------------------------------
(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )