Announcement

Collapse
No announcement yet.

Benchmark That Serial Port On Linux!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Benchmark That Serial Port On Linux!

    Phoronix: Benchmark That Serial Port On Linux!

    While it's 2015, a serial port benchmark was just added to the Phoronix Test Suite and OpenBenchmarking.org...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Looks good. :-)

    Comment


    • #3
      When I saw the title I was actually hoping this to be an actual benchmark in the sense of profibus speeds (there is some software allowing for profibus support with serial devices, but I believe it's limited to some specific chipsets). Nonetheless, it's good to see this old but proven technology getting valuable attention.

      Comment


      • #4
        Originally posted by mycroes View Post
        When I saw the title I was actually hoping this to be an actual benchmark in the sense of profibus speeds (there is some software allowing for profibus support with serial devices, but I believe it's limited to some specific chipsets). Nonetheless, it's good to see this old but proven technology getting valuable attention.
        This could be slightly related https://www.youtube.com/watch?v=HPJSK00xq0Y

        Comment


        • #5
          I cannot wait for a floppy benchmark anymore!
          not

          Comment


          • #6
            Much more interesting than raw speed would be testing for bugs. Fastest standard speed is 230kbit/s, which is around prehistoric floppy disk speed. What is there to benchmark ?

            In a sense of bad copies of 16/4/550 chip, bugs in buffers etc.

            BTW, PCIe cards seem like much better choice, when available. They can offer LPT port with full functionality, for example, since they don't need to encapsulate COM&LPT within USB packets. This sort of encapsulation renders such ports unuseable for e.g some programmers etc.

            Comment


            • #7
              Originally posted by Passso View Post
              I cannot wait for a floppy benchmark anymore!not
              In fact, unlike floppies, serial interface still widely used. Various industrial equipment and so on comes with RS-232 ("classic" version with bipolar signals). Low-voltage version aka "3.3V UART" is often used these days for early boot debugging on small embedded boards & devices. UART is also standard peripheral of almost any microcontroller in existence, except maybe some few low end and low pin count versions.

              The reason behind it is simple. It simple. Even minimal and dumb boot loader can output at least some messages about boot progress. And print error messages, if any. Needless to say, it saves a day, once your piece of hardware stucks in early boot, way before full blown Linux kicked in and let you ssh into box. All this without requiring megabytes of code to start up GPU (which could be totally missing in particular embedded system, btw) or some bloated protocol stack like USB.

              ...as for floppies, legends tell I got close to 50Kb/sec on usual 1.44Mb floppy using proper (interleaved) formatting.

              Comment


              • #8
                Originally posted by Brane215 View Post
                Much more interesting than raw speed would be testing for bugs. Fastest standard speed is 230kbit/s, which is around prehistoric floppy disk speed. What is there to benchmark ?
                In fact, modern usb-to-uart bridges can go orders of magnitude faster than that. As example, take a look on FTDI2232H and similar. Though there're many other. Some ICs even gone beyond USB full speed (12Mbps) since 12Mbps wasn't enough. Modern uart bridges like FTDI can also do decent "bit-bang", generally being able to represent I2C, SPI (and JTAG, as subflavour of it), and so on and all this on quite a decent speed. In fact, many cheap JTAG dongles are using FTDI bridges, etc.

                And while it is not widely known, Linux got some hidden but working "TIOCS2" ioctl, dubbed after original TIOCS and other termios stuff. However, unlike prehistoric crap from teletype times, this IOCTL allows to request "arbitrary" bit rates. So you can get your 1 or 2 or 3Mbps if that's what you want. Of course what you get is really depends on IC capabilities (i.e. how it derives clocks and what dividers it can use).

                In a sense of bad copies of 16/4/550 chip, bugs in buffers etc.
                In fact USB to UART bridges are not like 16550 at all. They usually come with much larger buffers either since USB, especially low and full speed assumes certain delay: host only polls bus 1000 times a second. This means 1ms delay, no matter what. USB-HS is a bit better, but still subject to delays. So USB bridges usually come with buffers which are 128 Bytes or more

                [quote]BTW, PCIe cards seem like much better choice, when available.[quote]
                It really depends. USB to low-voltage uart things are great for early startup debugging in embedded systems and so on. And one needs 3.3V voltage most of time, not ancient bipolar RS232 in such case. Not to mention installation of PCI-e card requires to unscrew PC and not going to work with notebook. Yet, I even got FTDI dongle hooked to my smartphone (yep, with Linux one can do some really strange magic).

                They can offer LPT port with full functionality,
                Still, things like FTDI's FT2232H and similar USB bridges would kick an ass as "IO Extender" aka fast GPIO and I2C/SPI/UART stuff.

                for example, since they don't need to encapsulate COM&LPT within USB packets.
                This may or may not be an issue. Generally, these days it is fundamentally wrong to have protocol which 100% relies on host (PC) being able to do precise timings without additional hardware support. You see, in first place there is multi-tasking system runs under your back. It switches tasks here and there. This interferes with idea of precise timings quite a lot. And I doubt too many people these days would be happy to go for single-task OSes like DOS to improve it. This means buffered I/O and some smarter command execution ensing on other end of link, be it USB bridge or microcontroller (yes, you can do usb to GPIO/UART/etc bidge yourself, it one really wants it, and it can do very precise timings for certain special task, etc).

                This sort of encapsulation renders such ports unuseable for e.g some programmers etc.
                These programmers are usually dumb shit from MS-DOS ages. As simple as that. This approach is not going to work well in multi-tasked environments, and relying on ancient x86 IO ports programming is so prehistoric, either. If you really want to program SPI/I2C/etc ICs, take a look on FTDI bridges. Or ready dongles, if you're not hardcore enough to create one yourself. Or if you dislike FTDI, you can grab microcontroller of your choice, as long as it got USB-device interface and whatever IO you want. Then one can write firmware yourself to do anything. There is even standard class of usb-serial bridge, if one wants to pretend it is "UART".

                Comment


                • #9
                  Originally posted by SystemCrasher View Post
                  In fact, modern usb-to-uart bridges can go orders of magnitude faster than that. As example, take a look on FTDI2232H and similar.
                  Yes, but:

                  RS-232 is not designed for those speeds. Who cares for high speeds if connection is not reliable ? Whole point of RS-232 is either compatibility with old machines or robust communication over some length. If you have a couple hundred meters of good wire and a bit of environmental noise, you'd probably work at 9600 bps or similar speed.

                  FTDI type solutions tend to be cr*p because they defeat whole PnP concept of USB, since you don't have a way of telling two cips apart, when used in different gadgets.
                  With ordinary USB, it is simple as each inplemetnation has to have distinct VendorId and Model_Id.

                  And while it is not widely known, Linux got some hidden but working "TIOCS2" ioctl, dubbed after original TIOCS and other termios stuff. However, unlike prehistoric crap from teletype times, this IOCTL allows to request "arbitrary" bit rates. So you can get your 1 or 2 or 3Mbps if that's what you want. Of course what you get is really depends on IC capabilities (i.e. how it derives clocks and what dividers it can use).
                  Which frequently doesn't work as intended, even on tandard speeds. Just now I have small PCengines Alix 3D3 on my desk with two small I/O cards, each with 4* COM ports. One of the first thing I had to do is muck areound to get standard baudrate out of it since it has some hack with frequency division. It has Oxford Computer chip.
                  This is part of the reason why I suggested bug tests. WRT to higher speeds, one has to be carefull with the conditions. RS-232 is good up to couple hundred kbps and even that on perhaps tens of meters.

                  In fact USB to UART bridges are not like 16550 at all. They usually come with much larger buffers either since USB, especially low and full speed assumes certain delay: host only polls bus 1000 times a second. This means 1ms delay, no matter what. USB-HS is a bit better, but still subject to delays. So USB bridges usually come with buffers which are 128 Bytes or more
                  Which is not always good. They have big buffers for a reason - USB. How would you connect to such combo say GPS receiver module with PPS signal ? PPS uses hadshaje signal of COM port as edge-triggering interrupt source on seconf lapse and latency and jitter are important there. On ordinary COM port you can get latency&jitter probably on the order of couple hundred of ns. USB-COM solution is bound to be many times worse.


                  It really depends. USB to low-voltage uart things are great for early startup debugging in embedded systems and so on. And one needs 3.3V voltage most of time, not ancient bipolar RS232 in such case.
                  Wrong. Whole point of RS-232 is voltage swing, which gives it robustnes. With 3V and short distances one can get better speeds other ways when needed.

                  Not to mention installation of PCI-e card requires to unscrew PC and not going to work with notebook. Yet, I even got FTDI dongle hooked to my smartphone (yep, with Linux one can do some really strange magic).
                  WRT PC, so what. WRT notebooks, you can get equivalent for expansion card, whatever flavor of PCIe it is nowadays.
                  This brings you the I/O closer to the "metal" and you don't have to muck with USB bus tree...


                  These programmers are usually dumb shit from MS-DOS ages. As simple as that. This approach is not going to work well in multi-tasked environments, and relying on ancient x86 IO ports programming is so prehistoric, either. If you really want to program SPI/I2C/etc ICs, take a look on FTDI bridges. Or ready dongles, if you're not hardcore enough to create one yourself. Or if you dislike FTDI, you can grab microcontroller of your choice, as long as it got USB-device interface and whatever IO you want. Then one can write firmware yourself to do anything. There is even standard class of usb-serial bridge, if one wants to pretend it is "UART".
                  Dumb shit ? WHo cares. I have old Xeltek Superpro III programmer with 80-pin drivers that works perfectly with many non-ISP chips. I certainly wont throw it away just because it uses LPT in "stupid way". And BTW, for soem other apps, why exactly is direct pin drive that stupid if done within kernel driver ? Many boards have IEEE-1284 ( LPT's last reincarnation) even today. This thing is ideal for such purpose - direct pin drive in one way or another. 1284 ecen has "fast" bidirectional transfer and buffering.


                  WRT to USB-COM, it misses the point most of the time. RS-232 is old. Whatever had to be standardised, it was done long ago. For most uses today bottleneck are old standards, not new ones - it is likely that SW that works with COM expects to talk to 8250/16/4/5/50 and doesn't care for USB-COM.









                  Comment


                  • #10
                    Originally posted by SystemCrasher View Post
                    In fact, modern usb-to-uart bridges can go orders of magnitude faster than that. As example, take a look on FTDI2232H and similar.
                    BTW, I'm drawing my own USB programing tool that is to have microcontroller and work over USB. I see that first instinct of many DIY-ers is to reach for FTDI.
                    I hate them as they are expensive and they dumb-down whole PnP concept of USB. I decided to do my own USB stack on PIC16F1469 ( for USB)+ extra PIC for I/O.

                    Yes, I know that there are many other choices, but I'm limited to Microchip at the moment. Those PICs are cheap.


                    Comment

                    Working...
                    X