"""
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/

-----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

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.

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

-----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

It pays to keep a computer with “real” serial and parallel ports around.