I thought I'd step in and clarify some things. I work at Technologic Systems
and designed both the XUART hardware FPGA core and the xuartctl software a few
years ago.
There seems to be confusion on what average response latency to expect out of
the XUART hardware + software.
First off, the RX FIFO is so deep in the XUART hardware that we don't even need
an interrupt for 90% of applications out there. This is why by default, the
xuartctl server process simply polls at 100hz (10ms) -- even if all 8 possible
channels are actively receiving data at 115200 baud the hardware is in no
danger of FIFO overflow. In the polling mode, you can expect around 10ms
latency before your app sees the RX data because thats how long it could be in
the hardware RX FIFO before being consumed and sent out to pipes/sockets to
downstream application code. Anything beyond 10ms is due to process
competition for the CPU -- if you have other threads/processes wanting the CPU
but you want to ensure your application still sees XUART serial data promptly,
its a simple matter of setting process priorities. Its worth noting this
latency is the norm for kernel serial drivers too, since they post their data
to the kernel termios layer which holds on to bytes and does not present them
to userspace until after 10-100ms unless a not-well-known low latency mode
ioctl() is run on the serial driver.
The XUART hardware and software can also be told to use IRQs. There really is
only 2 reasons to use IRQs: 1) You are using baud rates above 115200, or 2) you
need minimal or sub-10ms latency on RX characters. To use IRQs on the TS-7550,
edit the /linuxrc and change the line that invokes the xuartctl server from
"xuartctl --server" to "xuartctl --server --irq=29"
Once you start allowing the software to use IRQs, xuartctl starts paying
attention to a couple extra parameters -- specifically, the "rlw=" (Receive
low-water mark) and the "ithr=" (Idle-threshold). The "rlw=" arg takes a
number between 1-255 is the the minimum number of RX characters in the RX FIFO
that will be accumulated before sending an IRQ and waking up the hardware
consumer process. When you enable irq's, it defaults to "1" meaning it will
send an IRQ after every single RX character received. The "ithr=" argument is
used to tune the number of bit-times the RX line has to be idle before sending
an IRQ before the rlw= threshold is met.
The simple latency test we run as part of "xuartctl --test" is run with TX and
RX looped back to each other. The test transmits a single character, waits to
receive it on the rx line, then sends it again, over and over. This emulates a
system with a 1 byte 0-latency request/response protocol and serves as our
benchmark. The XUART polling at 100hz, predictably gives us approximately 100
request/response transactions per second, when using IRQs, we get approx 600
per second. When using the CPU internal uart with the low latency ioctl, we
get 1500. A modern multi-ghz Linux-x86 PC on a motherboard (not USB) serial
port gets 2000.
Why did we implemented XUART's in userspace over TCP? There are actually
several reasons:
1) Talking to customers over the years I've found a very large portion of
people use our boards as serial to network(TCPIP) converters, so I figured I'd
save them some development by allowing that out-of-the-box.
2) Linux kernel version independence -- xuartctl doesn't need to be reworked
when kernel innards APIs change.
3) Linux kernel serial port API deficiencies -- XUART hardware has features
that cannot be represented in the normal serial API. 9-bit serial, timed
idle/break, non-standard arbitrary baud rates, pipelined baud rate changes,
etc...
4) Debuggability -- since we designed both the hardware and software, we had to
debug both at the same time. This sort of design flow is much faster and
efficient when you have good debug tools and don't have to worry about
crashing/deadlocking the kernel.
5) As a userspace process, its priority can be tweaked lower if there are more
important things to process than serial ports. A kernel driver is always on
and interrupting at its full rate while its open.
6) Exportability -- xuartctl can export its serial ports to other UNIX machines
across the internet to serve as virtual "local" serial ports since xuartctl.c
compiles on any UNIX.
//Jesse Off
--- In Walter Marvin <> wrote:
>
> What actually occurs is that Technologic mmaps the xuart hardware into the
> Linux user space and then treats them as internal TCP servers.
> They have arranged the servers so as to support "raw" device mapping within
> Linux. What this does is cause excessive user space to kernel space context
> switches, especially since the xuart hardware can dribble in characters a few
> time. This causes non-linear latency responses when combined with other user
> space loads. The actual latency starts at about 2ms and increases in a
> non-linear fashion dependent on other load. This is really not that
> measurable with a simplistic program, but top is useful.
>
> If you want to use one xuart channel per serial line at 100 ms per packet,
> Technologics' system can probably handle that, but I would model it with
> some scripting and measure, just to be sure
>
>
>
> ________________________________
> From: mike ingle <>
> To:
> Sent: Wednesday, August 31, 2011 4:19 PM
> Subject: Re: [ts-7000] TS-7550 XUARTs
>
>
> Â
> Hi Walter,
>
> Am I right there there is no device driver, and that the userspace just mmaps
> the xuarts? Â For my application, latency won't be a problem, also very much
> a fixed line setup. Â What little I read on the xuart indicated that they
> expect about 100ms latency in their user space server (I would assume that I
> wouldn't be using their xuartctl server, instead directly reading and writing
> to the xuarts) . Â As long as It never ever drops characters, latency is OK.
> Â Given how few of these will be built, and the desire to run device test
> routines on the server, I think 8 uarts per 7550 is OK. Â my biggest concern
> is that the 7550 perform as described.
>
> best regards Mike
> On Aug 31, 2011, at 11:50 AM, Walter Marvin wrote:
>
> Â
> >
> >
> >The TS7500 and 7550 does NOT I repeat NOT have standard Linux serial device
> >driver support. The User Space servers that Technologic supply limit the
> >throughput and latency you achieve. Since your baud rate is the same on
> >all channels and the through put is relatively low you might be able to get
> >away with it. I would suggest you set up a demo with one 7550 and see if
> >it works without delays.Â
> >
> >
> >
> >I had to modify the servers and finally write my own drivers to get 50 ms
> >latency and line set up flexibility. If you go to a device driver, you might
> >be able to multiplex the serial streams in hardware and limit the number of
> >7550's. I can help you with this.
> >
> >
> >
> >
> >
> >
> >________________________________
> >From: mike ingle <>
> >To:
> >Sent: Wednesday, August 31, 2011 2:34 PM
> >Subject: [ts-7000] TS-7550 XUARTs
> >
> >
> >Â
> >Hi all,
> >
> >I need to maintain communications with 80 devices overRS-232 serial (115k).
> > Each device streams an approximately 120 byte packet every 100ms.
> >also the host, can send packets, and expect a response at any time. The
> >packets are hex encoded with out of band start and stop characters.
> >
> >I am contemplating using 10 ts-7550s (with appropriate level shifters) to
> >control the devices, and forward the data over ethernet. The intent would
> >be to crack the serial packets (which include 2 crc32 checks) down to their
> >60byte binary size, buffer 10 or so serial packets per channel, (600bytes
> >per ethernet packet) and send them on up to a host for logging and display.
> >
> >My data rate calculations show very modest ethernet usage (8 x 600 bytes/s).
> >
> >On the surface the ts-7550 looks like a nice fit for this. Anyone have any
> >experience with the XUARTs , or better suggestions? Probably no more than 3
> ><80 channel systems> will be built.
> >
> >Best Regards Mike
> >
> >
> >
> >
> >
> >
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|