• XModem in 2022

    From Ben Collver@21:1/5 to All on Sun Jun 12 15:35:34 2022
    """
    The first order of business was to figure out why my system was much
    slower than the theoretical performance. In short, this was due to implementation details of our USB-to-serial converter chip!

    Taking a step back, since very few computers have hardware serial ports
    in the modern era, we're using FTDI's USB-to-serial modules. These chips
    have the notion of a "latency timer", which determines how long the chip
    waits before sending an incomplete packet. By default, this parameter is
    16 milliseconds.

    XMODEM breaks the data into 65536 packets of 1024 bytes, and reads a
    single byte (ACK) from the target after each packet. The internal packet
    buffer is larger than 1 byte, so the chip waits for the latency timer
    period before transfering this ACK to the host. This adds 65536 × 16 milliseconds = 17 minutes, which matches the performance I saw!

    On Linux, this can be adjusted by writing to the sysfs:

    echo 1 >
    /sys/devices/pci0000:00/.../usb1/1-3/1-3:1.0/ttyUSB0/latency_timer
    """

    From: https://www.mattkeeter.com/blog/2022-05-31-xmodem/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Ben Collver on Mon Jun 13 12:21:01 2022
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512

    Ben Collver wrote:
    [...]
    XMODEM breaks the data into 65536 packets of 1024 bytes, and reads a
    single byte (ACK) from the target after each packet. The internal packet buffer is larger than 1 byte, so the chip waits for the latency timer
    period before transfering this ACK to the host. This adds 65536 × 16 milliseconds = 17 minutes, which matches the performance I saw!

    Well, that's slightly problematic (and something to keep tabs on, if I
    ever use FTDI chips for a project). Granted, I'm kind of "cheap", and
    those chinese CH-whatever chips one picks up from sparkfun (etc) seem to
    work just fine; although I can't say I've ever utilized xmodem in my
    little projects.

    Maybe something to add to the list ...


    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmKnK7oACgkQbWVw5Uzn KGB2PBAAs+JicZKkVYUTaavJ3sAVkee8jjQ9ad9z1hBKGwWnKxXXnMBuOyQbGuHp kblOR/jZt3kJ2FA9R48K4zeC6HErvHk6Y1kfCyAP23qHBccVkvvLDPYuXrR9b+uP Hovdkok1g+0M4czj1+EX8wprrbHNpOe3rn4cY3fts1K2nevmeEYwkH+JxoluZg7a nQuSYpIcxFYdXs1BOTl0sV8rbVwwTiFxTg1aUv1N312bs6m+5cIS2zsRfqMCFZdz WnN9Rzk4ORjzP3GQNigluNwVUd/CF11imz7aVND0huHtrwzg4yVpU3LjmhIvpRIs Cr62W1bK1u4A3+Xu+JMa0elobpjMsao5Z4l7kmTjeZO7DAWUPfmnkmZQ8K2hFBt3 zqQCDLtCB+8NI+zXbeelyePS8jjMvF7DFFoGJndElbZUygfWVHg+wTHio9LStBK7 0p+H59BsPJnraaIvU5LUxKCKkmy8YpKlPlqOMvA3ZP1JH2pGu8tYbbQbFhQFrCUG 6HZKYb8jdPcMneSnUyFMXYup/vcDuDEGUoTRb+kp93wFEqD6HwQhVL8wVjB+7JJs hzRtf3DXVYuWKJDyOb+PzdCO+ZjfcoC83sYyuUn9XOA2iWsCOHOHfgDCd7lfPXDM QlrBRDWsVqkQgfHZ97Zisgfwu5bT4lOwG9WHJmcotRpvTltrqbA=
    =R5Zz
    -----END PGP SIGNATURE-----

    --
    |_|O|_|
    |_|_|O| Github: https://github.com/dpurgert
    |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Computer Nerd Kev@21:1/5 to Dan Purgert on Tue Jun 14 09:00:33 2022
    Dan Purgert <dan@djph.net> wrote:
    [...]
    XMODEM breaks the data into 65536 packets of 1024 bytes, and reads a
    single byte (ACK) from the target after each packet. The internal packet
    buffer is larger than 1 byte, so the chip waits for the latency timer
    period before transfering this ACK to the host. This adds 65536 x 16
    milliseconds = 17 minutes, which matches the performance I saw!

    Well, that's slightly problematic (and something to keep tabs on, if I
    ever use FTDI chips for a project). Granted, I'm kind of "cheap", and
    those chinese CH-whatever chips one picks up from sparkfun (etc) seem to
    work just fine; although I can't say I've ever utilized xmodem in my
    little projects.

    Aren't those Chinese chips often FTDI clones? Hence the disaster a
    few years ago when the Windows FTDI drivers were updated and broke compatibility with the cloned chips, causing everyone's bargain
    basement USB serial adapters to stop working.

    Personally the PC I'm posting from has two real RS-232 serial
    ports. One's got a mouse connected to it and I built a little
    two-transistor level converter that allows it to talk to modern
    devices quite nicely with the other one.

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dan Purgert@21:1/5 to Computer Nerd Kev on Tue Jun 14 09:26:53 2022
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512

    Computer Nerd Kev wrote:
    Dan Purgert <dan@djph.net> wrote:
    [...]
    XMODEM breaks the data into 65536 packets of 1024 bytes, and reads a
    single byte (ACK) from the target after each packet. The internal packet >>> buffer is larger than 1 byte, so the chip waits for the latency timer
    period before transfering this ACK to the host. This adds 65536 x 16
    milliseconds = 17 minutes, which matches the performance I saw!

    Well, that's slightly problematic (and something to keep tabs on, if I
    ever use FTDI chips for a project). Granted, I'm kind of "cheap", and
    those chinese CH-whatever chips one picks up from sparkfun (etc) seem to
    work just fine; although I can't say I've ever utilized xmodem in my
    little projects.

    Aren't those Chinese chips often FTDI clones? Hence the disaster a
    few years ago when the Windows FTDI drivers were updated and broke compatibility with the cloned chips, causing everyone's bargain
    basement USB serial adapters to stop working.

    The CH-340 (I think that's the number?) ones I have do not purport
    themselves as FTDI devices; at least insofar as I recall. I'd need to
    plug it in and re-check the USB-IDs though.


    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmKoVHAACgkQbWVw5Uzn KGARPA//Uw/keJVJukuW0TPqB7f1iDavlIhBXwiwH8Vvriq6Oh9bMIXo41y010bo DSo9+OBRtBcERiUOfrEnxxiDhvrd48JZrC0PgFmsdUdd7YMXK3dMEQtx43LUbloD VQ/VWkvSU5XxI8U3gTSFh0+Il//bY06huxkIkhXYi6PzmsSUdufB0DH0hsmHPT/8 uito5psURGV+6MTkgN4S+Rwfx14Rjkx2drJMsiQwwZL/3cC2vTATUwQGhZ8R6Oxc v/YB6VpCeqPw5PpDV2EZ1BAikbOO35hPFx5T65tS/Vdwaryc9e0mr7bfWAP/xIQO ssLBFdXaj4fdnq8yvkYrhz3dm9cFvpLZSbhCLR6MpfgB5mmUnPYA0qB4UoqMpSaU vtc33QhzpyI2aDqscibR2UUnJn/sWjj8H54cfNll5XdWYKrZlr9TIEPJaW//GEAf JVpn+FwYFN7E9rNCpgPLweEmkb3fvB6JyHHvYip/O95Uwcmx8qqHi3RTY3KIQkYy FPV3rCFdoxABR7NDcUtU4wsqDxl8RZx+SnumNGuFrR8bOYS9azso/Ntuw7teFLC6 Wlz1H6V/cAGc/QIdIKeY00pmg+WIUJ3ngQMBxbRvaD2xeLUXQyKCTu7/eTcAQNRc tl5BuBQMMhD0piZ6u2snVkH751JzjfEnf+3D0jwpu6kwte7kUXs=
    =HB6s
    -----END PGP SIGNATURE-----

    --
    |_|O|_|
    |_|_|O| Github: https://github.com/dpurgert
    |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Oregonian Haruspex@21:1/5 to All on Fri Jul 15 15:57:24 2022
    It pays to keep a computer with “real” serial and parallel ports around.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)