Prev: generate discrete uniform random number with upper and lower bound
Next: Plane equation with 2 eigenvectors
From: Walter Roberson on 14 May 2010 03:08
Uzumaki wrote:
> Walter Roberson <roberson(a)hushmail.com> wrote in message

> Hi Roberson, I am talking about Ethernet (UDP/IP), not USB. Please read
> my question more carefully. Thank you for your concern anyways.

Sorry, it appears that I did misread; I thought you had asked about
sending it via a USB to ethernet converter, in which case the latency
would have depended upon USB latency.

For UDP, we cannot give you a real answer, as it depends upon your
equipment. We can speak in generalities:

The minimum UDP packet is the equivalent of 64 bytes plus the equivalent
of 4 bytes of preamble and the time equivalent of 12 bytes of silence
after the packet is transmitted, for a total of 80 bytes, 640 bit-times.
That applies up to 10 megabit ethernet, but if I recall correctly, the
minimum packet size is larger for gigabit ethernet.

640 bit times at 10 megabits per second is .064 ms, and since this is
the minimum packet size, the same size packet would be required in
return, taking us to a minimum of .128 ms.

To this we must add the time your target takes to respond (a matter
which you have not given us any information about), plus any line
latency due to distance, plus the interrupt latency of your real-time
system plus any time required to buffer the packet, check the CRC, and
so on.

The speed of electromagnetic waves in unshielded copper cables is
apparently about 0.96 c. However, reading your question carefully (as
per your request), I see that you specified that the transmission was to
be via "ethernet", which could potentially mean 10BASE2 or 10Base5 coax
cable (only 0.66c), or could mean the *-BaseT series, or could mean a
fibre optic based transmission layer. Good thing that you narrowed it
down to Ethernet though, as otherwise we might have had to explore
latencies for wireless too. In any case, clearly we do not have enough
information about your medium and about the distances you have, that we
might make an estimate of propagation latency.

Interrupt latency is going to depend upon your (unspecified) hardware.

About the only part of this that someone might potentially have
information about would be the RTWS packet driver software overhead. On
my part, I am going to guess that because real-time work depends upon
predictable timing rather than on highest performance, that the board
and driver would be more likely to be configured _not_ to "offload"
packet processing and DMA the packets in and then issue an interrupt:
configurations like that on an active system tend to have several
packets ready before the interrupt is ready, which is not behavior that
one would typically hope for in real-time work.
From: Uzumaki on 14 May 2010 03:25
Walter Roberson <roberson(a)hushmail.com> wrote in message <aG6Hn.7827$h57.5519(a)newsfe22.iad>...
> For UDP, we cannot give you a real answer, as it depends upon your
> equipment. We can speak in generalities:
>
> The minimum UDP packet is the equivalent of 64 bytes plus the equivalent
> of 4 bytes of preamble and the time equivalent of 12 bytes of silence
> after the packet is transmitted, for a total of 80 bytes, 640 bit-times.
> That applies up to 10 megabit ethernet, but if I recall correctly, the
> minimum packet size is larger for gigabit ethernet.
>
> 640 bit times at 10 megabits per second is .064 ms, and since this is
> the minimum packet size, the same size packet would be required in
> return, taking us to a minimum of .128 ms.
>
> To this we must add the time your target takes to respond (a matter
> which you have not given us any information about), plus any line
> latency due to distance, plus the interrupt latency of your real-time
> system plus any time required to buffer the packet, check the CRC, and
> so on.
>
> The speed of electromagnetic waves in unshielded copper cables is
> apparently about 0.96 c. However, reading your question carefully (as
> per your request), I see that you specified that the transmission was to
> be via "ethernet", which could potentially mean 10BASE2 or 10Base5 coax
> cable (only 0.66c), or could mean the *-BaseT series, or could mean a
> fibre optic based transmission layer. Good thing that you narrowed it
> down to Ethernet though, as otherwise we might have had to explore
> latencies for wireless too. In any case, clearly we do not have enough
> information about your medium and about the distances you have, that we
> might make an estimate of propagation latency.
>
> Interrupt latency is going to depend upon your (unspecified) hardware.
>
> About the only part of this that someone might potentially have
> information about would be the RTWS packet driver software overhead. On
> my part, I am going to guess that because real-time work depends upon
> predictable timing rather than on highest performance, that the board
> and driver would be more likely to be configured _not_ to "offload"
> packet processing and DMA the packets in and then issue an interrupt:
> configurations like that on an active system tend to have several
> packets ready before the interrupt is ready, which is not behavior that
> one would typically hope for in real-time work.

Hi Roberson, thank you for your useful answer. I'm sorry because I did not provide enough information on my system.
My system is as follow: A PC running RTWT connects with a microcontroller via Ethernet (UDP protocol). The microcontroller is dsPIC4011 from Microchip. The Ethernet Controller for dsPIC4011 is ENC424J600 (which is also from Microchip). This is a fast Ethernet Controller meaning that it can support 100Base-TX Ethernet. The transmission is through the regular coax cable. Also, you can neglect any time period regarding signal processing. I only need to know about the signal transmitting process. In other words, you can assume that after receiving the command packet (sent from PC), the microcontroller sends the data back immediately. So, in this configuration, can you help me to estimate the maximum time it takes for a complete request-response cycle to finish?

Regards,

Uzumaki
From: Walter Roberson on 14 May 2010 04:12
Uzumaki wrote:

> My system is as follow: A PC running RTWT connects with a
> microcontroller via Ethernet (UDP protocol). The microcontroller is
> dsPIC4011 from Microchip. The Ethernet Controller for dsPIC4011 is
> ENC424J600 (which is also from Microchip). This is a fast Ethernet
> Controller meaning that it can support 100Base-TX Ethernet. The
> transmission is through the regular coax cable.

100Base-TX is specified for Cat5 and later twisted pair cables, and is
not specified for coax.

> Also, you can neglect
> any time period regarding signal processing. I only need to know about
> the signal transmitting process. In other words, you can assume that
> after receiving the command packet (sent from PC), the microcontroller
> sends the data back immediately. So, in this configuration, can you help
> me to estimate the maximum time it takes for a complete request-response
> cycle to finish?

As per my earlier calculation, at least 640 bit times in each direction;
at 100 Mbit/s that would be 6.4 microseconds in each direction. You
would have to add the interrupt latency time to that. It appears that
that family of controllers has a 3 instruction cycle hardware interrupt
latency time,
http://en.wikipedia.org/wiki/PIC_microcontroller
which would be 100 ns for their 30 MIPS dsPIC30F4011 -- but you would
have to add another 4 instructions to that for saving the registers,
together with the driver execution times.
From: Uzumaki on 14 May 2010 04:24
Walter Roberson <roberson(a)hushmail.com> wrote in message
> As per my earlier calculation, at least 640 bit times in each direction;
> at 100 Mbit/s that would be 6.4 microseconds in each direction. You
> would have to add the interrupt latency time to that. It appears that
> that family of controllers has a 3 instruction cycle hardware interrupt
> latency time,
> http://en.wikipedia.org/wiki/PIC_microcontroller
> which would be 100 ns for their 30 MIPS dsPIC30F4011 -- but you would
> have to add another 4 instructions to that for saving the registers,
> together with the driver execution times.

Thank you for your answer. It seems that these speeds are enough for me because I only needs the the response time to be within ~1ms. I will build a circuit to verify these estimations.

Regards,

AnhTD
First  |  Prev  | 
Pages: 1 2
Prev: generate discrete uniform random number with upper and lower bound
Next: Plane equation with 2 eigenvectors